From internet-drafts@ietf.org Fri Aug 3 22:49:41 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4F421E8039; Fri, 3 Aug 2012 22:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msXvTfOCSZ9j; Fri, 3 Aug 2012 22:49:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33E821F8D33; Fri, 3 Aug 2012 22:49:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120804054919.9447.74187.idtracker@ietfa.amsl.com> Date: Fri, 03 Aug 2012 22:49:19 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 05:49:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. Title : A SASL and GSS-API Mechanism for OAuth Author(s) : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-02.txt Pages : 22 Date : 2012-08-03 Abstract: OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses OAuth over the Simple Authentication and Security Layer (SASL) or the Generic Security Service Application Program Interface (GSS-API) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. Clients typically store the user's long term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a token. Tokens typically provided limited access rights and can be managed and revoked separately from the user's long-term credential (password). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wmills@yahoo-inc.com Fri Aug 3 22:59:46 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D32C21F8D40 for ; Fri, 3 Aug 2012 22:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.423 X-Spam-Level: X-Spam-Status: No, score=-17.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVp+F8ielJEq for ; Fri, 3 Aug 2012 22:59:45 -0700 (PDT) Received: from nm22-vm0.bullet.mail.sp2.yahoo.com (nm22-vm0.bullet.mail.sp2.yahoo.com [98.139.91.222]) by ietfa.amsl.com (Postfix) with SMTP id 6827621F8D34 for ; Fri, 3 Aug 2012 22:59:45 -0700 (PDT) Received: from [98.139.91.70] by nm22.bullet.mail.sp2.yahoo.com with NNFMP; 04 Aug 2012 05:59:45 -0000 Received: from [98.139.91.37] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 04 Aug 2012 05:59:45 -0000 Received: from [127.0.0.1] by omp1037.mail.sp2.yahoo.com with NNFMP; 04 Aug 2012 05:59:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 110610.28440.bm@omp1037.mail.sp2.yahoo.com Received: (qmail 16388 invoked by uid 60001); 4 Aug 2012 05:59:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344059984; bh=hCnUQYFUjt0QkYa1ohgVXWMN/OW1hlW7xmLCSzrdT3k=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=TDt2A3QOPraGuVMjNa6nQzIErYteZjdKPtCeMNttqiXzEBd32jtCon/sj0z5iJf3fHzJfbwoFAHqSSR6D5Uk8i/UEZ/KzgTiIUGPHirnc0CIwUznT9TJ1MF54oypH0Yqy818vSJ4G/3/w+lp2MnjKJZy2R1ctz1313i3ADoKZ38= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=U3KMyTJ0s+98OU86sQ2m9Kai0N0HdnzVfFL/1cGKLar7lONRusPvI1J/xj70r17fivfHyWqLaUOwe8wYbLkh0ecwmKWNyWo4nvXR+/n1pRRryCbEx2FFjb/J10zP4dq6WhzUkEYN9oKQQ4X/sxHUxSas3tWNmqMhgdt9S+EUjrE=; X-YMail-OSG: Orq1PtIVM1lU1ijaZf8HDfVbuLZpSnqe_pJrWqNWdhnjMH7 H9BTABjTHu1qfoUD07IGja3ZGc48ntuBOgk8v8WgpLPdwPZwJmYSyP_PxrDR oado01_H_bcQCUouUaa_LL37zjbMa1OG8bX3ZY2fjLYvxViKMahcYxixEX6l 4yFqK13mKkVx6bblfVxijopqtx4Qoz52l9_2YYgds0UZXu5Hh7OBZoY5f66M nyLlZMthSUpAefom94ZpWoiQXH8kfkKn_hRuAOX.dBzDDoiNPaRNVDMVwu8M jtu0WU8otgnmtjb2m8itWLTDM5WNn_7ecHulKYu8tm8zfH58N6HZw0kEe9A2 w5OHdpK8U5oLRqEQ0wKoI1a1QW38473zD1GFUwjieKQ89cVwgq90v8kw8GFx fO.gMFr51KTWUPtRJGUB6I4Qgks9eMFE0G8ay3FZf4WU- Received: from [99.31.212.42] by web31804.mail.mud.yahoo.com via HTTP; Fri, 03 Aug 2012 22:59:44 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <20120804054919.9447.74187.idtracker@ietfa.amsl.com> Message-ID: <1344059984.3012.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Fri, 3 Aug 2012 22:59:44 -0700 (PDT) From: William Mills To: "kitten@ietf.org" In-Reply-To: <20120804054919.9447.74187.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-9536188-1344059984=:3012" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 05:59:46 -0000 --835683298-9536188-1344059984=:3012 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FYI, this draft:=0A=0A-=A0=A0=A0 adds a required user name data element as = a routing hint to the server.=0A-=A0=A0=A0 minor editorial changes=0A-=A0= =A0=A0 Corrected the ABNF RFC number to the later one.=0A=0A-bill=0A=0A=0A= =0A=0A>________________________________=0A> From: "internet-drafts@ietf.org= " =0A>To: i-d-announce@ietf.org =0A>Cc: kitten@ie= tf.org =0A>Sent: Friday, August 3, 2012 10:49 PM=0A>Subject: [kitten] I-D A= ction: draft-ietf-kitten-sasl-oauth-02.txt=0A> =0A>=0A>A New Internet-Draft= is available from the on-line Internet-Drafts directories.=0A>This draft i= s a work item of the Common Authentication Technology Next Generation Worki= ng Group of the IETF.=0A>=0A>=A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : A SASL a= nd GSS-API Mechanism for OAuth=0A>=A0=A0=A0 Author(s)=A0 =A0 =A0 : William= Mills=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tim Showalter= =0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hannes Tschofenig= =0A>=A0=A0=A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-kitten-sasl-oauth-02.txt= =0A>=A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0 : 22=0A>=A0=A0=A0 Date=A0 =A0 =A0 = =A0 =A0 =A0 : 2012-08-03=0A>=0A>Abstract:=0A>=A0 OAuth enables a third-par= ty application to obtain limited access to a=0A>=A0 protected resource, ei= ther on behalf of a resource owner by=0A>=A0 orchestrating an approval int= eraction, or by allowing the third-party=0A>=A0 application to obtain acce= ss on its own behalf.=0A>=0A>=A0 This document defines how an application = client uses OAuth over the=0A>=A0 Simple Authentication and Security Layer= (SASL) or the Generic=0A>=A0 Security Service Application Program Interfa= ce (GSS-API) to access a=0A>=A0 protected resource at a resource serve.=A0= Thereby, it enables schemes=0A>=A0 defined within the OAuth framework for= non-HTTP-based application=0A>=A0 protocols.=0A>=0A>=A0 Clients typicall= y store the user's long term credential.=A0 This does,=0A>=A0 however, lea= d to significant security vulnerabilities, for example,=0A>=A0 when such a= credential leaks.=A0 A significant benefit of OAuth for=0A>=A0 usage in t= hose clients is that the password is replaced by a token.=0A>=A0 Tokens ty= pically provided limited access rights and can be managed=0A>=A0 and revok= ed separately from the user's long-term credential=0A>=A0 (password).=0A>= =0A>=0A>The IETF datatracker status page for this draft is:=0A>https://data= tracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth=0A>=0A>There's also a htm= lized version available at:=0A>http://tools.ietf.org/html/draft-ietf-kitten= -sasl-oauth-02=0A>=0A>A diff from the previous version is available at:=0A>= http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-02=0A>=0A>= =0A>Internet-Drafts are also available by anonymous FTP at:=0A>ftp://ftp.ie= tf.org/internet-drafts/=0A>=0A>____________________________________________= ___=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailm= an/listinfo/kitten=0A>=0A>=0A> --835683298-9536188-1344059984=:3012 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
FYI, this draft:

-    adds a required user name data el= ement as a routing hint to the server.
-    minor editorial changes
-  &= nbsp; Corrected the ABNF RFC number to the later one.

=
-bill
<= /div>

= From: "internet-drafts@ie= tf.org" <internet-drafts@ietf.org>
To: i-d-announce@ietf.org
Cc: kitten@ietf.org
Sent: Friday, August 3, 2012 10:49 PM
Subject: [kitten] I-D Action: draft-i= etf-kitten-sasl-oauth-02.txt

=0A
A New Internet-D= raft is available from the on-line Internet-Drafts directories.
This dr= aft is a work item of the Common Authentication Technology Next Generation = Working Group of the IETF.

    Title    &nb= sp;     : A SASL and GSS-API Mechanism for OAuth
  =   Author(s)      : William Mills
    &nbs= p;                     Ti= m Showalter
                &nbs= p;         Hannes Tschofenig
    File= name        : draft-ietf-kitten-sasl-oauth-02.txt
&n= bsp;   Pages          : 22
 &nb= sp;  Date            : 2012-08-03
Abstract:
  OAuth enables a third-party application to obtain lim= ited access to a
  protected resource, either on behalf of a resource owner by
  orchestrating an approv= al interaction, or by allowing the third-party
  application to ob= tain access on its own behalf.

  This document defines how an = application client uses OAuth over the
  Simple Authentication and= Security Layer (SASL) or the Generic
  Security Service Applicati= on Program Interface (GSS-API) to access a
  protected resource at= a resource serve.  Thereby, it enables schemes
  defined wit= hin the OAuth framework for non-HTTP-based application
  protocols= .

  Clients typically store the user's long term credential.&n= bsp; This does,
  however, lead to significant security vulnerabil= ities, for example,
  when such a credential leaks.  A signif= icant benefit of OAuth for
  usage in those clients is that the pa= ssword is replaced by a token.
  Tokens typically provided limited access rights and can be managed
  and revoked separately= from the user's long-term credential
  (password).


The= IETF datatracker status page for this draft is:
https:= //datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth

There's = also a htmlized version available at:
http://tools.ietf.org/html/draft-i= etf-kitten-sasl-oauth-02

A diff from the previous version is availab= le at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-0= 2


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ie= tf.org/internet-drafts/

________________________________________= _______
Kitten mailing list
Kitten@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/kitten


--835683298-9536188-1344059984=:3012-- From rtroll@google.com Mon Aug 6 09:50:50 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0322421F8568 for ; Mon, 6 Aug 2012 09:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qPp8YiHWJBV for ; Mon, 6 Aug 2012 09:50:49 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E14D21F8541 for ; Mon, 6 Aug 2012 09:50:42 -0700 (PDT) Received: by qcac10 with SMTP id c10so2162947qca.31 for ; Mon, 06 Aug 2012 09:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=moZMPbTvg70+bRIcrSV8Ai456w/nSItteprA5IajCcI=; b=QIBuFfw/VVDuuGiC2bskMWqqZ37oPVUoF8HkOgKgDDJPAlUTxWVfExteyWQ1Jw19wI fwS16y7qMh754Mz/eYOgKf3sGnxywGV9ldFlGDuTbh128xcH6/J2qYp0RlaFAjCj3HkO UAJ12PWw/6mvi50xvv2Wp4xQpVL9HfuiNBR2w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=moZMPbTvg70+bRIcrSV8Ai456w/nSItteprA5IajCcI=; b=QKtNWkuIoNIQkYfux2os/jZLezl6dIsMaYJVtZ+dsNwdXf1n9GeLOIYpRA1GvACf5w lohgWDImB85UbpLPxyqPikmjj9ThHvL4w+nE7LwsxqFVkPRbEyJ5RB7XeBt45VHC/51x N1nTBMvC/nw1TgW8H3IqnDx5Qz35mgLeZLhuXEtGV1QmzmQ0kD0tmRUt6gamOKJy+xrZ 4+E6kIYlZp3d/cpHOSEpqL+E4mv98l4dZttZN7HnMNTL6XoJbVMeIqFevb6eB9eC05ks 75McCfoaG5LaSWBKV5GSye/feOJ8oUijR7c/dI90EuI4NORvAEgrzCI5MJXGShB4XJj8 WHiw== Received: by 10.229.135.199 with SMTP id o7mr5795973qct.0.1344271841801; Mon, 06 Aug 2012 09:50:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.199 with SMTP id o7mr5795965qct.0.1344271841610; Mon, 06 Aug 2012 09:50:41 -0700 (PDT) Received: by 10.229.201.230 with HTTP; Mon, 6 Aug 2012 09:50:41 -0700 (PDT) Date: Mon, 6 Aug 2012 09:50:41 -0700 Message-ID: From: Ryan Troll To: kitten@ietf.org Content-Type: multipart/alternative; boundary=00248c70fd8199ccf904c69bad4a X-System-Of-Record: true X-Gm-Message-State: ALoCoQkIv33IoBzCQRFa2kZ4vYgVtvMD0nf5CSFVXv2wqx6YLf0a3KtNUwP8vXcs70Hrwb/KXReQNiB6oV7VQtthmcP17qgbIkY5F58P5+BO52aNYimIU/OymdSXeTGZACiYF8GHfrJXoN0ZZ/olkDjKYByXWSh/yDiu5f+WH20uw80RTOpCrmb9iTEuWdZ+2goHXLSHTRvq Subject: [kitten] Comments on draft-ietf-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 16:50:50 -0000 --00248c70fd8199ccf904c69bad4a Content-Type: text/plain; charset=ISO-8859-1 Reviewing the latest draft, I had two comments: *Signature Calculation* In the last paragraph of section 3.1, the user field should be included in the signature. *Bearer Token Format* According to draft-ietf-oauth-v2-bearer, section 2.1, the credential in the Authorization header is formatted as: b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=" credentials = "Bearer" 1*SP b64token for example: Bearer mF_9.B5f-4.1JqM Should the SASL Auth mechanism follow the same format? If so, the example in section 5.1 should be changed to: auth=Bearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==^A^A This removes the quotes, and uses the same casing fror "Bearer" as defined in the draft. -R --00248c70fd8199ccf904c69bad4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Reviewing the latest draft, I had two comments:


Signature Calculation
In the last paragr= aph of section 3.1, the user field should be included in the signature.


Bearer Token Format
According to draft-ietf-oauth-v2-bearer, section 2.1, the credent= ial in the Authorization header is formatted as:
<= br>
b64token =A0 =A0=3D 1*( ALPHA / DIGIT /
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"-" / "." / = "_" / "~" / "+" / "/" ) *"=3D&= quot;
credentials =3D "Bearer" 1*SP b64token

for example:

Bearer mF_9.B5f-4.1JqM<= /div>


Should the SASL Auth mechanism f= ollow the same format? =A0If so, the example in section 5.1 should be chang= ed to:

auth=3DBearer=A0vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=3D=3D^A^A

This removes the quotes, and uses the sa= me casing fror "Bearer" as defined in the draft.


-R

--00248c70fd8199ccf904c69bad4a-- From wmills@yahoo-inc.com Mon Aug 6 10:27:54 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF8B11E80A5 for ; Mon, 6 Aug 2012 10:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.549 X-Spam-Level: X-Spam-Status: No, score=-17.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayBcuXJ8FAIH for ; Mon, 6 Aug 2012 10:27:54 -0700 (PDT) Received: from nm2.bullet.mail.bf1.yahoo.com (nm2.bullet.mail.bf1.yahoo.com [98.139.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id D68D011E80A3 for ; Mon, 6 Aug 2012 10:27:53 -0700 (PDT) Received: from [98.139.212.146] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 06 Aug 2012 17:27:53 -0000 Received: from [98.139.212.247] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 06 Aug 2012 17:27:53 -0000 Received: from [127.0.0.1] by omp1056.mail.bf1.yahoo.com with NNFMP; 06 Aug 2012 17:27:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 90628.55530.bm@omp1056.mail.bf1.yahoo.com Received: (qmail 91762 invoked by uid 60001); 6 Aug 2012 17:27:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344274072; bh=+Oquebu0jp6QwJLnm2wD2Llud/x99zxTIdsZLlOJuHY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PRkGXcTeWV1NPMEKwgSGu/TqNMpo0AGr3vIe6iEQi5Her3Io4H1p2KhRMMTR8gEmrEAly5IXhmxZAhUaaD+vkEXtyTXqdNPNfHDB+OCBwnlIFFIe2X9CFcRP/Es3R+1rnLUe5LL9qeZATwiHj9do+y7z5uTnkl+r2wMziykXw1g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Pu/MJgCa3b8VVsCdevKq0aZB3h8830usGDcvyKgabADoQEfJjVYTd7MZRpb+2PM7u3I0xvohz1PjJiMD2WWxVYrJDcxV3nXBuvo6qnOIzs/8hv7K5YqsYJyqooNUj+ppfWGDWhyBqbeuFC4okWCdGxJU2sAZzcJq+hATsIf0euk=; X-YMail-OSG: cUWCrQYVM1msYqgTYz4a7GzLOIHq_X4izvO9pGmwLQYwVh8 c.jJNJSq86or_x0BFeURlJKx6U.EtwoUFMrR6gCDBmHgt19WAAbmV6PLIFcV uqleF6TgPgrk6gw05PZJ0NQxlr2zyipoABJYTyO3U1Bw6r8pGhhNDIumDqKq DilS4H.cbbo9L59kUvtzqFVRtcqAsJ1svMbUhxcJ4Sc8jIoLfpuRJlrv9zmK _i_ffWI42FemC4BXgs7fQhnEzfTt17de3b_.IfCzs3WkKY2zIjFRgwK_z2bV XHMKioUPv5JF6kiieE.4TyJnFPRBqj6W0HHhk3irNLrJaKxc.g6cuf.FywGY XK9F6ajGOS90XzsZl4Mv_NRMbUqlxFpzhGK8xA91aUtXYJuNK7Hai3X9RRQX HlzgAqU0HY2icbb9SjGPDUchL8gyPp37CAFyzBW7FQNm8e6s4a97_ow41kg9 TNUO6HQ-- Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Mon, 06 Aug 2012 10:27:52 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: Message-ID: <1344274072.86461.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Mon, 6 Aug 2012 10:27:52 -0700 (PDT) From: William Mills To: Ryan Troll , "kitten@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [kitten] Comments on draft-ietf-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 17:27:55 -0000 >________________________________=0A> From: Ryan Troll =0A>To: kitten@ietf.org =0A>Sent: Monday, August 6, 2012 9:50 AM=0A>Subjec= t: [kitten] Comments on draft-ietf-kitten-sasl-oauth-02=0A> =0A>=0A>Reviewi= ng the latest draft, I had two comments:=0A>=0A=0A=0AThank you for the revi= ew :)=0A=0A>=0A>Signature Calculation=0A>In the last paragraph of section 3= .1, the user field should be included in the signature.=0A>=0A=0A=0AI don't= think so.=A0 The user field is a hint, and not authoritative.=A0 Also, the= re's no way to get it into OAuth 1.0a.=A0 If we want it there we have to pu= t user in the path, query string, or post args.=0A=0A=0A>=0A>Bearer Token F= ormat=0A>=0A>According to draft-ietf-oauth-v2-bearer, section 2.1, the cred= ential in the Authorization header is formatted as:=0A>=0A>>=0A>>b64token = =A0 =A0=3D 1*( ALPHA / DIGIT /=0A>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0"-" / "." / "_" / "~" / "+" / "/" ) *"=3D"=0A>>credentials =3D "Bear= er" 1*SP b64token=0A>=0A>for example:=0A>=0A>=0A>Bearer mF_9.B5f-4.1JqM=0A>= >=0A>=0A>Should the SASL Auth mechanism follow the same format? =A0If so, t= he example in section 5.1 should be changed to:=0A>=0A>auth=3DBearer=A0vF9d= ft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=3D=3D^A^A=0A>=0A>This removes the quot= es, and uses the same casing fror "Bearer" as defined in the draft.=0A>=0A= =0A=0ARemoved the quotes.=A0 =0A=0A=0ACase is an interesting question.=A0 A= uthorization header scheme names are case insensitive.=A0 I'm happy to make= this consistent, but I relly don't want folks to get hung up on the exampl= es rather than the actual spec.=A0 What's the right thing here, add a note? From wmills@yahoo-inc.com Mon Aug 6 10:35:48 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D93621F84A1 for ; Mon, 6 Aug 2012 10:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.251 X-Spam-Level: X-Spam-Status: No, score=-17.251 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voKhnY9wRHEc for ; Mon, 6 Aug 2012 10:35:47 -0700 (PDT) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1AE21F84A2 for ; Mon, 6 Aug 2012 10:35:46 -0700 (PDT) Received: from [98.139.212.145] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 06 Aug 2012 17:35:46 -0000 Received: from [98.139.212.205] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 06 Aug 2012 17:35:46 -0000 Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 06 Aug 2012 17:35:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 469709.36000.bm@omp1014.mail.bf1.yahoo.com Received: (qmail 78464 invoked by uid 60001); 6 Aug 2012 17:35:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344274546; bh=v+w+vw+SqatbPUO4C0jEZWa/pba5IYouXEhei5kVEYc=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gQfl/GYIQHXkBrxa1Cuc72IEhDGxo43Z1D+QG7+/pGfFO7nICGIsMomurQ/TOLCLlPXRF6gdbdU0AjRVdYQ5lC88xpzRFf99VBNgmpE5P2F9f/pCK7MoiEEpm7tomO3V/O6ZRXYOgxkc2Og/7obYeTe6FKp9D4jSpF/IacgyP+4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FlB8c1lm2aIWFxJmbxIXQNFPMdIr0K1KSGzhfeewp/en1LxYNUxQ0xbGCqWJNBJr4EL36bUWI77SUNkGM1zyTPb+G8/c7gME6rTQNTe5tLUFQh2cKKoFETvqhIlDgZuLIcLYvDsvxIzMQtpgRCTpamrdKMNImRwv6aIJeO626N0=; X-YMail-OSG: _qtv.oMVM1nEhkRhe4FH3UYJCyL6yfReAaiwRcmuWNQ4FEC V0ckPbRzOAxQoWSe5aBGCTvQagEbdwQx7NUkQX.L7u9sowcHNPp.tYwhyb2D .k5e1drooQEG8QKoGNNP2unTXdb99BJKzwjI9e7Nnb2ScLLJKFidBFzRPKSv 6J6CVOC.q1jf49O1.AYRZHULjoNVcQ4TlkTLv8etSDlo44SZJujb.78EtfgS dYm.LZ5UsBSbpXqRU1bYDfsQunWsb1vvqI6_B9b54tg_tM8lJJXPycgVXn4d jn1PofLr1_WvOVSZmV9EFF0aaeeeG1fCLfAL18QhWBzR5BpWJc26DZQ3jXlM R5D9V_EYX2zPjrVPk33I7XkSbtXNjN9_FrKn6Ew5SDQDkxFK2AbSb6bLNsQ5 .Rb1Rtt7yUQVVintAzLdHgZu6B_kQeK6VrOflLXIJVo7RZjZqNm.T1fk.zR4 C2jfPfw-- Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Mon, 06 Aug 2012 10:35:45 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <1344274072.86461.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: <1344274545.58506.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Mon, 6 Aug 2012 10:35:45 -0700 (PDT) From: William Mills To: William Mills , Ryan Troll , "kitten@ietf.org" In-Reply-To: <1344274072.86461.YahooMailNeo@web31806.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [kitten] Comments on draft-ietf-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 17:35:48 -0000 And I need to fix all the examples now to add the user header.=0A=0A=0A=0A-= ---- Original Message -----=0A> From: William Mills = =0A> To: Ryan Troll ; "kitten@ietf.org" =0A> Cc: =0A> Sent: Monday, August 6, 2012 10:27 AM=0A> Subject: Re: [ki= tten] Comments on draft-ietf-kitten-sasl-oauth-02=0A> =0A>> _______________= _________________=0A>> From: Ryan Troll =0A>> To: kit= ten@ietf.org =0A>> Sent: Monday, August 6, 2012 9:50 AM=0A>> Subject: [kitt= en] Comments on draft-ietf-kitten-sasl-oauth-02=0A>> =0A>> =0A>> Reviewing = the latest draft, I had two comments:=0A>> =0A> =0A> =0A> Thank you for the= review :)=0A> =0A>> =0A>> Signature Calculation=0A>> In the last paragraph= of section 3.1, the user field should be included in =0A> the signature.= =0A>> =0A> =0A> =0A> I don't think so.=A0 The user field is a hint, and not= authoritative.=A0 Also, =0A> there's no way to get it into OAuth 1.0a.=A0 = If we want it there we have to =0A> put user in the path, query string, or = post args.=0A> =0A> =0A>> =0A>> Bearer Token Format=0A>> =0A>> According to= draft-ietf-oauth-v2-bearer, section 2.1, the credential in the =0A> Author= ization header is formatted as:=0A>> =0A>>> =0A>>> b64token =A0 =A0=3D 1*( = ALPHA / DIGIT /=0A>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"-" / = "." / "_" / =0A> "~" / "+" / "/" ) *"=3D"=0A>>> credentials =3D "Bearer" 1*= SP b64token=0A>> =0A>> for example:=0A>> =0A>> =0A>> Bearer mF_9.B5f-4.1JqM= =0A>>> =0A>> =0A>> Should the SASL Auth mechanism follow the same format? = =A0If so, the example =0A> in section 5.1 should be changed to:=0A>> =0A>> = auth=3DBearer=A0vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=3D=3D^A^A=0A>> =0A= >> This removes the quotes, and uses the same casing fror "Bearer" as =0A> = defined in the draft.=0A>> =0A> =0A> =0A> Removed the quotes.=A0 =0A> =0A> = =0A> Case is an interesting question.=A0 Authorization header scheme names = are case =0A> insensitive.=A0 I'm happy to make this consistent, but I rell= y don't want =0A> folks to get hung up on the examples rather than the actu= al spec.=A0 What's =0A> the right thing here, add a note?=0A> _____________= __________________________________=0A> Kitten mailing list=0A> Kitten@ietf.= org=0A> https://www.ietf.org/mailman/listinfo/kitten=0A> From internet-drafts@ietf.org Mon Aug 6 15:12:07 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5E811E8107; Mon, 6 Aug 2012 15:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b-cvNxI7ovW; Mon, 6 Aug 2012 15:12:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2764611E80F4; Mon, 6 Aug 2012 15:12:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120806221206.25659.5176.idtracker@ietfa.amsl.com> Date: Mon, 06 Aug 2012 15:12:06 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 22:12:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. Title : A SASL and GSS-API Mechanism for OAuth Author(s) : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-03.txt Pages : 22 Date : 2012-08-06 Abstract: OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses OAuth over the Simple Authentication and Security Layer (SASL) or the Generic Security Service Application Program Interface (GSS-API) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. Clients typically store the user's long term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a token. Tokens typically provided limited access rights and can be managed and revoked separately from the user's long-term credential (password). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wmills@yahoo-inc.com Mon Aug 6 15:17:14 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3768021F84FC for ; Mon, 6 Aug 2012 15:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.544 X-Spam-Level: X-Spam-Status: No, score=-17.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GBCZ98hzxXs for ; Mon, 6 Aug 2012 15:17:13 -0700 (PDT) Received: from nm21.bullet.mail.sp2.yahoo.com (nm21.bullet.mail.sp2.yahoo.com [98.139.91.91]) by ietfa.amsl.com (Postfix) with SMTP id 278C321F84F5 for ; Mon, 6 Aug 2012 15:17:13 -0700 (PDT) Received: from [98.139.91.70] by nm21.bullet.mail.sp2.yahoo.com with NNFMP; 06 Aug 2012 22:17:10 -0000 Received: from [98.139.91.18] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 06 Aug 2012 22:16:10 -0000 Received: from [127.0.0.1] by omp1018.mail.sp2.yahoo.com with NNFMP; 06 Aug 2012 22:16:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 558249.21270.bm@omp1018.mail.sp2.yahoo.com Received: (qmail 9943 invoked by uid 60001); 6 Aug 2012 22:16:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344291370; bh=URq0RINdg8WYGXsYEd6dHeig5WBjAi++u+7ywOKL9rs=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=P1CvRUFvG8x6Vyo53Us1MI1Lk81qJ2KFGetD5VVzyX43BFM3lBJB8L8+qGZVQpvnKYGPHIrpg+UJH8Ngq00ZOroRfOYwjcVPlXVMFCCz5Kilq1oAVImpn8Si4lafWwsfyPrDrsDEtRm+FG/FpD7J2WZH8127NSIncnOdCg0ec+s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=sDPOPu3xr4REyLT8lhszypPtM5YfxTr65OWqRIrdLMSfbpmK+6zpa22MMEih0KcaMJzOgGlXgxArgaMvWwH4Qth3da1NNwS8Vlsn9pWr2rYVKlXmvEoBNiI0cjqM5F+5m4b9dWm6XxNl/AzqhRQBXzSM5dfGfd/auWp1J5v9rr8=; X-YMail-OSG: ltqGHIoVM1l786OoWljVpkHHJN2iDFZEVDiJsDxjlSzn2sO fBRqmL5_rW6c9ieh2cbQcFQ4q0SIzXDn_3BOubnun83TA_hO71bnCIsiALPy Wp8kKdgQv_6Jkeu7KW14VdR.Gs1Ca9dU_JVuaoTrsiNHuTd.OK3wmQop_.9U 1.NbQNB4UKnTdkJokpb925OpjydfuAAWvzWTljB3Kkd6u7D.IcykoIx2PNgI ykYCC.Kj7JhuMvOSPpoltC5DvyK_1S_TBRZFxmJrTcxri8WNUn6gt8gUVkIe eGOhbpdQ_0A1.QrybT4UcaZtPjfHW24JhpSAkcE.LChdGZ0y2tkbEyoTQE54 ZU1ADZkZw3M2.q5VrkVWgfeaEenKoiOqKeC0bn_T2Is8y.yc4KHd.ayUByYv .e6_sGB7IJ_M05Bv6c94I1KXMY0mqlFIbJ7RWIdLgMZeDBYRXg2ctEq3GFm0 6Fl9QSuw- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Mon, 06 Aug 2012 15:16:10 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <20120806221206.25659.5176.idtracker@ietfa.amsl.com> Message-ID: <1344291370.8130.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Mon, 6 Aug 2012 15:16:10 -0700 (PDT) From: William Mills To: "kitten@ietf.org" In-Reply-To: <20120806221206.25659.5176.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-253924860-1344291370=:8130" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 22:17:14 -0000 ---1238014912-253924860-1344291370=:8130 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Fixing a couple of egregious errors in the examples.=0A=0A-bill=0A=0A=0A=0A= =0A>________________________________=0A> From: "internet-drafts@ietf.org" <= internet-drafts@ietf.org>=0A>To: i-d-announce@ietf.org =0A>Cc: kitten@ietf.= org =0A>Sent: Monday, August 6, 2012 3:12 PM=0A>Subject: [kitten] I-D Actio= n: draft-ietf-kitten-sasl-oauth-03.txt=0A> =0A>=0A>A New Internet-Draft is = available from the on-line Internet-Drafts directories.=0A>This draft is a = work item of the Common Authentication Technology Next Generation Working G= roup of the IETF.=0A>=0A>=A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : A SASL and G= SS-API Mechanism for OAuth=0A>=A0=A0=A0 Author(s)=A0 =A0 =A0 : William Mil= ls=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tim Showalter=0A>= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hannes Tschofenig=0A>= =A0=A0=A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-kitten-sasl-oauth-03.txt=0A>= =A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0 : 22=0A>=A0=A0=A0 Date=A0 =A0 =A0 =A0 = =A0 =A0 : 2012-08-06=0A>=0A>Abstract:=0A>=A0 OAuth enables a third-party a= pplication to obtain limited access to a=0A>=A0 protected resource, either= on behalf of a resource owner by=0A>=A0 orchestrating an approval interac= tion, or by allowing the third-party=0A>=A0 application to obtain access o= n its own behalf.=0A>=0A>=A0 This document defines how an application clie= nt uses OAuth over the=0A>=A0 Simple Authentication and Security Layer (SA= SL) or the Generic=0A>=A0 Security Service Application Program Interface (= GSS-API) to access a=0A>=A0 protected resource at a resource serve.=A0 The= reby, it enables schemes=0A>=A0 defined within the OAuth framework for non= -HTTP-based application=0A>=A0 protocols.=0A>=0A>=A0 Clients typically st= ore the user's long term credential.=A0 This does,=0A>=A0 however, lead to= significant security vulnerabilities, for example,=0A>=A0 when such a cre= dential leaks.=A0 A significant benefit of OAuth for=0A>=A0 usage in those= clients is that the password is replaced by a token.=0A>=A0 Tokens typica= lly provided limited access rights and can be managed=0A>=A0 and revoked s= eparately from the user's long-term credential=0A>=A0 (password).=0A>=0A>= =0A>The IETF datatracker status page for this draft is:=0A>https://datatrac= ker.ietf.org/doc/draft-ietf-kitten-sasl-oauth=0A>=0A>There's also a htmlize= d version available at:=0A>http://tools.ietf.org/html/draft-ietf-kitten-sas= l-oauth-03=0A>=0A>A diff from the previous version is available at:=0A>http= ://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-03=0A>=0A>=0A>I= nternet-Drafts are also available by anonymous FTP at:=0A>ftp://ftp.ietf.or= g/internet-drafts/=0A>=0A>_______________________________________________= =0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/= listinfo/kitten=0A>=0A>=0A> ---1238014912-253924860-1344291370=:8130 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Fixing a couple of egregious errors in the examples.
-bill

From: "internet-drafts@ietf.org" <inte= rnet-drafts@ietf.org>
To: i-d-announce@ietf.org
Cc:<= /span> kitten@ietf.org
Sent:= Monday, August 6, 2012 3:12 PM
S= ubject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-03.txt=

=0A
A New Internet-Draft is available from the o= n-line Internet-Drafts directories.
This draft is a work item of the Co= mmon Authentication Technology Next Generation Working Group of the IETF.
    Title          : A SASL = and GSS-API Mechanism for OAuth
    Author(s)   = ;   : William Mills
            &nbs= p;             Tim Showalter
   =                     &nbs= p; Hannes Tschofenig
    Filename      &nb= sp; : draft-ietf-kitten-sasl-oauth-03.txt
    Pages =         : 22
    Date    =         : 2012-08-06

Abstract:
  OAuth = enables a third-party application to obtain limited access to a
  = protected resource, either on behalf of a resource owner by
  orchestrating an approv= al interaction, or by allowing the third-party
  application to ob= tain access on its own behalf.

  This document defines how an = application client uses OAuth over the
  Simple Authentication and= Security Layer (SASL) or the Generic
  Security Service Applicati= on Program Interface (GSS-API) to access a
  protected resource at= a resource serve.  Thereby, it enables schemes
  defined wit= hin the OAuth framework for non-HTTP-based application
  protocols= .

  Clients typically store the user's long term credential.&n= bsp; This does,
  however, lead to significant security vulnerabil= ities, for example,
  when such a credential leaks.  A signif= icant benefit of OAuth for
  usage in those clients is that the pa= ssword is replaced by a token.
  Tokens typically provided limited access rights and can be managed
  and revoked separately= from the user's long-term credential
  (password).


The= IETF datatracker status page for this draft is:
https:= //datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth

There's = also a htmlized version available at:
http://tools.ietf.org/html/draft-i= etf-kitten-sasl-oauth-03

A diff from the previous version is availab= le at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-0= 3


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ie= tf.org/internet-drafts/

________________________________________= _______
Kitten mailing list
Kitten@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/kitten


---1238014912-253924860-1344291370=:8130-- From wmills@yahoo-inc.com Mon Aug 6 15:19:17 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E39721F850C for ; Mon, 6 Aug 2012 15:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.545 X-Spam-Level: X-Spam-Status: No, score=-17.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kflsjedtv-uO for ; Mon, 6 Aug 2012 15:19:16 -0700 (PDT) Received: from nm8-vm0.bullet.mail.ac4.yahoo.com (nm8-vm0.bullet.mail.ac4.yahoo.com [98.139.52.230]) by ietfa.amsl.com (Postfix) with SMTP id F1B5221F8504 for ; Mon, 6 Aug 2012 15:19:15 -0700 (PDT) Received: from [98.139.52.191] by nm8.bullet.mail.ac4.yahoo.com with NNFMP; 06 Aug 2012 22:19:10 -0000 Received: from [98.139.52.144] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 06 Aug 2012 22:19:10 -0000 Received: from [127.0.0.1] by omp1027.mail.ac4.yahoo.com with NNFMP; 06 Aug 2012 22:19:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 567127.90548.bm@omp1027.mail.ac4.yahoo.com Received: (qmail 55155 invoked by uid 60001); 6 Aug 2012 22:19:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344291549; bh=3f3aNaa/Knh2BCEo/y/2y2dkboqmekuTnxE4ik7PZbk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=rx9hSW0LPnV4p03vw9v+oodpnL1Aa9oa4UCWS+/pP64QKSMuvY1gHAENpkgh22lUEKPdRhthnduHPFmru3Dbfj/L3l106pzioJdbWUUMIJ7TnnmR1QWYDLSuUxXMqqZb8Npgxfodz9jN9MNKDJauIIMSt18cBXMzG4vTFx5TAu0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ojdsau/bQxeMzl4oARv7DtnRjlj7C514TuiTn+fGYs2NfpjbdTCTbTkJIlVvNY4cn2sHEE7Vag7qzseqg/H6R2u9N9Fwx4NKv3NTVmNlaNVCKDLfRBj5fvDqw8wgZ0xX0QRipcC5FbMfhMkn7o9ytVE2T5qyxsc+GKtKxndxvms=; X-YMail-OSG: BbpfXUwVM1l94yzii54_GCv2qebbn9.8PEiFfDd9MIre6_5 fnGoDsd4bEkfsg0oFoJ2CTLgrmuaMYlqDew28D.zXGQ8Q3VSASciseSG.shC SY9HDwKKEM20FeI6mfAmj6Vtjrx87_GQ_vbw_Fqp_V9BfvYBn6gO2kw5lSy5 cOv0mC1qQInyUteQys_Oq8Z6Wv.UoeSwxlD75RKxdM31jI3HRt8VDmaXomQB O62Fh013aG4412SCV5NOhAvdF8a6YxD1N0fCKzUcVUgHX8tTqJ0b6aMyvyXb _iMNckGd19rpLZM4Mi6vFUWezEqAC5rj6xdY.LjOgnfeYSaXbvfXNOCnvQHc FIo7143.aPluSGXIwPkw2aAc33Y0RemoAKaarfFOydHQnQ2zC3hWvyGgRPxm NYZfCIMPjX4fwtuLOYSyJNWFUtMl8sQ82GMz_n_TEW1_D4kKel8TNdBwK.MA BKg1T8gA- Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Mon, 06 Aug 2012 15:19:09 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: Message-ID: <1344291549.51188.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Mon, 6 Aug 2012 15:19:09 -0700 (PDT) From: William Mills To: Ryan Troll , "kitten@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1935884094-1221886370-1344291549=:51188" Subject: Re: [kitten] Comments on draft-ietf-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 22:19:17 -0000 --1935884094-1221886370-1344291549=:51188 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Not to be over anxious, but posted a new draft.=0A=0A=0A=0A>_______________= _________________=0A> From: Ryan Troll =0A>To: kitten@= ietf.org =0A>Sent: Monday, August 6, 2012 9:50 AM=0A>Subject: [kitten] Comm= ents on draft-ietf-kitten-sasl-oauth-02=0A> =0A>=0A>Reviewing the latest dr= aft, I had two comments:=0A>=0A>=0A>=0A>=0A>Signature Calculation=0A>In the= last paragraph of section 3.1, the user field should be included in the si= gnature.=0A>=0A>=0A>=0A>=0A>Bearer Token Format=0A>=0A>=0A>According to dra= ft-ietf-oauth-v2-bearer, section 2.1, the credential in the Authorization h= eader is formatted as:=0A>=0A>>=0A>>b64token =A0 =A0=3D 1*( ALPHA / DIGIT /= =0A>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"-" / "." / "_" / "~" /= "+" / "/" ) *"=3D"=0A>>credentials =3D "Bearer" 1*SP b64token=0A>=0A>for e= xample:=0A>=0A>=0A>Bearer mF_9.B5f-4.1JqM=0A>>=0A>>=0A>=0A>Should the SASL = Auth mechanism follow the same format? =A0If so, the example in section 5.1= should be changed to:=0A>=0A>=0A>auth=3DBearer=A0vF9dft4qmTc2Nvb3RlckBhbHR= hdmlzdGEuY29tCg=3D=3D^A^A=0A>=0A>=0A>This removes the quotes, and uses the = same casing fror "Bearer" as defined in the draft.=0A>=0A>=0A>=0A>=0A>-R=0A= >=0A>=0A>_______________________________________________=0A>Kitten mailing = list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/listinfo/kitten=0A>= =0A>=0A> --1935884094-1221886370-1344291549=:51188 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Not to be over anxious, but posted a new draft.

From: Ryan Troll <rtroll@goog= lers.com>
To: kitte= n@ietf.org
Sent: Mond= ay, August 6, 2012 9:50 AM
Subjec= t: [kitten] Comments on draft-ietf-kitten-sasl-oauth-02

=0A
Reviewing the latest draft,= I had two comments:


Signature C= alculation
In the last paragraph of section 3.1, the user fie= ld should be included in the signature.
=0A


Bearer Token Format

According to draft-ietf-oauth-v2-bearer, section 2.1, the= credential in the Authorization header is formatted as:
=0A

=
b64token    =3D 1*( ALPHA / DIGIT /
  &n= bsp;                    "= -" / "." / "_" / "~" / "+" / "/" ) *"=3D"
=0A
credentials =3D "Bea= rer" 1*SP b64token

for example:

Bearer mF_9.B5f-4.1JqM
=0A

=
Should the SASL Auth mechanism follow the same format?  = ;If so, the example in section 5.1 should be changed to:

=0A
= auth=3DBearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=3D=3D^A^A
=

This removes the quotes, and uses the same= casing fror "Bearer" as defined in the draft.

=0A
=
-R

=0A

________________________= _______________________
Kitten mailing list
Kitten@ietf.org
https:/= /www.ietf.org/mailman/listinfo/kitten


--1935884094-1221886370-1344291549=:51188-- From wmills@yahoo-inc.com Mon Aug 6 21:43:33 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B786C11E80E8 for ; Mon, 6 Aug 2012 21:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.546 X-Spam-Level: X-Spam-Status: No, score=-17.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uuV-dVWf-tT for ; Mon, 6 Aug 2012 21:43:32 -0700 (PDT) Received: from nm15.bullet.mail.bf1.yahoo.com (nm15.bullet.mail.bf1.yahoo.com [98.139.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id D904511E8087 for ; Mon, 6 Aug 2012 21:43:31 -0700 (PDT) Received: from [98.139.212.146] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 07 Aug 2012 04:43:31 -0000 Received: from [98.139.212.239] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 07 Aug 2012 04:43:31 -0000 Received: from [127.0.0.1] by omp1048.mail.bf1.yahoo.com with NNFMP; 07 Aug 2012 04:43:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 29326.91995.bm@omp1048.mail.bf1.yahoo.com Received: (qmail 28277 invoked by uid 60001); 7 Aug 2012 04:43:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344314610; bh=182d137vmXiV3sURcnzA5/sjQqawvjAwh+/hJrZO5nA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=B+dWIM5NCAy492JbDnp9C5meXoaeOcDmPDEjohQEP0D4UmFvankLoZEJ4uZIrUcHQe/MA6NNddtehA/QG594K5hlA7l3/en3iGLwyxdOw/Xt75MbkNyBHsG8ku7cIqTHAAY763iTLjg7VAcffPsaPxnWTRYxMHLp8B3oFOkGRtI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=aWnVjuIqlo1OHbZY4WiWlRLyYiNP5+2HBocFyf18yLdql1qwoAx0trsd1jwFBm49Dos6whCbZisz3nQ7BxYVhEKnge2r3CB4ReiNOklwt9eq1yobbp5TRWonrpyrHZRz32B8pcpYR7jrnN55W3jnVOR9PUm3Ht/ywG5t7d/aors=; X-YMail-OSG: xtWrSWoVM1m9mine4.1QCm4UV6qNrd1WRtVoZmh5BtctgjT g1SjTEpLSY3.OXczvXSlm7uM6QnTOQ_h1mC5kfMSO4q5rXoscN0vB3cufPhR k7Qz7Zcty9I4hwCtR692U62ZLv1oH2NpiTRmVViybBSN.WTvXGrIpNC82cJY M8DQIjuzcWbA4FBBroaU_Q1B7vnQuUIpR3Qj3JNR0ClitgHmfk9rK9zlsbo1 .nG7QTN1nibAm1ltMhJyvnLkYcaFIBmIu4NEq0xxJFqK2PudxVH7aS3zbXA2 YTjl44htUOZtm3LcGmDNCkkoJGHbUVJ0kZQo53vYhZuIXjI2guq9UBNjXu4v CXufIvNQ_O6cTBBfVLul2W_EUB01a_eLw6.W29HrEHvvO2Ijq0rYYA.4JyhV d8LrEj0WmmUNuRPldSCLeajiuPU0wzTncwZ0Bct4Whi7AZ_5zQrW1Wdo22iP 8NHiQGg-- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Mon, 06 Aug 2012 21:43:30 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <1344291549.51188.YahooMailNeo@web31810.mail.mud.yahoo.com> Message-ID: <1344314610.20298.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Mon, 6 Aug 2012 21:43:30 -0700 (PDT) From: William Mills To: William Mills , Ryan Troll , "kitten@ietf.org" In-Reply-To: <1344291549.51188.YahooMailNeo@web31810.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-523375871-1344314610=:20298" Subject: Re: [kitten] Comments on draft-ietf-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 04:43:34 -0000 ---1238014912-523375871-1344314610=:20298 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It is a fascinating thing to be implementing my own spec, and going back an= d referring to it and finding things to fix where I thought it was just fin= e...=0A=0A=0A=0A=0A>________________________________=0A> From: William Mill= s =0A>To: Ryan Troll ; "kitten@i= etf.org" =0A>Sent: Monday, August 6, 2012 3:19 PM=0A>Subj= ect: Re: [kitten] Comments on draft-ietf-kitten-sasl-oauth-02=0A> =0A>=0A>N= ot to be over anxious, but posted a new draft.=0A>=0A>=0A>=0A>>____________= ____________________=0A>> From: Ryan Troll =0A>>To: ki= tten@ietf.org =0A>>Sent: Monday, August 6, 2012 9:50 AM=0A>>Subject: [kitte= n] Comments on draft-ietf-kitten-sasl-oauth-02=0A>> =0A>>=0A>>Reviewing the= latest draft, I had two comments:=0A>>=0A>>=0A>>=0A>>=0A>>Signature Calcul= ation=0A>>In the last paragraph of section 3.1, the user field should be in= cluded in the signature.=0A>>=0A>>=0A>>=0A>>=0A>>Bearer Token Format=0A>>= =0A>>=0A>>According to draft-ietf-oauth-v2-bearer, section 2.1, the credent= ial in the Authorization header is formatted as:=0A>>=0A>>>=0A>>>b64token = =A0 =A0=3D 1*( ALPHA / DIGIT /=0A>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0"-" / "." / "_" / "~" / "+" / "/" ) *"=3D"=0A>>>credentials =3D "Be= arer" 1*SP b64token=0A>>=0A>>for example:=0A>>=0A>>=0A>>Bearer mF_9.B5f-4.1= JqM=0A>>>=0A>>>=0A>>=0A>>Should the SASL Auth mechanism follow the same for= mat? =A0If so, the example in section 5.1 should be changed to:=0A>>=0A>>= =0A>>auth=3DBearer=A0vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=3D=3D^A^A=0A>= >=0A>>=0A>>This removes the quotes, and uses the same casing fror "Bearer" = as defined in the draft.=0A>>=0A>>=0A>>=0A>>=0A>>-R=0A>>=0A>>=0A>>_________= ______________________________________=0A>>Kitten mailing list=0A>>Kitten@i= etf.org=0A>>https://www.ietf.org/mailman/listinfo/kitten=0A>>=0A>>=0A>>=0A>= _______________________________________________=0A>Kitten mailing list=0A>K= itten@ietf.org=0A>https://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> ---1238014912-523375871-1344314610=:20298 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It is a fascinating thing to be implementing my own spec, and going back = and referring to it and finding things to fix where I thought it was just f= ine...

=
From: William Mills <wmills@yahoo-inc.com>
To: Ryan Troll <rtroll@googlers.com>; "= kitten@ietf.org" <kitten@ietf.org>
Sent: Monday, August 6, 2012 3:19 PM
Subject: Re: [kitten] Comments on draft-= ietf-kitten-sasl-oauth-02

=0A
Not = to be over anxious, but posted a new draft.

=
From: Ryan Troll <rtroll@googlers.com>
= To: kitten@ietf.org
Sent: Monday, August 6, 2012 9:5= 0 AM
Subject: [kitten] = Comments on draft-ietf-kitten-sasl-oauth-02

=0A
Reviewing the latest draft, I had two comments:


Signature Calculation
In the last paragraph of section 3.1, the user field should be included i= n the signature.
=0A


Bearer Token= Format

According to draft-ietf-oauth-v2-bearer, section 2.1, the credential in the Auth= orization header is formatted as:
=0A

b64token &nbs= p;  =3D 1*( ALPHA / DIGIT /
        &nbs= p;              "-" / "." / "_" / "~" / = "+" / "/" ) *"=3D"
=0A
credentials =3D "Bearer" 1*SP b64token

for example:

Bearer = mF_9.B5f-4.1JqM
=0A


Should t= he SASL Auth mechanism follow the same format?  If so, the example in = section 5.1 should be changed to:

=0A
auth=3DBearer vF9d= ft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=3D=3D^A^A

<= /div>
This removes the quotes, and uses the same casing fror "Bearer" a= s defined in the draft.

=0A

-R
=

=0A

_______________________________________________=
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
<= br>

_________= ______________________________________
Kitten mailing list
Kitten@ietf.org=
https://www.ietf.org/mailman/listinfo/kitten


= ---1238014912-523375871-1344314610=:20298-- From rtroll@google.com Thu Aug 9 14:28:59 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0900321F86E0 for ; Thu, 9 Aug 2012 14:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2itxFZIHn1vn for ; Thu, 9 Aug 2012 14:28:57 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 411B921F860F for ; Thu, 9 Aug 2012 14:28:57 -0700 (PDT) Received: by qadz3 with SMTP id z3so560099qad.10 for ; Thu, 09 Aug 2012 14:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=/f6WXIdjO+waCa+m0B5VQ+vyRqa6Q4xMyOhViqtNKts=; b=XoyzRn4TZtk3NnU6siYySNWiNJDUuYNXVBaYDXCHkRBE/BynwG8t5jTxzeOowL3iWM 3rlIaGdFbvfsGoZa1vDaSQ558PfHW4KXWcWcwfV5WzaDEU800Hqhccz3P4VJTKk6isN6 gAIAfe80+mrMLH4xPNhvNLuBZRw0jU9WQyb0o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=/f6WXIdjO+waCa+m0B5VQ+vyRqa6Q4xMyOhViqtNKts=; b=Io+E8r9Zidd/exN6hYGnKktZggFhT1ctkoHdisRM9WgRC7rdJ6lfJvF7qE8aYvQelI 6KJYadj8KUX1K70l6Z7vra5G64GBWZMd3k6nePAgS7VeK6SkI1P8Dr9JE74+6NYwtfTD aCk5r75Z8AQ/CROyNjFz3a3BMgYCPWQ+zMc9enJSg7BDLvQSIsM4jjrjDGAIXtwxBvsn Iz2mxgrcINXpWcqMD06xRXcHQF7k7guDy1mDOdcAfUOXQNPbJ+NgBSWUjhaOjuiX4iiR iV8yVbD1g7TM65nk2Z8t+c1Qwgj+DQjkGhDr+n19KaXvV1ph4rjVdodFFRUD9i5vcXsa FD+Q== Received: by 10.229.105.141 with SMTP id t13mr326311qco.118.1344547736744; Thu, 09 Aug 2012 14:28:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.105.141 with SMTP id t13mr326300qco.118.1344547736590; Thu, 09 Aug 2012 14:28:56 -0700 (PDT) Received: by 10.229.201.230 with HTTP; Thu, 9 Aug 2012 14:28:56 -0700 (PDT) Date: Thu, 9 Aug 2012 14:28:56 -0700 Message-ID: From: Ryan Troll To: kitten@ietf.org Content-Type: multipart/alternative; boundary=00235429cfac39194304c6dbea5b X-System-Of-Record: true X-Gm-Message-State: ALoCoQmwaPE13y0NnmK7pqvETuPhlLG1htiFyheuiIPluxLRGBRr43Kydrl1CP1Dw9dFx4mexdVSwhZOpKpu+hXaJLzT0cV7eeLBwfntXE6sNRMHmzVyfJ1a/vVci4Woo/TOMAgyhGqc8D/mZMSYN90iPmqKmZvCS4BUioNqj3OMk37WdIW7ATOjewi0e0aUaP2ul2q1FhoL Subject: [kitten] Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 21:28:59 -0000 --00235429cfac39194304c6dbea5b Content-Type: text/plain; charset=ISO-8859-1 All, How close does the group feel draft-ietf-kitten-sasl-oauth-03is to being submitted to the IESG? We are preparing to launch OAuth2 support in IMAP and SMTP. Our current implementation conforms to this document, with one minor exception - we're using a slightly different capability name, in order to allow us to launch prior to this document achieving RFC status. (Once the RFC is published, we'll add support for it -- we're taking this approach in case there are major changes prior to publication.) -R --00235429cfac39194304c6dbea5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

How close does the group feel draft-ietf-kitten-sasl-oa= uth-03 is to being submitted to the IESG?

We are= preparing to launch OAuth2 support in IMAP and SMTP. =A0Our current implem= entation conforms to this document, with one minor exception - we're us= ing a slightly different capability name, in order to allow us to launch pr= ior to this document achieving RFC status. =A0(Once the RFC is published, w= e'll add support for it -- we're taking this approach in case there= are major changes prior to publication.)

-R
--00235429cfac39194304c6dbea5b-- From wmills@yahoo-inc.com Thu Aug 9 14:47:05 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE02721F86F9 for ; Thu, 9 Aug 2012 14:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.547 X-Spam-Level: X-Spam-Status: No, score=-17.547 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ofQhjkjKyMu for ; Thu, 9 Aug 2012 14:47:05 -0700 (PDT) Received: from nm14.bullet.mail.bf1.yahoo.com (nm14.bullet.mail.bf1.yahoo.com [98.139.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id BEBAA21F86EE for ; Thu, 9 Aug 2012 14:47:04 -0700 (PDT) Received: from [98.139.212.144] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 09 Aug 2012 21:47:04 -0000 Received: from [98.139.212.241] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 09 Aug 2012 21:47:04 -0000 Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 09 Aug 2012 21:47:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 72507.36177.bm@omp1050.mail.bf1.yahoo.com Received: (qmail 39838 invoked by uid 60001); 9 Aug 2012 21:47:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344548823; bh=XWT+Ipilz5bU9yEXUMdD8zapStlDZTfe/Xys7WW1Ow0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=hk+PwSwL0HqDTTUmcl4wxTPz+yFGd36sCB8D6syYTpnb5meNYMHsu2mlVEy0pFMp4SLtRNNaARy2EViTRruxSVqszeUHA20QhiqObbvCnalpHhvRMqpSchgdUbatEL03ccLf7psvDEe1ZApKD2LQj2LwQZvyqrzvX4IacqMm0Ak= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=iVoLoxFsB1kGLf2sRj/n0TDcmPdAq0nXFc9igdSpUhXP3EgPUdOW8NgWYZ4a4mMwo4zP3e9VHn0PfftXbsjfjpkQFDIef+GzwOW6Mj2RUpiAgm4Br27Zftw0lcuszu5FqvWYXmYMW9WCxwSUrKxrkHIqCVuvB5OwZSYXp0Jd2aM=; X-YMail-OSG: oOjAtQ8VM1kJUltA2us9nu2IzKLUtoD3jYTZVhM5CY3MoPU hCHsS30zXOcLWxv6z.vr.Ck6wTH3OMKqDMXgpODSOv.ksQ8_hvda8kO3xMEX 72nsj1P.5CZ..HnjriXW9GGbIMr7KuY1KqtMh3A5qKXdiaE.dtQC38oeE4Rd NrlRjzFnZsixFh2tZHzmxkudSKABTCMe5bGwZOcgQ.Pq8RHFdhoO.HZlN4Xm q5KP89F10rzo8yKD_2kaB_UIBQHgIdlGeKNfa840w7ytyzQ.mAwH64YhUINB 33nydDomV878axM94is35mHOCBaM_Rd7i3N4XL29i5mE8q7qpB_OD3oQA.QJ EYYs.dHWyQIsM7jiP0y..BWk_qKyrjuvdEp_g_HoFTfWecebwKkSlkg4H2ux Bcca4GffFtGjw2gumSvGIZDaikpnnP1at6Nv55QPN7LgtJdOh.P3Q4mB0d4a PSGMegr0- Received: from [209.131.62.113] by web31808.mail.mud.yahoo.com via HTTP; Thu, 09 Aug 2012 14:47:03 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: Message-ID: <1344548823.23915.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 14:47:03 -0700 (PDT) From: William Mills To: Ryan Troll , "kitten@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-961424077-1344548823=:23915" Subject: Re: [kitten] Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 21:47:05 -0000 --258328648-961424077-1344548823=:23915 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable There hasn't been a lot of action in any substantive way on the list on thi= s draft, and I think it's pretty well baked.=A0 A working implementation is= going to go a long way to nailing this down.=0A=0AAnyone out there with an= y significant objections or proposed should speak up "real soon now".=A0 = =0A=0A=0AI'm still working on the Cyrus SASL reference implementation plugi= n, and it's getting close though I have some bugs to quash.=A0 It'll be int= eresting to test against a production service.=0A=0A=0A-bill=0A=0A=0A=0A=0A= >________________________________=0A> From: Ryan Troll =0A>To: kitten@ietf.org =0A>Sent: Thursday, August 9, 2012 2:28 PM=0A>Subj= ect: [kitten] Status of draft-ietf-kitten-sasl-oauth?=0A> =0A>=0A>All,=0A>= =0A>=0A>How close does the group feel draft-ietf-kitten-sasl-oauth-03 is to= being submitted to the IESG?=0A>=0A>=0A>=0A>We are preparing to launch OAu= th2 support in IMAP and SMTP. =A0Our current implementation conforms to thi= s document, with one minor exception - we're using a slightly different cap= ability name, in order to allow us to launch prior to this document achievi= ng RFC status. =A0(Once the RFC is published, we'll add support for it -- w= e're taking this approach in case there are major changes prior to publicat= ion.)=0A>=0A>=0A>-R=0A>_______________________________________________=0A>K= itten mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/listi= nfo/kitten=0A>=0A>=0A> --258328648-961424077-1344548823=:23915 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
There = hasn't been a lot of action in any substantive way on the list on this draf= t, and I think it's pretty well baked.  A working implementation is go= ing to go a long way to nailing this down.

Anyone out there with an= y significant objections or proposed should speak up "real soon now". =

I'm still working on the Cyrus SASL reference i= mplementation plugin, and it's getting close though I have some bugs to qua= sh.  It'll be interesting to test against a production service.

= -bill

From: Ryan Troll <rtroll@googlers.com>
To: kitten@ietf.org
Sent: Thursday, August 9, 2012 2:28 PM Subject: [kitten] Statu= s of draft-ietf-kitten-sasl-oauth?

=0A
All,

How close does the group feel draft-ietf-kitten-sasl-oauth-03 is to being submi= tted to the IESG?

We are preparing to launch OAuth2 = support in IMAP and SMTP.  Our current implementation conforms to this= document, with one minor exception - we're using a slightly different capa= bility name, in order to allow us to launch prior to this document achievin= g RFC status.  (Once the RFC is published, we'll add support for it --= we're taking this approach in case there are major changes prior to public= ation.)
=0A

-R
=0A

____________= ___________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten


--258328648-961424077-1344548823=:23915-- From simon@josefsson.org Thu Aug 9 16:24:24 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6733321F861B for ; Thu, 9 Aug 2012 16:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpSvtXOQ-Cww for ; Thu, 9 Aug 2012 16:24:24 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 896D721F861A for ; Thu, 9 Aug 2012 16:24:23 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q79NOGqH010187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Aug 2012 01:24:17 +0200 From: Simon Josefsson To: William Mills References: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120809:wmills@yahoo-inc.com::+SqFLYZsiexuI8JI:BkFI X-Hashcash: 1:22:120809:kitten@ietf.org::eMSnaklzKf8HUAb+:7lYW X-Hashcash: 1:22:120809:rtroll@googlers.com::gybiqSx85K68HfSs:CjFr Date: Fri, 10 Aug 2012 01:24:12 +0200 In-Reply-To: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> (William Mills's message of "Thu, 9 Aug 2012 14:47:03 -0700 (PDT)") Message-ID: <87hasbd4yq.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 23:24:24 -0000 William Mills writes: > There hasn't been a lot of action in any substantive way on the list > on this draft, and I think it's pretty well baked.  A working > implementation is going to go a long way to nailing this down. > > Anyone out there with any significant objections or proposed should > speak up "real soon now".  I have reviewed the -03 document, and I believe there are some major issues with it. MAJOR: * The protocol does not appear to be compatible with the GS2 framing, thus the GSS-API mechanism the document defines would not be wire-compatible with the SASL mechanism. The SASL packets needs to use the GS2 header to be compatible. The examples reinforces my readings, they don't begin with the GS2 header. Compare the SCRAM, OPENID and SAML20 mechanism to see how this should be done. * I don't see where the mechanism transfers the SASL authorization identity, which is required. This would be done by the GS2 header. * I don't follow how the channel binding data is integrity protected. Unless I'm missing some keying, this seems to open up for a MITM to fake channel binding. Section 3.2: In the OAUTH-PLUS mechanism the server examines the channel binding data, extracts the channel binding unique prefix, and extracts the raw channel biding data based on the channel binding type used. It then computes it's own copy of the channel binding payload and compares that to the payload sent by the client in the cbdata key/ value. Those two must be equal for channel binding to succeed. Presumably the client is not authenticated when this is sent, so the server might as well be talking to an attacker, which sends its own channel binding data. I'm not sure I see how OAuth with bearer tokens could support channel bindings at all? * Section 3.4 seems confusing. Quoting: If the specification for the underlying authorization scheme requires a security layer, such as TLS [RFC5246], the server SHOULD only offer a mechanism where channel binding can be enabled. Should "authorization scheme" be "application protocol"? Quoting further: The channel binding data is computed by the client based on it's choice of preferred channel binding type. I think you want something similar to section 5.2 in RFC 5802 instead, to leave the choise of preferred channel binding type up to the application protocol profile (or resume back to a default). If the raw channel binding data is 500 bytes or larger then a SHA-1 [RFC3174] hash of the raw channel binding data is computed. SHA-1? This opens up for hash agility concerns. If the client is using tls-unique for a channel binding then the raw channel binding data equals the first TLS finished message. There is subtlety with renegotiation here, I suggest to quote RFC 5929 instead. /Simon From simon@josefsson.org Thu Aug 9 16:28:43 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412E421F8652 for ; Thu, 9 Aug 2012 16:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQqvfaA5KUvo for ; Thu, 9 Aug 2012 16:28:42 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 817C721F864A for ; Thu, 9 Aug 2012 16:28:42 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q79NSbEK010402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Aug 2012 01:28:38 +0200 From: Simon Josefsson To: William Mills References: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> <87hasbd4yq.fsf__31719.1455084414$1344554674$gmane$org@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120809:kitten@ietf.org::wRwXzh/nT3FUf1gC:3RUP X-Hashcash: 1:22:120809:wmills@yahoo-inc.com::IJichBDizSYBS3KT:I8XG Date: Fri, 10 Aug 2012 01:28:34 +0200 In-Reply-To: <87hasbd4yq.fsf__31719.1455084414$1344554674$gmane$org@latte.josefsson.org> (Simon Josefsson's message of "Fri, 10 Aug 2012 01:24:12 +0200") Message-ID: <87d32zd4rh.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 23:28:43 -0000 Simon Josefsson writes: > The channel binding data is computed by the client based on it's > choice of preferred channel binding type. > > I think you want something similar to section 5.2 in RFC 5802 instead, Sorry, that should be RFC 5801. Alternatively, see section 6.1 in RFC 5802. /Simon From wmills@yahoo-inc.com Thu Aug 9 16:48:21 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DF821F867F for ; Thu, 9 Aug 2012 16:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.549 X-Spam-Level: X-Spam-Status: No, score=-17.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKNTxnZI7gvb for ; Thu, 9 Aug 2012 16:48:20 -0700 (PDT) Received: from nm6-vm0.bullet.mail.sp2.yahoo.com (nm6-vm0.bullet.mail.sp2.yahoo.com [98.139.91.206]) by ietfa.amsl.com (Postfix) with ESMTP id 746FC21F867D for ; Thu, 9 Aug 2012 16:48:20 -0700 (PDT) Received: from [98.139.91.61] by nm6.bullet.mail.sp2.yahoo.com with NNFMP; 09 Aug 2012 23:48:17 -0000 Received: from [98.139.91.41] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 09 Aug 2012 23:48:17 -0000 Received: from [127.0.0.1] by omp1041.mail.sp2.yahoo.com with NNFMP; 09 Aug 2012 23:48:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 119352.37880.bm@omp1041.mail.sp2.yahoo.com Received: (qmail 71770 invoked by uid 60001); 9 Aug 2012 23:48:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344556096; bh=1duV3pFSXLHMbCTLdiE3qRHnUvkevC/bgVSEnGgdwFY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AzPOth3MSrrEjHJmRw4ARhIUznZ3ldpJj+w+Mb7srJjcu3aFoFMy0IWZO9+8Esr0US73acRomAuOjUEw+yX/bOjJ1BBGC8AcsFgZGB9xG3DgmNxk5ZAo0PDpF1SHtJAK6wfrJ+JU8cV3rAgxrEcy3HjD29cxBowjobxW6lvnMGU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=W63zcs+KNkjwuytcmPq87CSPFki0XRjzjT/dTmO5pzEub3WF9WiqCjf8I0k22Xc0oQN1qZBZGUYzuU0m5AKlToLqBf1gKGPGl8P5ebEUArKhOMR3rCZRAfN7vmBawQ37bmc7NECIMkt1Pg7Sd1ote3pG8i1ExB8Lmvy77Adov5w=; X-YMail-OSG: wWUZYesVM1nMg50i0Yu8kyxIs8fej7ZyZgy0DzYXRF92wGD x_aovNpg.qTtdZka2OmjJmHjkbZj2075W4.Uw60CwUHM95Rxj7__sJZm867g 8y5GUiXEgT81XLduryBRqKSCIGFEhMEwdcP4xqMDofslPAeG7BsfA.Zkmpsm tUBpIaV6tJ5WRFyhhp8S5GzXqv_1vAttCoxde_ht4dqPJScBKZh_XGtb7XLR stn89So4sNWORHJNXsvbWSc7WwX4_VYWrHxLxhQRKx4RYMb.ZRPJGI1S.4jh gHixVT9wnVs5A1Dv.He6Bw9lsP00mKq_oO5ckFojc1phDHIAGgXjOkeQSF6O Lniya9zLYp56q5I1zNhkAgjHFaWXT4luoBG3pfV.IE1kwL7ewDDAAg7eYTY1 p_NtlKZkN5tJNDSXFy8pYcRL9xvhWNRp.A16KxtkkbOMGB9S9DqMOEc7_Kwu Qm.TLReY- Received: from [209.131.62.113] by web31813.mail.mud.yahoo.com via HTTP; Thu, 09 Aug 2012 16:48:16 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> <87hasbd4yq.fsf@latte.josefsson.org> Message-ID: <1344556096.48347.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 16:48:16 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87hasbd4yq.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 23:48:21 -0000 Simon,=0A=0AThanks for the review!=0A=0ARe: SASL entities: That's covered i= n 3.2.1 I hope.=0A=0A3.2.1.=A0=A0Mapping to SASL Identities =0A=0ASome OAut= h mechanisms can provide both an authorization identity and an authenticati= on identity.=A0=A0An example of this is OAuth 1.0a [RFC5849] where the cons= umer key (oauth_consumer_key) identifies the entity using the token which e= quates to the SASL authentication identity, and is authenticated using the = shared secret.=A0=A0The authorization identity in the OAuth 1.0a case is ca= rried in the token (per the requirement above), which SHOULD be validated i= ndependently. The server MAY use a consumer key, a value derived from it, o= r other comparable identity in the OAuth authorization scheme as the SASL a= uthentication identity.=A0=A0If an appropriate authentication identity is n= ot available the server MUST use the authorization identity as the authenti= cation identity.=0A=0A=0ARe: GS2 header:=A0=A0 I'll go read up on this, I h= ope it's easy :)=0A=0A=0A=0ARe: Channel Binding:=A0 =0A=0A=0AQuite frankly = I'd like to rip it out, but I was told originally it was required.=A0 I thi= nk the stance in the group on this has changed, but I'm not sure.=A0 It is = certainly vulnerable to MITM in the Bearer case.=A0 An option would be to l= imit CB to usage when we have an auth profile that supports signing.=A0 Doe= s it need to stay at this point?=0A=0ARegards,=0A=0A-bill=0A=0A>___________= _____________________=0A> From: Simon Josefsson =0A>To= : William Mills =0A>Cc: Ryan Troll ; "kitten@ietf.org" =0A>Sent: Thursday, August 9, 201= 2 4:24 PM=0A>Subject: Re: Status of draft-ietf-kitten-sasl-oauth?=0A> =0A>W= illiam Mills writes:=0A>=0A>> There hasn't been a lo= t of action in any substantive way on the list=0A>> on this draft, and I th= ink it's pretty well baked.=A0 A working=0A>> implementation is going to go= a long way to nailing this down.=0A>>=0A>> Anyone out there with any signi= ficant objections or proposed should=0A>> speak up "real soon now".=A0=0A>= =0A>I have reviewed the -03 document, and I believe there are some major=0A= >issues with it.=0A>=0A>MAJOR:=0A>=0A>* The protocol does not appear to be = compatible with the GS2 framing,=0A>=A0 thus the GSS-API mechanism the docu= ment defines would not be=0A>=A0 wire-compatible with the SASL mechanism.= =A0 The SASL packets needs to=0A>=A0 use the GS2 header to be compatible.= =A0 The examples reinforces my=0A>=A0 readings, they don't begin with the G= S2 header.=A0 Compare the SCRAM,=0A>=A0 OPENID and SAML20 mechanism to see = how this should be done.=0A>=0A>* I don't see where the mechanism transfers= the SASL authorization=0A>=A0 identity, which is required.=A0 This would b= e done by the GS2 header.=0A>=0A>* I don't follow how the channel binding d= ata is integrity protected.=0A>=A0 Unless I'm missing some keying, this see= ms to open up for a MITM to=0A>=A0 fake channel binding.=A0 Section 3.2:=0A= >=0A>=A0 =A0 In the OAUTH-PLUS mechanism the server examines the channel bi= nding=0A>=A0 =A0 data, extracts the channel binding unique prefix, and extr= acts the=0A>=A0 =A0 raw channel biding data based on the channel binding ty= pe used.=A0 It=0A>=A0 =A0 then computes it's own copy of the channel bindin= g payload and=0A>=A0 =A0 compares that to the payload sent by the client in= the cbdata key/=0A>=A0 =A0 value.=A0 Those two must be equal for channel b= inding to succeed.=0A>=0A>=A0 Presumably the client is not authenticated wh= en this is sent, so the=0A>=A0 server might as well be talking to an attack= er, which sends its own=0A>=A0 channel binding data.=0A>=0A>=A0 I'm not sur= e I see how OAuth with bearer tokens could support channel=0A>=A0 bindings = at all?=0A>=0A>* Section 3.4 seems confusing.=A0 Quoting:=0A>=0A>=A0 =A0 If= the specification for the underlying authorization scheme requires=0A>=A0 = =A0 a security layer, such as TLS [RFC5246], the server SHOULD only offer= =0A>=A0 =A0 a mechanism where channel binding can be enabled.=0A>=0A>=A0 Sh= ould "authorization scheme" be "application protocol"?=0A>=0A>=A0 Quoting f= urther:=0A>=0A>=A0 =A0 The channel binding data is computed by the client b= ased on it's=0A>=A0 =A0 choice of preferred channel binding type.=0A>=0A>= =A0 I think you want something similar to section 5.2 in RFC 5802 instead,= =0A>=A0 to leave the choise of preferred channel binding type up to the=0A>= =A0 application protocol profile (or resume back to a default).=0A>=0A>=A0 = =A0 If the raw channel binding data is 500=0A>=A0 =A0 bytes or larger then = a SHA-1 [RFC3174] hash of the raw channel=0A>=A0 =A0 binding data is comput= ed.=0A>=0A>=A0 SHA-1?=A0 This opens up for hash agility concerns.=0A>=0A>= =A0 =A0 If the client is using tls-unique for a channel binding then the ra= w=0A>=A0 =A0 channel binding data equals the first TLS finished message.=0A= >=0A>=A0 There is subtlety with renegotiation here, I suggest to quote RFC = 5929=0A>=A0 instead.=0A>=0A>/Simon=0A>=0A>=0A> From wmills@yahoo-inc.com Thu Aug 9 17:16:59 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A94311E8099 for ; Thu, 9 Aug 2012 17:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.55 X-Spam-Level: X-Spam-Status: No, score=-17.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHpmTNfFOAKy for ; Thu, 9 Aug 2012 17:16:58 -0700 (PDT) Received: from nm17-vm0.bullet.mail.ac4.yahoo.com (nm17-vm0.bullet.mail.ac4.yahoo.com [98.139.53.208]) by ietfa.amsl.com (Postfix) with ESMTP id 463B911E808A for ; Thu, 9 Aug 2012 17:16:58 -0700 (PDT) Received: from [98.139.52.188] by nm17.bullet.mail.ac4.yahoo.com with NNFMP; 10 Aug 2012 00:16:55 -0000 Received: from [98.139.52.149] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 10 Aug 2012 00:16:55 -0000 Received: from [127.0.0.1] by omp1032.mail.ac4.yahoo.com with NNFMP; 10 Aug 2012 00:16:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 144866.81538.bm@omp1032.mail.ac4.yahoo.com Received: (qmail 53458 invoked by uid 60001); 10 Aug 2012 00:16:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344557814; bh=avWzkUdv2UO139QvYy/5REwmXjFe9JSAUoPvc7BvLA0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=taaAEq3SzdY9CQdxRkGhkJe6SRPEmkakCeFdCybIXqTsn/I6qrCN2Komvi26gQfgGMpaHFa/npKj1azSKczu5ADhEg4G61vjSidraKvCUA6HPOx3HVckfQVr6FLn54o5s5YB8H5JJXDavxGq1f71czZF3GdwJs89pOaCouy6a5Q= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HlBdc3dr2eFdXjxHjCAtUI8awLqV3KTTqinHXZtP0bkwsajZcCsfEgF8gY3RaL+9ZfhKy/enrBOG/34fnDYweU6OmFbYNV5y1F1bPmICrjEvO6y3z6J1f5s2Yh9anCyvaWV3pQaB+Kzf02TVYSXSy0eiVNgeYZOKBkasPf/KbkU=; X-YMail-OSG: D3lZUAUVM1nSAh41gcF7RfnDYkAYbOW4M5d3.EgmtiTzx2. A19UAbxEntATeEPtQSZ3Ubq.4Tm53Vb3cYaYdaej7UlY1tu1FjSiu6c1WDz7 GVZdQt.VAkBoqkyJ_ZYjCqsT2GU3WE3BRX298Uvuexmk1EbRfBht9J0O0DCV LPuQdZRIdtl.L8mow0iUfPW.sleI8BD.v2EAhDULSG8QcFfuv51sterUtzBF G8_NRD8N5SL0mXec3aFzjIe2SeNkqhLAjLHMGAduvijr1Gk6GSAkBQq8HaUU fe2_TGrRPeuTkZfZpdKr98Pktj.Aj_TD5m9KrpbsLdp9B1j2GpJ7uVJSoKee xht7LfKnUeao3ZewZbzPdMm7CxIdOYzojC66UoGUrO4IPVU514RO.wbUxtlv pSj0RrgDGX57B.w40rItluAriDRqYmEbx_2Qu6LxYFvx5cMkSlNj29aoSr2O oIEqkiw-- Received: from [209.131.62.113] by web31805.mail.mud.yahoo.com via HTTP; Thu, 09 Aug 2012 17:16:54 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> <87hasbd4yq.fsf__31719.1455084414$1344554674$gmane$org@latte.josefsson.org> <87d32zd4rh.fsf@latte.josefsson.org> Message-ID: <1344557814.46045.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 17:16:54 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87d32zd4rh.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 00:16:59 -0000 So in reading http://tools.ietf.org/html/rfc5801 and teh SAML SASL spec it = looks like the gs2-header must appear by itself in a message?=A0 Since we d= on't have a challenge response=A0 model here it sounds like we have to have= the following logic:=0A=0A1)=A0=A0=A0 client sends gs2-header=0A2)=A0=A0= =A0 server sends an empty reply or fail here if auth won't be permitted bec= ause CB is required.=0A3)=A0=A0=A0 client sends OAUTH mechanism auth reques= t=0A4)=A0=A0=A0 server replies=0A=0ASo for the non channel binding case we'= re forced into an empty round trip.=A0 Correct?=0A=0A-bill=0A=0A=0A=0A=0A--= --- Original Message -----=0A> From: Simon Josefsson = =0A> To: William Mills =0A> Cc: "kitten@ietf.org" =0A> Sent: Thursday, August 9, 2012 4:28 PM=0A> Subject: Re: = Status of draft-ietf-kitten-sasl-oauth?=0A> =0A> Simon Josefsson writes:=0A> =0A>> =A0 =A0 The channel binding data is computed= by the client based on it's=0A>> =A0 =A0 choice of preferred channel bind= ing type.=0A>> =0A>> =A0 I think you want something similar to section 5.2= in RFC 5802 instead,=0A> =0A> Sorry, that should be RFC 5801.=A0 Alternati= vely, see section 6.1 in RFC 5802.=0A> =0A> /Simon=0A> From simon@josefsson.org Thu Aug 9 22:42:28 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9B321F84F4 for ; Thu, 9 Aug 2012 22:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9EpG29MVC+K for ; Thu, 9 Aug 2012 22:42:27 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5172221F84EE for ; Thu, 9 Aug 2012 22:42:26 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7A5gKg4028062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Aug 2012 07:42:22 +0200 From: Simon Josefsson To: William Mills References: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> <87hasbd4yq.fsf@latte.josefsson.org> <1344556096.48347.YahooMailNeo__48411.905745934$1344556115$gmane$org@web31813.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120810:wmills@yahoo-inc.com::q7SdVed8i6Ka+fg6:6eDW X-Hashcash: 1:22:120810:kitten@ietf.org::FPF2S8mJn+WOkgv2:AKbV Date: Fri, 10 Aug 2012 07:42:17 +0200 In-Reply-To: <1344556096.48347.YahooMailNeo__48411.905745934$1344556115$gmane$org@web31813.mail.mud.yahoo.com> (William Mills's message of "Thu, 9 Aug 2012 16:48:16 -0700 (PDT)") Message-ID: <878vdncngm.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 05:42:28 -0000 William Mills writes: > Re: Channel Binding:  > > > Quite frankly I'd like to rip it out, but I was told originally it was > required.  I think the stance in the group on this has changed, but > I'm not sure.  It is certainly vulnerable to MITM in the Bearer case.  > An option would be to limit CB to usage when we have an auth profile > that supports signing.  Does it need to stay at this point? Yes, I believe CB should only be advertised/used when it actually provides some security. /Simon From simon@josefsson.org Thu Aug 9 22:49:09 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4851411E80E8 for ; Thu, 9 Aug 2012 22:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHGtJRkQOo9o for ; Thu, 9 Aug 2012 22:49:08 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5A68511E80DF for ; Thu, 9 Aug 2012 22:49:08 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7A5msIB028296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Aug 2012 07:48:56 +0200 From: Simon Josefsson To: William Mills References: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> <87hasbd4yq.fsf__31719.1455084414$1344554674$gmane$org@latte.josefsson.org> <87d32zd4rh.fsf@latte.josefsson.org> <1344557814.46045.YahooMailNeo__28311.2241108485$1344557830$gmane$org@web31805.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120810:wmills@yahoo-inc.com::tFhvTH9RqIJnC9ys:6lre X-Hashcash: 1:22:120810:kitten@ietf.org::6+QKWVL9qxIqHom3:AShV Date: Fri, 10 Aug 2012 07:48:51 +0200 In-Reply-To: <1344557814.46045.YahooMailNeo__28311.2241108485$1344557830$gmane$org@web31805.mail.mud.yahoo.com> (William Mills's message of "Thu, 9 Aug 2012 17:16:54 -0700 (PDT)") Message-ID: <874nobcn5o.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 05:49:09 -0000 William Mills writes: > So in reading http://tools.ietf.org/html/rfc5801 and teh SAML SASL > spec it looks like the gs2-header must appear by itself in a message?  > Since we don't have a challenge response  model here it sounds like we > have to have the following logic: > > 1)    client sends gs2-header > 2)    server sends an empty reply or fail here if auth won't be permitted because CB is required. > 3)    client sends OAUTH mechanism auth request > 4)    server replies > > So for the non channel binding case we're forced into an empty round trip.  Correct? No, the gs2-header can be a prefix of other data, it doesn't have to be its own message. Look at the SCRAM/OPENID/SAML20 protocol examples. Thus OAUTH could look like this (ABNF): initial-client-response := gs2-header oath-data oath-data := ... The important part is that the wire syntax of the OAUTH SASL mechanism starts with the gs2-header, and that it has the same semantics as GS2. Note that the gs2-header transfers the SASL authorization identity which is required by the SASL framework, solving that problem as well. /Simon From alexey.melnikov@isode.com Fri Aug 10 02:29:03 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C7C21F855E for ; Fri, 10 Aug 2012 02:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kg5cpIp8AfMk for ; Fri, 10 Aug 2012 02:29:02 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8EF21F853D for ; Fri, 10 Aug 2012 02:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1344590938; d=isode.com; s=selector; i=@isode.com; bh=Pnit2t2Py6Shs1Tb2sLiEf4NPndSbfgekYpauFQnCDI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Z9l1Wv1bBdJqUIt7r2zk1zmTnEbtUrSKIZSf4WF68yvmF2Ozg9P6140MKZTtaTWvrK+gl/ nSDunNJ/azs+oRaNdmGwoo+oKocPzjDWNjwBEDaZbtBiWX+Kp19qXQtiXuKCHc4XDH7tBV mfnvIFpCGTdD5gjj7FrpqJju/PQfDQI=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 10 Aug 2012 10:28:58 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <5024D487.9000208@isode.com> Date: Fri, 10 Aug 2012 10:29:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Chris Newman References: <5000104E.2000607@angry-red-pla.net> <87629j3jty.fsf@latte.josefsson.org> <7E7509CFA6720310B98847D3@96B2F16665FF96BAE59E9B90> In-Reply-To: <7E7509CFA6720310B98847D3@96B2F16665FF96BAE59E9B90> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kitten@ietf.org, Simon Josefsson Subject: Re: [kitten] draft-josefsson-sasl-external-channel-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 09:29:03 -0000 On 20/07/2012 16:45, Chris Newman wrote: > --On July 19, 2012 16:29:45 +0200 Simon Josefsson > wrote: >> I share your concern, although the reason for not saying anything like >> what you suggest is that, today, EXTERNAL and EXTERNAL-TLS semantically >> are different beasts. I believe the EXTERNAL-TLS semantics are more >> useful. It seems the deployment you refer to support that notion as >> well: they use EXTERNAL precisely what we want EXTERNAL-TLS for. >> The problem is that EXTERNAL can be used for other things too, and there > is >> no way of knowing which purpose was intended. > > Honestly, I see no real-world problem here. Yes, there's a minor > semantic difference between "use available credentials" and "use > available TLS credentials" but I don't see why it would matter to a > client that has gone through the trouble of being configured to > provide TLS client certificates. > >> To illustrate the problem, consider an application running over IPSEC >> that does IMAP with STARTTLS. The client see EXTERNAL announced from >> the server. The app wants to authenticate to the IMAP server using its >> TLS credentials. The app does not want to use its IPSEC credential to >> authenticate to the IMAP server. If it does 'AUTHENTICATE EXTERNAL' the >> client doesn't know which credential was used for authentication, and it >> isn't deterministic which account it was logged into. (This example >> does not use any authorization identity for simplicity, although this is >> the most common usage.) > > I know of no such implementation, nor of anyone conceiving of such an > implementation. First, no IMAP server will advertise EXTERNAL as a > result of IPSEC. The problem is that IPSEC uses host credentials which > can't be mapped to an end-user account (or if it uses end-user > credentials, there's no standard API to get them from the OS), so it > doesn't provide any useful credentials for end-user authentication > purposes so any IMAP server that advertised EXTERNAL without a useful > mapping to end-user credentials would be at least broken and probably > incompliant. Even if IPSEC could provide end-user credentials, those > credentials would almost always be the correct ones and the client > need not worry. > > So your strawman presumes 4 unlikely events: 1. someone uses IPSEC. 2. > IPSEC uses end-user credentials which imapd can access through a > supported API. 3. The IPSEC end-user credentials differ from the mail > account identity. 4. The client both cares which mail account is > accessed and fails to provide the mail account authorization identity > to the EXTERNAL mechanism. > > That scenario is at best an unlikely misconfiguration, if not a broken > client. I still think this is all trying to solve a non-existent problem. Agreed. The only other non-TLS use case I've seen for SASL EXTERNAL was over a Unix domain socket. > >> I believe the text you provided would be good, and we'd be happy to add >> it. There is another solution though: >> >> How do you feel about revising the EXTERNAL mechanism specification to >> say that it refers to the credentials negotiated under TLS, similar to >> what's in d-j-sasl-external-channel? Currently EXTERNAL refers to >> anything outside of the application protocol, and to get security and >> interoperability, client and server need to negotiate out of band what >> is intended. > > I would have no objection to this change. > >> Compare how we "updated" the GSSAPI mechanism to be for Kerberos V5 >> only. We could update EXTERNAL to be for TLS only, and permit future >> specification of EXTERNAL-SSH or EXTERNAL-IPSEC for "external" SASL >> authentication with other security protocols (if someone cares about >> that). >> >> I find EXTERNAL to be rarely used because applications cannot >> auto-detect when it is appropriate to use, and when it is used, in my >> experience it always means to use the TLS-negotiated credentials. > > There are two useful models for clients: > 1. explicit end-user selected security mechanism/policy > 2. latched auto-select security policy: the client looks for the best > option that works, and records that it worked with that server and > requires security at least that good in the future to prevent > downgrade attacks. > > Most clients do 1 because it's much less complex to implement/debug > even if it does leave the choice up to the end-user. On top of that, > it's even more difficult to auto-select the intended client > certificate (which client certificate is associated with which mail > account?). So if you have to make the end-user manually configure TLS > client cert authentication anyway, may as well keep the code simpler. > > The other problem is the wide deployment of non-interoperable > protocols when it comes to TLS client certificate authentication. > There are ones where we botched the IETF specifications (SMTP), so > there are servers that require EXTERNAL, servers that disallow > EXTERNAL and servers that do or don't use client certificate > credentials as a side-effect of the STARTTLS command and there's > usually no way for the client to tell the difference. Most SMTP > clients are lazy and just send the TLS client certificate and hope it > works. Then there's the non-standard imaps and pops protocols that > have unspecified behavior (and often do not interoperate when it comes > to client certificate authentication). > > At least there's no excuse for non-interoperable STARTTLS client > certificate authentication in IMAP and POP because that was > standardized unambiguously in 1999. > > Of course, there's also the problem that deploying and managing a > certificate infrastructure is a huge amount of work so for most > deployments the incremental security (if any) isn't worth the cost. > > I don't think making EXTERNAL more complex will improve deployment of > TLS client certificate authentication. Frankly, spending time on DANE > specification and implementation would probably be a better investment > if the latter is your goal. > >> The EXTERNAL-* idea is mostly to formalize one use-case for EXTERNAL. >> We could modify d-j-sasl-external-channel and say that for historical >> reasons EXTERNAL-TLS is actually called EXTERNAL, and then supersede >> Appendix A of RFC 4422 with this document. The only problem this would >> cause, that I can identify, is if someone is using EXTERNAL to mean >> IPSEC or some other security protocol. Is anyone aware of any such >> usage? > > No. +1 to all of this. From wmills@yahoo-inc.com Fri Aug 10 08:28:15 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FE421F86F9 for ; Fri, 10 Aug 2012 08:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.467 X-Spam-Level: X-Spam-Status: No, score=-17.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlNmA3wwnKJh for ; Fri, 10 Aug 2012 08:28:14 -0700 (PDT) Received: from nm23.bullet.mail.sp2.yahoo.com (nm23.bullet.mail.sp2.yahoo.com [98.139.91.93]) by ietfa.amsl.com (Postfix) with ESMTP id B8CFB21F86E4 for ; Fri, 10 Aug 2012 08:28:14 -0700 (PDT) Received: from [98.139.91.61] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 15:28:09 -0000 Received: from [98.139.91.18] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 15:28:09 -0000 Received: from [127.0.0.1] by omp1018.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 15:28:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 722423.49326.bm@omp1018.mail.sp2.yahoo.com Received: (qmail 57998 invoked by uid 60001); 10 Aug 2012 15:28:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344612489; bh=OWpQnGVl6rJCMNRSO7/zUhgB5kqZPzstRverDvbyOR8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kbNXOGAhG6NjQsZQ1mLE7+SffQbplq5+xbu/+9X1EONJqwU4Unxrk/gfu/ePxSN8v1Fm/moLAFEwWj55efT2yGc34RpQ8DCY/63lEiJzGBwWuull2nFjZWxzPmqyZycGEkL9Alhy4MsWxCQAbXHxoQqAJbmZB2u4IPbf84+iXPI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nLdFHcaC2ngo7Of+sPw4Ot+Y9q2+F5cX4EJTOrFg6PPVdWCe3Immw8gjYd7UMp0aaR9JsnfpbrDedzYkLnIFwzQzlLcTr6v1Zvz0j5qqZrDjktX5LJBSJ4OW5F9MPGyHLAWyHC2N7GCdGJ8k1ielbMi9gopByaGB7TTDZecgCSg=; X-YMail-OSG: KeVeWzcVM1lQ3AK2grEnhnwr3oF0o_TeQZKGldMI7y6byME 4qxJdN1C2mjntSABFKqHYG87gzHY1AFTJo0DvJvBuHAL4wj4pNiaRr4tBL6y lQ3IcJrIPWJPloRvrhfDxUYP3.aPz3sZYCGaqgL5VhbQr_4sUQ57xUXrDsTB cCS_waw4hS2o8Gs.9pVSnhDUFV_GRAv8_r_GWQOhuPATQhtFzQFmSpVFpbPz BqXNW1rUzsoHZL1FicgLH.S90OGIJkF2E1ATUKQ2Pl79cQbU7ziVnLATsfp2 98N_d57sBcBCE_8zBsTe3AoQfaVeKMu_Ewy.xY3qxUJoG_Yglxn5uXKwfgeN 8j4fO3IkSbrdNzYxqwO3cfZJ77NHnJrqTn8tl3ATXYBvtp63AJZY3KaJ8bDs 8tfYhx_dhJITFPcC5nRjOMpmjFOo.ZiO2RxxgnzQ_6NKeIJQ1bCXOrKwdiuB GGGTzd.Ls1scirYocR5ug2oGHI2tXhhw0ndHJYm8- Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Fri, 10 Aug 2012 08:28:09 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> <87hasbd4yq.fsf__31719.1455084414$1344554674$gmane$org@latte.josefsson.org> <87d32zd4rh.fsf@latte.josefsson.org> <1344557814.46045.YahooMailNeo__28311.2241108485$1344557830$gmane$org@web31805.mail.mud.yahoo.com> <874nobcn5o.fsf@latte.josefsson.org> Message-ID: <1344612489.49881.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Fri, 10 Aug 2012 08:28:09 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <874nobcn5o.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-684518285-1344612489=:49881" Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 15:28:15 -0000 --764183289-684518285-1344612489=:49881 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I did look at the OPENID example and it does exactly this, and initial gs2-= header, the server responds with a challenge.=A0 In fact, looking at http:/= /tools.ietf.org/html/rfc6595 section 5.1 it looks wrong to me in the exampl= e, I think it's missing a comma, it has =0A=0A=A0=A0=A0 n,,example.org=0A= =0Aand there should be 3 commas there? That said, having re-read this the = gs2-header is terminated by a comma so I now see how this =0Awould work whe= re I did not before.=0AI specifically did not want to put the authz id outs= ide the OAuth information, because I think that strays too far from the web= based OAuth model.=A0 Do you think section 3.2.1 is insufficient?=0A=0A-bi= ll=0A=0A=0A=0A=0A>________________________________=0A> From: Simon Josefsso= n =0A>To: William Mills =0A>Cc:= "kitten@ietf.org" =0A>Sent: Thursday, August 9, 2012 10:= 48 PM=0A>Subject: Re: Status of draft-ietf-kitten-sasl-oauth?=0A> =0A>Willi= am Mills writes:=0A>=0A>> So in reading http://tools= .ietf.org/html/rfc5801 and teh SAML SASL=0A>> spec it looks like the gs2-he= ader must appear by itself in a message?=A0=0A>> Since we don't have a chal= lenge response=A0 model here it sounds like we=0A>> have to have the follow= ing logic:=0A>>=0A>> 1)=A0=A0=A0 client sends gs2-header=0A>> 2)=A0=A0=A0 s= erver sends an empty reply or fail here if auth won't be permitted because = CB is required.=0A>> 3)=A0=A0=A0 client sends OAUTH mechanism auth request= =0A>> 4)=A0=A0=A0 server replies=0A>>=0A>> So for the non channel binding c= ase we're forced into an empty round trip.=A0 Correct?=0A>=0A>No, the gs2-h= eader can be a prefix of other data, it doesn't have to be=0A>its own messa= ge.=A0 Look at the SCRAM/OPENID/SAML20 protocol examples.=0A>Thus OAUTH cou= ld look like this (ABNF):=0A>=0A>initial-client-response :=3D gs2-header oa= th-data=0A>oath-data :=3D ...=0A>=0A>The important part is that the wire sy= ntax of the OAUTH SASL mechanism=0A>starts with the gs2-header, and that it= has the same semantics as GS2.=0A>=0A>Note that the gs2-header transfers t= he SASL authorization identity which=0A>is required by the SASL framework, = solving that problem as well.=0A>=0A>/Simon=0A>=0A>=0A> --764183289-684518285-1344612489=:49881 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I did look at the= OPENID example and it does exactly this, and initial gs2-header, the serve= r responds with a challenge.  In fact, looking at http://tools.ietf.or= g/html/rfc6595 section 5.1 it looks wrong to me in the example, I think it'= s missing a comma, it has 
&n=
bsp;   n,,example.org

and there should be 3 commas =
there?  That said, having re-read this the gs2-header is terminated by a co=
mma so I now see how this 
would work where I did not before.
I= specifically did not want to put the authz id outside the OAuth informatio= n, because I think that strays too far from the web based OAuth model. = ; Do you think section 3.2.1 is insufficient?

-bill

From: Simon Josefsson <simon@= josefsson.org>
To: = William Mills <wmills@yahoo-inc.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>
= Sent: Thursday, August 9, 201= 2 10:48 PM
Subject: Re= : Status of draft-ietf-kitten-sasl-oauth?

=0AWilliam= Mills <wmills@yahoo-inc.com> writes:

> So in read= ing http://tools.ietf.org/html/rfc5801 and teh SAML SASL
> spec it lo= oks like the gs2-header must appear by itself in a message? 
> S= ince we don't have a challenge response  model here it sounds like we<= br>> have to have the following logic:
>
> 1)  &nb= sp; client sends gs2-header
> 2)    server sends an em= pty reply or fail here if auth won't be permitted because CB is required.> 3)    client sends OAUTH mechanism auth request
&g= t; 4)    server replies
>
> So for the non chann= el binding case we're forced into an empty round trip.  Correct?
No, the gs2-header can be a prefix of other data, it doesn't have to beits own message.  Look at the SCRAM/OPENID/SAML20 protocol examples.
Thus OAUTH could look like this (ABNF):

initial-client= -response :=3D gs2-header oath-data
oath-data :=3D ...

The import= ant part is that the wire syntax of the OAUTH SASL mechanism
starts with= the gs2-header, and that it has the same semantics as GS2.

Note tha= t the gs2-header transfers the SASL authorization identity which
is requ= ired by the SASL framework, solving that problem as well.

/Simon
=

--764183289-684518285-1344612489=:49881-- From wmills@yahoo-inc.com Fri Aug 10 11:36:19 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B233B21F8526 for ; Fri, 10 Aug 2012 11:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.806 X-Spam-Level: X-Spam-Status: No, score=-16.806 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7482Sl4nOOs for ; Fri, 10 Aug 2012 11:36:19 -0700 (PDT) Received: from nm2.bullet.mail.sp2.yahoo.com (nm2.bullet.mail.sp2.yahoo.com [98.139.91.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0036221F85AA for ; Fri, 10 Aug 2012 11:36:18 -0700 (PDT) Received: from [72.30.22.77] by nm2.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 18:36:16 -0000 Received: from [98.139.91.1] by tm11.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 18:36:16 -0000 Received: from [127.0.0.1] by omp1001.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 18:36:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 396364.32708.bm@omp1001.mail.sp2.yahoo.com Received: (qmail 85631 invoked by uid 60001); 10 Aug 2012 18:36:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344623775; bh=JjJ8UJPDE6Z2AH3tahL6+1YXv1GIoHQIpP+M7wxE6/g=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Vi39xiDNlFsky2x6UmY4XThwj3ZWsMn+qn1Ur7Y0+Tc1jqR3yat6v9BHTMtCkP5p0c+pDNnvEiyvr8zQ/ljOPWqzr6BueJWR4P2/VC8EkCBE+yj7b/yOKwCI1FJm1OAgk71pztJDuiM2r2RvLb4jy7Tx8vvaDQKH81tSZX+eyMQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=CypomrxOoT4+j0yRu+m6YLW63ir8NRQ9gsjxyU234ESrmlMmOKaCNr+sRA2fjIgMhL75FAqHobK8fw0D6qQhwYlmBdSYOzewPy0dpzDRzl6x6X/GxOTl1pKcSDukLVV1yXCYUgKPbUgsgeNsFXkRzcn5jmk3Mcn/6WYQoCFCwTM=; X-YMail-OSG: FGNKbbkVM1m4KodG96_RzHL5MfBfR60R08Lj1ozPLYUFSY9 Utule_S7EERosjsMwlAx.dtmXscEWaGn2tPQUucXKG4JQEp_6USHa5Je11dS jekwnQzRzR1g1hG9.TosUoUn5naWa13SNuz_aiZQvv2JYsdjTWdtXN0a8zNx fciPZ4bHFLTSc.KzLqltj_D3q3Iuywq31PJhmhanwTwPYXmwCV_FezWE8OUn Nsgn0XAziUitU6BLZnD.2JQOygVJ0Z2979M5gh2Aa.1VwZDW4iv8v68GXi5i wCq0p6.jivKlWxzM4Ym6EjjQmoUgRZbPPWxHrcOJH54JDeBAmW0JVT5yhSu2 flFDYmw8fV1SEKjxW0QeDef1co51SV446lUkUPvTb7MkWNHrLPUr6jHfqjMu SZnAOrts4jC6aLUq1UKQY9RjRIwKSL3i.6a0mf0xNk0bZINZI Received: from [209.131.62.115] by web31801.mail.mud.yahoo.com via HTTP; Fri, 10 Aug 2012 11:36:15 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 Message-ID: <1344623775.76296.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Fri, 10 Aug 2012 11:36:15 -0700 (PDT) From: William Mills To: "kitten@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-368338466-1054421919-1344623775=:76296" Subject: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 18:36:19 -0000 ---368338466-1054421919-1344623775=:76296 Content-Type: text/plain; charset=us-ascii Given Simon's recent comments about the fundamental flaw in the idea of channel binding when you don't have an integrity guarantee,, as in the Bearer token use case, should channel binding remain in the OAuth SASL profile? Thanks, -bill ---368338466-1054421919-1344623775=:76296 Content-Type: text/html; charset=us-ascii
Given Simon's recent comments about the fundamental flaw in the idea of channel binding when you don't have an integrity guarantee,, as in the Bearer token use case, should channel binding remain in the OAuth SASL profile?

Thanks,

-bill
---368338466-1054421919-1344623775=:76296-- From cantor.2@osu.edu Fri Aug 10 11:48:18 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2899C21F8650 for ; Fri, 10 Aug 2012 11:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APg65C8L8zEx for ; Fri, 10 Aug 2012 11:48:17 -0700 (PDT) Received: from defang21.it.ohio-state.edu (defang21.it.ohio-state.edu [128.146.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 90B8121F8613 for ; Fri, 10 Aug 2012 11:48:17 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang21.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7AIm1wG015277; Fri, 10 Aug 2012 14:48:15 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.02.0309.002; Fri, 10 Aug 2012 14:39:43 -0400 From: "Cantor, Scott" To: William Mills , "kitten@ietf.org" Thread-Topic: [kitten] OAUTH SASL and Channel binding Thread-Index: AQHNdycLQTvVvlun60mY6GJcxxz8LpdTYLiA Date: Fri, 10 Aug 2012 18:39:43 +0000 Message-ID: In-Reply-To: <1344623775.76296.YahooMailNeo@web31801.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <1E145DABCCF95842BACB120B708AD3A9@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8051; longitude=-81.9351; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8051,-81.9351&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.181 Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 18:48:18 -0000 On 8/10/12 2:36 PM, "William Mills" wrote: >Given Simon's recent comments about the fundamental flaw in the idea of >channel binding when you don't have an integrity guarantee,, as in the >Bearer token use case, should channel binding remain in the OAuth SASL >profile? If you can never have an integrity guarantee, probably not, but I wouldn't personally use such a mechanism in any case, so probably moot. -- Scott From wmills@yahoo-inc.com Fri Aug 10 11:54:22 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB02B11E8072 for ; Fri, 10 Aug 2012 11:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.536 X-Spam-Level: X-Spam-Status: No, score=-17.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRkxarEKk6AQ for ; Fri, 10 Aug 2012 11:54:21 -0700 (PDT) Received: from nm20-vm6.bullet.mail.ne1.yahoo.com (nm20-vm6.bullet.mail.ne1.yahoo.com [98.138.91.113]) by ietfa.amsl.com (Postfix) with SMTP id EC24D21F86B7 for ; Fri, 10 Aug 2012 11:54:17 -0700 (PDT) Received: from [98.138.90.50] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 10 Aug 2012 18:54:14 -0000 Received: from [98.138.89.175] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 10 Aug 2012 18:54:14 -0000 Received: from [127.0.0.1] by omp1031.mail.ne1.yahoo.com with NNFMP; 10 Aug 2012 18:54:14 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 152041.13950.bm@omp1031.mail.ne1.yahoo.com Received: (qmail 76669 invoked by uid 60001); 10 Aug 2012 18:54:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344624853; bh=hvo0HpfFjx8wo9gobB4wQICArFtDprsv02+OZ5FwTbk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=S7oLKtM3vntFqdi8plJaKoMymAGiDeLLpigDLHNQzoMf6eGhbneEb8EnxGF23t+//gsOQchCGEVGZcWDt+kFomsMBIEUpAi0gQ31OAV2NZ5B29Zqq+Gl9ZZlZ0Qpl+acCCwvr4T5GWFFPPOLZ+du2kPUHGKlnPLO976oCW8XNcY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=d517fKV9r10j/27oZkihyXqOB/d285poMbXKkjtWpY50GV8u8/SG8RWQVkq0NDNQw6jOUfiJUpSM1JSG4fb3ejNukV5WNNThpE0ybJy09cQgnU1WxaqJMn0Z+IGzdiOTuyqMD6pgs3VVR4anuIyYSY1AJ5dWJuemBPWhfsd7sGM=; X-YMail-OSG: fO_eO_oVM1kS4oxU0IVA5Z8VmDFMi8N.wuh_8qVAzsxt_UZ S9M3g_989SW9EDBn4yJGHJT9PYqcsKyzsXrP7EUb_7pQjGPTZnbMtXtFDljc kAtEenRyix5SUHPhGSNzBeWlb6vvto4MqnGB0SOhQUa8RSGcAbWbmOPRbqPx BRh1zmDGQsLkXVzkMHWdbca9tpXfqGVjxk99yMh2AFtcjTGj8Wu1vooT1eCk .1ALxK_AVqddGM9tWp5BYawzVyScXTCERXHUcqU2XjEQVXYfBQpIHOw6Lz5q V1xWCxnCz.1hLFJK8_LlttvAoPp22yOblQQsSyAuyCgzFCGaEkNsos.zgown IMc1ix5Vl3UOxRlxnic1IIph0gQG3qRkyVByVXL0oIho63L6YteNcls2lgmQ ZdXjb43xKcxitGOiRhjRrAK_EDF4RyZyKOXs50.U0fOvlC7krIjhHN6IE.Vr xJGJGKy4- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Fri, 10 Aug 2012 11:54:12 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1344623775.76296.YahooMailNeo@web31801.mail.mud.yahoo.com> Message-ID: <1344624852.76552.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Fri, 10 Aug 2012 11:54:12 -0700 (PDT) From: William Mills To: "Cantor, Scott" , "kitten@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-2110391144-1344624852=:76552" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 18:54:22 -0000 --1458549034-2110391144-1344624852=:76552 Content-Type: text/plain; charset=us-ascii You could have an integrity guarantee for a signed profile like MAC or OAuth 1.0a. >________________________________ > From: "Cantor, Scott" >To: William Mills ; "kitten@ietf.org" >Sent: Friday, August 10, 2012 11:39 AM >Subject: Re: [kitten] OAUTH SASL and Channel binding > >On 8/10/12 2:36 PM, "William Mills" wrote: > >>Given Simon's recent comments about the fundamental flaw in the idea of >>channel binding when you don't have an integrity guarantee,, as in the >>Bearer token use case, should channel binding remain in the OAuth SASL >>profile? > >If you can never have an integrity guarantee, probably not, but I wouldn't >personally use such a mechanism in any case, so probably moot. > >-- Scott > > > > --1458549034-2110391144-1344624852=:76552 Content-Type: text/html; charset=us-ascii
You could have an integrity guarantee for a signed profile like MAC or OAuth 1.0a.


From: "Cantor, Scott" <cantor.2@osu.edu>
To: William Mills <wmills@yahoo-inc.com>; "kitten@ietf.org" <kitten@ietf.org>
Sent: Friday, August 10, 2012 11:39 AM
Subject: Re: [kitten] OAUTH SASL and Channel binding

On 8/10/12 2:36 PM, "William Mills" <wmills@yahoo-inc.com> wrote:

>Given Simon's recent comments about the fundamental flaw in the idea of
>channel binding when you don't have an integrity guarantee,, as in the
>Bearer token use case, should channel binding remain in the OAuth SASL
>profile?

If you can never have an integrity guarantee, probably not, but I wouldn't
personally use such a mechanism in any case, so probably moot.

-- Scott



--1458549034-2110391144-1344624852=:76552-- From nico@cryptonector.com Fri Aug 10 11:55:31 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC29711E8072 for ; Fri, 10 Aug 2012 11:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=-1.223, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLw3zlZVf-YX for ; Fri, 10 Aug 2012 11:55:31 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7459021F86C4 for ; Fri, 10 Aug 2012 11:55:31 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 16BA8202022 for ; Fri, 10 Aug 2012 11:55:31 -0700 (PDT) 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; s=cryptonector.com; bh=+OAgWEqGkIZYU9Aoz3zR 5xa9Z08=; b=GdrYt7WvAdydUx0DjYrwx1+2qVMCGgChPZQ+oAxMAPJRBFcOK9Ph hgPDm359bFK2GU0ff6J0wm7ntWcHGlpupx05HoAJntPfO1eWlowe9cw51ej029Z4 stftSm+G+H9iCVq9ba3uLMnfxOoozGkKT60cRSwXQX3JWNphij5nCYE= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id EAA43202018 for ; Fri, 10 Aug 2012 11:55:30 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3136821pbb.31 for ; Fri, 10 Aug 2012 11:55:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.191.4 with SMTP id gu4mr1071704pbc.50.1344624930511; Fri, 10 Aug 2012 11:55:30 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Fri, 10 Aug 2012 11:55:30 -0700 (PDT) In-Reply-To: <1344623775.76296.YahooMailNeo@web31801.mail.mud.yahoo.com> References: <1344623775.76296.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Fri, 10 Aug 2012 13:55:30 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 18:55:32 -0000 On Fri, Aug 10, 2012 at 1:36 PM, William Mills wrote: > Given Simon's recent comments about the fundamental flaw in the idea of > channel binding when you don't have an integrity guarantee,, as in the > Bearer token use case, should channel binding remain in the OAuth SASL > profile? I find it truly sad that OAuth 2.0 is only a bearer token system. Channel binding is still possible, but since bearer tokens depend so utterly on the TLS server PKI, channel binding adds... no value. But, IMO, bearer tokens are a waste of time. Nico -- From nico@cryptonector.com Fri Aug 10 11:58:52 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E170521F86A8 for ; Fri, 10 Aug 2012 11:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=-1.209, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQiu0KTaeEb8 for ; Fri, 10 Aug 2012 11:58:51 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 1F25021F86A5 for ; Fri, 10 Aug 2012 11:58:51 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id BAE231DE071 for ; Fri, 10 Aug 2012 11:58:50 -0700 (PDT) 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; s=cryptonector.com; bh=M99CYGr5JLyOkyvy9Nsy vTsNDh4=; b=ZJYA4mIayqODArYiIOmxN+XA0gSbYZBEBHVIupj800Ze4SV6kAbs 8st3Uu0mnmjM1oQHXYNoXGThiYsyI/Pb/gqDIm7rrxAEgq+4C5gOn4y5MQSZTjXi 2U6g+IlFzarhVRgpb88qPVl00QjBj+SGNUuYx9fKqzmueHjdfT0yEv4= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id A9CB71DE070 for ; Fri, 10 Aug 2012 11:58:50 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3140497pbb.31 for ; Fri, 10 Aug 2012 11:58:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.222.40 with SMTP id qj8mr14504339pbc.139.1344625130256; Fri, 10 Aug 2012 11:58:50 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Fri, 10 Aug 2012 11:58:50 -0700 (PDT) In-Reply-To: <1344624852.76552.YahooMailNeo@web31812.mail.mud.yahoo.com> References: <1344623775.76296.YahooMailNeo@web31801.mail.mud.yahoo.com> <1344624852.76552.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Fri, 10 Aug 2012 13:58:50 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 18:58:52 -0000 On Fri, Aug 10, 2012 at 1:54 PM, William Mills wrote: > You could have an integrity guarantee for a signed profile like MAC or OAuth > 1.0a. But that's not OAuth 2.0... Nico -- From cantor.2@osu.edu Fri Aug 10 12:14:20 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DF521F86F7 for ; Fri, 10 Aug 2012 12:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jH6IHDIVpzke for ; Fri, 10 Aug 2012 12:14:19 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9A44B21F86F6 for ; Fri, 10 Aug 2012 12:14:19 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7AJE4Qt002190; Fri, 10 Aug 2012 15:14:16 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.02.0309.002; Fri, 10 Aug 2012 15:05:41 -0400 From: "Cantor, Scott" To: Nico Williams , William Mills Thread-Topic: [kitten] OAUTH SASL and Channel binding Thread-Index: AQHNdym2QTvVvlun60mY6GJcxxz8LpdTZ/IA Date: Fri, 10 Aug 2012 19:05:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <6A7B7CB9E72DC943A81EE2C75E18E57B@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8051; longitude=-81.9351; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8051,-81.9351&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 19:14:20 -0000 On 8/10/12 2:55 PM, "Nico Williams" wrote: > >I find it truly sad that OAuth 2.0 is only a bearer token system. I believe the MAC pieces in 2.0 still would permit it. I don't happen to think they'll get implemented and used properly, but that's a separate argument. I would like to see the specs built on OAuth get done in a way that at least allows them to be done securely when the will exists. > Channel binding is still possible, but since bearer tokens depend so > utterly on the TLS server PKI, channel binding adds... no value. Not quite (in the abstract, maybe not here). One of the benefits in the SAML case is that it provides a very nice way to offload TLS server credential verification from the client (where it will be botched) to the IdP (where it can be done via SAML metadata and PKIX told to go get stuffed). -- Scott From nico@cryptonector.com Fri Aug 10 12:38:35 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C008F21F873A for ; Fri, 10 Aug 2012 12:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBLlstSjmF0P for ; Fri, 10 Aug 2012 12:38:35 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 42A7921F8713 for ; Fri, 10 Aug 2012 12:38:35 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 154B436006F for ; Fri, 10 Aug 2012 12:38:35 -0700 (PDT) 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; s=cryptonector.com; bh=Uz+ilgaVUwhq2vlUbwMU OwmOUlY=; b=o5A/Z25z1EbZ+Argf6zYzCGNc3QENDZmeBVg7nSIwLpMSx300N+f awjLx8sG1xwwdgPh4BsPxvumdFwPXSA7PuGF+dBijGRMXB5uGUXVqMz1XRnyGBm1 Vf4I99+B0mf9grGRjI5CfWnyPBLFrXBwL4BVgUF0ZLxdAp5VSc/a8M8= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id EE48236006B for ; Fri, 10 Aug 2012 12:38:34 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3185274pbb.31 for ; Fri, 10 Aug 2012 12:38:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.41 with SMTP id or9mr3120537pbb.115.1344627514638; Fri, 10 Aug 2012 12:38:34 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Fri, 10 Aug 2012 12:38:34 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Aug 2012 14:38:34 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 19:38:35 -0000 On Fri, Aug 10, 2012 at 2:05 PM, Cantor, Scott wrote: > On 8/10/12 2:55 PM, "Nico Williams" wrote: >> Channel binding is still possible, but since bearer tokens depend so >> utterly on the TLS server PKI, channel binding adds... no value. > > Not quite (in the abstract, maybe not here). One of the benefits in the > SAML case is that it provides a very nice way to offload TLS server > credential verification from the client (where it will be botched) to the > IdP (where it can be done via SAML metadata and PKIX told to go get > stuffed). Oh, good point, but, of course, that requires changes to the HTTP/TLS stack plumbing (since you want the client to not bother validating the server cert the normal way on account of the bearer token mechanism being about to do so via its interactions with the IdP). Nico -- From cantor.2@osu.edu Fri Aug 10 12:52:09 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A517511E80A5 for ; Fri, 10 Aug 2012 12:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yfLPljcjqsG for ; Fri, 10 Aug 2012 12:52:07 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 19CD811E80AD for ; Fri, 10 Aug 2012 12:52:05 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7AJpi0i019865; Fri, 10 Aug 2012 15:51:58 -0400 Received: from CIO-KRC-HT03.osuad.osu.edu (164.107.81.43) by CIO-KRC-HT02.osuad.osu.edu (164.107.81.40) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 10 Aug 2012 15:50:13 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT03.osuad.osu.edu ([fe80::2572:c08d:8186:46a4%12]) with mapi id 14.02.0309.002; Fri, 10 Aug 2012 15:50:12 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] OAUTH SASL and Channel binding Thread-Index: AQHNdym2QTvVvlun60mY6GJcxxz8LpdTZ/IAgABMPQD//8AzgA== Date: Fri, 10 Aug 2012 19:50:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <41009BDE849A65419AAE177412C3F079@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8051; longitude=-81.9351; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8051,-81.9351&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 19:52:09 -0000 On 8/10/12 3:38 PM, "Nico Williams" wrote: > >Oh, good point, but, of course, that requires changes to the HTTP/TLS >stack plumbing (since you want the client to not bother validating the >server cert the normal way on account of the bearer token mechanism >being about to do so via its interactions with the IdP). Yes, that's true. There are extant examples of that, and not just in C, but less so as you get more scripty. Anyway, not trying to go off topic. My opinion as an observer is that it would be nice if the MAC or whatever non-bearer approaches within OAuth could be used with channel binding even if it's not possible in the bearer case. If it actually is. The SAML EC bearer case still supports channel binding but that's because you can sign requests and responses and still be using bearer tokens. -- Scott From wmills@yahoo-inc.com Fri Aug 10 14:14:43 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F7B11E8097 for ; Fri, 10 Aug 2012 14:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.537 X-Spam-Level: X-Spam-Status: No, score=-17.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpIf0bMUhE+N for ; Fri, 10 Aug 2012 14:14:43 -0700 (PDT) Received: from nm5-vm1.bullet.mail.sp2.yahoo.com (nm5-vm1.bullet.mail.sp2.yahoo.com [98.139.91.205]) by ietfa.amsl.com (Postfix) with SMTP id 0520611E808E for ; Fri, 10 Aug 2012 14:14:42 -0700 (PDT) Received: from [72.30.22.77] by nm5.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 21:14:42 -0000 Received: from [98.139.91.31] by tm11.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 21:13:42 -0000 Received: from [127.0.0.1] by omp1031.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 21:13:42 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 922613.82942.bm@omp1031.mail.sp2.yahoo.com Received: (qmail 67105 invoked by uid 60001); 10 Aug 2012 21:13:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344633222; bh=NfQpHLQ+En1M/wLjISoRkmfhCX9dgNN/FoD1NNgglLs=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ohR7CFtFszU5OfFezTA3IkRuIOJeLN8cwNMq/fIUllTThQQAwfvUmAQIkB8oPojNjL0Lv5nXrBelIjQCI+4f00yXrVlnbsZ4hgHGmzkS4Tc3Qu+iQ3Ooqsvi05ZznoUe6rBDBx6uk2CUsxxw0GBc5gCXpzlUbGkutEGZnHzUWKI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ja7STDB7E/ctWdxOYmVt57mcIyXYL6JCK9cmID0oIbX5hAWN+aaj07ZtAOMwNyh4VexgMkSdoJCDWxDPrIamizDhwt8BvmVXkrwYaMpCRXwEBTsq5X7qLg4lTYmP52IxYwyqNDKdnWvrToScby9inU60NM+FYZ8UgbY8X8PgXDw=; X-YMail-OSG: QEA_ptUVM1m11SQpax5IEKUDfGqin8UcEJggCayETuToXSH NPK_yR4CWcgaK742gflVEYWRlAusaVO4rmfxj.pptqg9MHAfHv5SY_b3iNin IdLRDtSkbRjWBe0zyXysOqn2p5UWGSLlWdl2KNxRMYNzGudm3vs0xTmaYj6R 8PgfoZ2XnIHOUNw15NvY46g5GkXdqpkGOzLsZi4L5RBmvi1yMtS7X8R1jvue 7aRkrHNHOr9V0U_kRNjZqe5CEVFbmnqX1kxAXOeUG3gHt1Rm_jr7j3sCAVBl ju.MZ2ja51v6CV95se3xtA44JLFgML2rEwnp3x8HiVHGhNyIHxUg0Sump1xi OZN.Vp9I4xV5nsOX4pShNWxnABOMPJa4ipUHRLQCzozkhV7FrOu9P7lQ5rHs bQxTL.2W9OX7SrWwVTZLae8Jpbxv8P6u7nopjalHh8xY4JKD0y9to.4zgBwx hWXZhCg-- Received: from [209.131.62.113] by web31807.mail.mud.yahoo.com via HTTP; Fri, 10 Aug 2012 14:13:41 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1344623775.76296.YahooMailNeo@web31801.mail.mud.yahoo.com> <1344624852.76552.YahooMailNeo@web31812.mail.mud.yahoo.com> Message-ID: <1344633221.28420.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Fri, 10 Aug 2012 14:13:41 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-1281662829-1344633221=:28420" Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 21:14:43 -0000 ---125733401-1281662829-1344633221=:28420 Content-Type: text/plain; charset=us-ascii The SASL profile will support OAuth 1.0a just fine. >________________________________ > From: Nico Williams >To: William Mills >Cc: "Cantor, Scott" ; "kitten@ietf.org" >Sent: Friday, August 10, 2012 11:58 AM >Subject: Re: [kitten] OAUTH SASL and Channel binding > >On Fri, Aug 10, 2012 at 1:54 PM, William Mills wrote: >> You could have an integrity guarantee for a signed profile like MAC or OAuth >> 1.0a. > >But that's not OAuth 2.0... > >Nico >-- > > > ---125733401-1281662829-1344633221=:28420 Content-Type: text/html; charset=us-ascii
The SASL profile will support OAuth 1.0a just fine.


From: Nico Williams <nico@cryptonector.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: "Cantor, Scott" <cantor.2@osu.edu>; "kitten@ietf.org" <kitten@ietf.org>
Sent: Friday, August 10, 2012 11:58 AM
Subject: Re: [kitten] OAUTH SASL and Channel binding

On Fri, Aug 10, 2012 at 1:54 PM, William Mills <wmills@yahoo-inc.com> wrote:
> You could have an integrity guarantee for a signed profile like MAC or OAuth
> 1.0a.

But that's not OAuth 2.0...

Nico
--


---125733401-1281662829-1344633221=:28420-- From wmills@yahoo-inc.com Fri Aug 10 16:25:24 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974A211E80AD for ; Fri, 10 Aug 2012 16:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.538 X-Spam-Level: X-Spam-Status: No, score=-17.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+-qrXIrVdKg for ; Fri, 10 Aug 2012 16:25:23 -0700 (PDT) Received: from nm25.bullet.mail.ac4.yahoo.com (nm25.bullet.mail.ac4.yahoo.com [98.139.52.222]) by ietfa.amsl.com (Postfix) with ESMTP id 77DCC11E80A3 for ; Fri, 10 Aug 2012 16:25:23 -0700 (PDT) Received: from [98.139.52.189] by nm25.bullet.mail.ac4.yahoo.com with NNFMP; 10 Aug 2012 23:25:19 -0000 Received: from [98.139.52.135] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 10 Aug 2012 23:25:18 -0000 Received: from [127.0.0.1] by omp1018.mail.ac4.yahoo.com with NNFMP; 10 Aug 2012 23:25:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 985501.17050.bm@omp1018.mail.ac4.yahoo.com Received: (qmail 34004 invoked by uid 60001); 10 Aug 2012 23:25:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344641118; bh=llaUW+YL1CwhDPGhPLRmuqsn9EtkpoHUeRgr7oHbgxs=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GQ7w0esu+NylJ3NzDSNivE78/iPKkC2JoFUSAtgmBpLNlcWNgMdu8iQ+lnqpb+tlnkhrHxmeIPDtMu7weFC/HYOXkvg1gq/NXoqJ9ABOAsjQpMx7RyzRhU7ossv2RE/V5cdtTRvmxTSR8X2j/svcahxeXY9EWUqt1vMBdGwaM4s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HEv4h/J+v8CmbEfFqtWMHz+EI5f1w7cbXiHISEprl08UL0u+R/L3olbLQGmvhFUDc3wX74+QVPMeFX8Pw893/xkD4vZ8Ob9XTHMNa1T8wFIf6HvGTrKK8cWv8BVSdC5rLuoCLVFExJ2967BY9/Ep1do1TPPHbYtxKVcyp5N3p2g=; X-YMail-OSG: sT0eiYEVM1lJomNKPFvUw9bFnyDQmSlM4kANDZ8gQbe4b1N JgLblgi8uWCvX142vmxK_owFeSrTR4MnfMhV8c.NYI0sIkPLdzNuWOpursYB _pzv6m.Y3_sEXF4o01CO0CNl2Bymsx1Nwa8IBLx2fvWeImtmVcv.9pfJYx8A nagRgtPzqEBNhB0KOB6mEpJCDUFEhpyZILpSgvk6RvrXwcnPWioHrnMy8q5G LtTlxd0QHlMhm6RegIkpY8DW5Csf8vXPBKufwI6IFvDI1l.NJyWTTRuzvKOo fT_P69Lkwr4o_PfNutPT7wufSZ6ZU.moeYPR9vITrII32TXhPijAGzHb3SK6 V9gpdSDAZojrjU4gV4OaZ7mOy9xVz8ZlMsTYlbigqoIR2eUTQump9hiWAI.Q srhYwfa4DZ83OcuVVgfI8TP0BZAfg9iNLvD4zLSD2DcUScCkOz74bGVgAAgN uzPhUXNg- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Fri, 10 Aug 2012 16:25:17 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> <87hasbd4yq.fsf@latte.josefsson.org> Message-ID: <1344641117.33923.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Fri, 10 Aug 2012 16:25:17 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87hasbd4yq.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-1623469309-1344641117=:33923" Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 23:25:24 -0000 --1458549034-1623469309-1344641117=:33923 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable In re your comment on 3.4=A0 "Should "authorization scheme" be "application= protocol"?", authorization scheme is intended here.=A0 Bearer for example = has a SHOULD for TLS so I want to carry that through into this spec.=0A=0AI= 'm going to leave off fixing the channel binding stuff until we decide whet= her it's staying.=0A=0A=0A=0A=0A>________________________________=0A> From:= Simon Josefsson =0A>To: William Mills =0A>Cc: Ryan Troll ; "kitten@ietf.org" =0A>Sent: Thursday, August 9, 2012 4:24 PM=0A>Subject: Re: Statu= s of draft-ietf-kitten-sasl-oauth?=0A> =0A>William Mills writes:=0A>=0A>> There hasn't been a lot of action in any substantive = way on the list=0A>> on this draft, and I think it's pretty well baked.=A0 = A working=0A>> implementation is going to go a long way to nailing this dow= n.=0A>>=0A>> Anyone out there with any significant objections or proposed s= hould=0A>> speak up "real soon now".=A0=0A>=0A>I have reviewed the -03 docu= ment, and I believe there are some major=0A>issues with it.=0A>=0A>MAJOR:= =0A>=0A>* The protocol does not appear to be compatible with the GS2 framin= g,=0A>=A0 thus the GSS-API mechanism the document defines would not be=0A>= =A0 wire-compatible with the SASL mechanism.=A0 The SASL packets needs to= =0A>=A0 use the GS2 header to be compatible.=A0 The examples reinforces my= =0A>=A0 readings, they don't begin with the GS2 header.=A0 Compare the SCRA= M,=0A>=A0 OPENID and SAML20 mechanism to see how this should be done.=0A>= =0A>* I don't see where the mechanism transfers the SASL authorization=0A>= =A0 identity, which is required.=A0 This would be done by the GS2 header.= =0A>=0A>* I don't follow how the channel binding data is integrity protecte= d.=0A>=A0 Unless I'm missing some keying, this seems to open up for a MITM = to=0A>=A0 fake channel binding.=A0 Section 3.2:=0A>=0A>=A0 =A0 In the OAUTH= -PLUS mechanism the server examines the channel binding=0A>=A0 =A0 data, ex= tracts the channel binding unique prefix, and extracts the=0A>=A0 =A0 raw c= hannel biding data based on the channel binding type used.=A0 It=0A>=A0 =A0= then computes it's own copy of the channel binding payload and=0A>=A0 =A0 = compares that to the payload sent by the client in the cbdata key/=0A>=A0 = =A0 value.=A0 Those two must be equal for channel binding to succeed.=0A>= =0A>=A0 Presumably the client is not authenticated when this is sent, so th= e=0A>=A0 server might as well be talking to an attacker, which sends its ow= n=0A>=A0 channel binding data.=0A>=0A>=A0 I'm not sure I see how OAuth with= bearer tokens could support channel=0A>=A0 bindings at all?=0A>=0A>* Secti= on 3.4 seems confusing.=A0 Quoting:=0A>=0A>=A0 =A0 If the specification for= the underlying authorization scheme requires=0A>=A0 =A0 a security layer, = such as TLS [RFC5246], the server SHOULD only offer=0A>=A0 =A0 a mechanism = where channel binding can be enabled.=0A>=0A>=A0 Should "authorization sche= me" be "application protocol"?=0A>=0A>=A0 Quoting further:=0A>=0A>=A0 =A0 T= he channel binding data is computed by the client based on it's=0A>=A0 =A0 = choice of preferred channel binding type.=0A>=0A>=A0 I think you want somet= hing similar to section 5.2 in RFC 5802 instead,=0A>=A0 to leave the choise= of preferred channel binding type up to the=0A>=A0 application protocol pr= ofile (or resume back to a default).=0A>=0A>=A0 =A0 If the raw channel bind= ing data is 500=0A>=A0 =A0 bytes or larger then a SHA-1 [RFC3174] hash of t= he raw channel=0A>=A0 =A0 binding data is computed.=0A>=0A>=A0 SHA-1?=A0 Th= is opens up for hash agility concerns.=0A>=0A>=A0 =A0 If the client is usin= g tls-unique for a channel binding then the raw=0A>=A0 =A0 channel binding = data equals the first TLS finished message.=0A>=0A>=A0 There is subtlety wi= th renegotiation here, I suggest to quote RFC 5929=0A>=A0 instead.=0A>=0A>/= Simon=0A>=0A>=0A> --1458549034-1623469309-1344641117=:33923 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
In re = your comment on 3.4  "Should "authorization scheme" be "applica= tion protocol"?", authorization scheme is intended here.  Bearer for e= xample has a SHOULD for TLS so I want to carry that through into this spec.=

I'm going to leav= e off fixing the channel binding stuff until we decide whether it's staying= .

From:<= /b> Simon Josefsson <simon@josefsson.org>
To: William Mills <wmills@yahoo-inc.com> Cc: Ryan Troll <rtrol= l@googlers.com>; "kitten@ietf.org" <kitten@ietf.org>
Sent: Thursday, August 9, 2012 4:2= 4 PM
Subject: Re: Stat= us of draft-ietf-kitten-sasl-oauth?

=0AWilliam Mills= <wmills@yahoo-inc.com> writes:

> There hasn't bee= n a lot of action in any substantive way on the list
> on this draft,= and I think it's pretty well baked.  A working
> implementation= is going to go a long way to nailing this down.
>
> Anyone out= there with any significant objections or proposed should
> speak up = "real soon now". 

I have reviewed the -03 document, and I belie= ve there are some major
issues with it.

MAJOR:

* The proto= col does not appear to be compatible with the GS2 framing,
  thus t= he GSS-API mechanism the document defines would not be
  wire-compa= tible with the SASL mechanism.  The SASL packets needs to
  us= e the GS2 header to be compatible.  The examples reinforces my
&nbs= p; readings, they don't begin with the GS2 header.  Compare the SCRAM,
  OPENID and SAML20 mechanism to see how this s= hould be done.

* I don't see where the mechanism transfers the SASL = authorization
  identity, which is required.  This would be do= ne by the GS2 header.

* I don't follow how the channel binding data = is integrity protected.
  Unless I'm missing some keying, this seem= s to open up for a MITM to
  fake channel binding.  Section 3.= 2:

    In the OAUTH-PLUS mechanism the server examines the= channel binding
    data, extracts the channel binding unique= prefix, and extracts the
    raw channel biding data based on= the channel binding type used.  It
    then computes it'= s own copy of the channel binding payload and
    compares tha= t to the payload sent by the client in the cbdata key/
    val= ue.  Those two must be equal for channel binding to succeed.

  Presumably the client is not authenticated when thi= s is sent, so the
  server might as well be talking to an attacker,= which sends its own
  channel binding data.

  I'm not = sure I see how OAuth with bearer tokens could support channel
  bin= dings at all?

* Section 3.4 seems confusing.  Quoting:

&= nbsp;   If the specification for the underlying authorization scheme r= equires
    a security layer, such as TLS [RFC5246], the serve= r SHOULD only offer
    a mechanism where channel binding can = be enabled.

  Should "authorization scheme" be "application pro= tocol"?

  Quoting further:

    The channel bin= ding data is computed by the client based on it's
    choice o= f preferred channel binding type.

  I think you want something = similar to section 5.2 in RFC 5802 instead,
  to leave the choise of preferred channel binding type up to the
  application p= rotocol profile (or resume back to a default).

    If the = raw channel binding data is 500
    bytes or larger then a SHA= -1 [RFC3174] hash of the raw channel
    binding data is compu= ted.

  SHA-1?  This opens up for hash agility concerns.
    If the client is using tls-unique for a channel binding = then the raw
    channel binding data equals the first TLS fin= ished message.

  There is subtlety with renegotiation here, I s= uggest to quote RFC 5929
  instead.

/Simon


--1458549034-1623469309-1344641117=:33923-- From simon@josefsson.org Sat Aug 11 00:26:47 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12D821F84E1 for ; Sat, 11 Aug 2012 00:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzcjXIsXpVU8 for ; Sat, 11 Aug 2012 00:26:47 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id C009F21F84D2 for ; Sat, 11 Aug 2012 00:26:45 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7B7QcXZ005158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 11 Aug 2012 09:26:39 +0200 From: Simon Josefsson To: William Mills References: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> <87hasbd4yq.fsf__31719.1455084414$1344554674$gmane$org@latte.josefsson.org> <87d32zd4rh.fsf@latte.josefsson.org> <1344557814.46045.YahooMailNeo__28311.2241108485$1344557830$gmane$org@web31805.mail.mud.yahoo.com> <874nobcn5o.fsf@latte.josefsson.org> <1344612489.49881.YahooMailNeo__9698.61105918444$1344612510$gmane$org@web31811.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120811:kitten@ietf.org::LErJ/WBmXL5mdafi:AEdY X-Hashcash: 1:22:120811:wmills@yahoo-inc.com::j4tLpH3lbcKmjHnG:E1Ft Date: Sat, 11 Aug 2012 09:26:34 +0200 In-Reply-To: <1344612489.49881.YahooMailNeo__9698.61105918444$1344612510$gmane$org@web31811.mail.mud.yahoo.com> (William Mills's message of "Fri, 10 Aug 2012 08:28:09 -0700 (PDT)") Message-ID: <87y5llanyt.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 07:26:47 -0000 William Mills writes: > I did look at the OPENID example and it does exactly this, and initial > gs2-header, the server responds with a challenge.  In fact, looking at > http://tools.ietf.org/html/rfc6595 section 5.1 it looks wrong to me in > the example, I think it's missing a comma, it has > >     n,,example.org > > and there should be 3 commas there? No, see ABNF from RFC 5801: gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] "," ;; The GS2 header is gs2-header. > That said, having re-read this the gs2-header is terminated by a comma > so I now see how this would work where I did not before. I > specifically did not want to put the authz id outside the OAuth > information, because I think that strays too far from the web based > OAuth model.  Do you think section 3.2.1 is insufficient? SASL requires that the mechanism transfer an opaque authorization identity without modification from the application protocol to the server. The mechanism shouldn't modify it. See RFC 4422. If you add a gs2-header to your initial client response, you are fine and don't have to think about this any more. /Simon > > -bill > > > > >>________________________________ >> From: Simon Josefsson >>To: William Mills >>Cc: "kitten@ietf.org" >>Sent: Thursday, August 9, 2012 10:48 PM >>Subject: Re: Status of draft-ietf-kitten-sasl-oauth? >> >>William Mills writes: >> >>> So in reading http://tools.ietf.org/html/rfc5801 and teh SAML SASL >>> spec it looks like the gs2-header must appear by itself in a message?  >>> Since we don't have a challenge response  model here it sounds like we >>> have to have the following logic: >>> >>> 1)    client sends gs2-header >>> 2)    server sends an empty reply or fail here if auth won't be >>> permitted because CB is required. >>> 3)    client sends OAUTH mechanism auth request >>> 4)    server replies >>> >>> So for the non channel binding case we're forced into an empty round trip.  Correct? >> >>No, the gs2-header can be a prefix of other data, it doesn't have to be >>its own message.  Look at the SCRAM/OPENID/SAML20 protocol examples. >>Thus OAUTH could look like this (ABNF): >> >>initial-client-response := gs2-header oath-data >>oath-data := ... >> >>The important part is that the wire syntax of the OAUTH SASL mechanism >>starts with the gs2-header, and that it has the same semantics as GS2. >> >>Note that the gs2-header transfers the SASL authorization identity which >>is required by the SASL framework, solving that problem as well. >> >>/Simon >> >> >> > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From simon@josefsson.org Sat Aug 11 00:28:42 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142E921F84F1 for ; Sat, 11 Aug 2012 00:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqJnw2Si23Lh for ; Sat, 11 Aug 2012 00:28:41 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5C121F84E4 for ; Sat, 11 Aug 2012 00:28:40 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7B7SZTW005172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 11 Aug 2012 09:28:37 +0200 From: Simon Josefsson To: William Mills References: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> <87hasbd4yq.fsf@latte.josefsson.org> <1344641117.33923.YahooMailNeo__37551.0724298239$1344641134$gmane$org@web31812.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120811:kitten@ietf.org::AQMQUZpaB/NFzLSA:3o+s X-Hashcash: 1:22:120811:wmills@yahoo-inc.com::aRBu4o/QNBm904wR:Oqd1 Date: Sat, 11 Aug 2012 09:28:32 +0200 In-Reply-To: <1344641117.33923.YahooMailNeo__37551.0724298239$1344641134$gmane$org@web31812.mail.mud.yahoo.com> (William Mills's message of "Fri, 10 Aug 2012 16:25:17 -0700 (PDT)") Message-ID: <87txw9anvj.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 07:28:42 -0000 William Mills writes: > In re your comment on 3.4  "Should "authorization scheme" be > "application protocol"?", authorization scheme is intended here.  > Bearer for example has a SHOULD for TLS so I want to carry that > through into this spec. Ah, now I think I understand better the meaning of that paragraph. I think this should be a MUST. There is no sense in using an insecure over non-TLS transports. It is like using PLAIN without TLS. /Simon > I'm going to leave off fixing the channel binding stuff until we decide whether it's staying. > > > > >>________________________________ >> From: Simon Josefsson >>To: William Mills >>Cc: Ryan Troll ; "kitten@ietf.org" >>Sent: Thursday, August 9, 2012 4:24 PM >>Subject: Re: Status of draft-ietf-kitten-sasl-oauth? >> >>William Mills writes: >> >>> There hasn't been a lot of action in any substantive way on the list >>> on this draft, and I think it's pretty well baked.  A working >>> implementation is going to go a long way to nailing this down. >>> >>> Anyone out there with any significant objections or proposed should >>> speak up "real soon now".  >> >>I have reviewed the -03 document, and I believe there are some major >>issues with it. >> >>MAJOR: >> >>* The protocol does not appear to be compatible with the GS2 framing, >>  thus the GSS-API mechanism the document defines would not be >>  wire-compatible with the SASL mechanism.  The SASL packets needs to >>  use the GS2 header to be compatible.  The examples reinforces my >>  readings, they don't begin with the GS2 header.  Compare the SCRAM, >>  OPENID and SAML20 mechanism to see how this should be done. >> >>* I don't see where the mechanism transfers the SASL authorization >>  identity, which is required.  This would be done by the GS2 header. >> >>* I don't follow how the channel binding data is integrity protected. >>  Unless I'm missing some keying, this seems to open up for a MITM to >>  fake channel binding.  Section 3.2: >> >>    In the OAUTH-PLUS mechanism the server examines the channel binding >>    data, extracts the channel binding unique prefix, and extracts the >>    raw channel biding data based on the channel binding type used.  It >>    then computes it's own copy of the channel binding payload and >>    compares that to the payload sent by the client in the cbdata key/ >>    value.  Those two must be equal for channel binding to succeed. >> >>  Presumably the client is not authenticated when this is sent, so the >>  server might as well be talking to an attacker, which sends its own >>  channel binding data. >> >>  I'm not sure I see how OAuth with bearer tokens could support channel >>  bindings at all? >> >>* Section 3.4 seems confusing.  Quoting: >> >>    If the specification for the underlying authorization scheme requires >>    a security layer, such as TLS [RFC5246], the server SHOULD only offer >>    a mechanism where channel binding can be enabled. >> >>  Should "authorization scheme" be "application protocol"? >> >>  Quoting further: >> >>    The channel binding data is computed by the client based on it's >>    choice of preferred channel binding type. >> >>  I think you want something similar to section 5.2 in RFC 5802 instead, >>  to leave the choise of preferred channel binding type up to the >>  application protocol profile (or resume back to a default). >> >>    If the raw channel binding data is 500 >>    bytes or larger then a SHA-1 [RFC3174] hash of the raw channel >>    binding data is computed. >> >>  SHA-1?  This opens up for hash agility concerns. >> >>    If the client is using tls-unique for a channel binding then the raw >>    channel binding data equals the first TLS finished message. >> >>  There is subtlety with renegotiation here, I suggest to quote RFC 5929 >>  instead. >> >>/Simon >> >> >> > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From simon@josefsson.org Sat Aug 11 00:43:50 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809A221F8596 for ; Sat, 11 Aug 2012 00:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTyiyo1jylJS for ; Sat, 11 Aug 2012 00:43:50 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id ADF7121F858A for ; Sat, 11 Aug 2012 00:43:49 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7B7hfLh005898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 11 Aug 2012 09:43:42 +0200 From: Simon Josefsson To: William Mills References: <1344623775.76296.YahooMailNeo@web31801.mail.mud.yahoo.com> <1344624852.76552.YahooMailNeo__46092.9163652056$1344624873$gmane$org@web31812.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120811:wmills@yahoo-inc.com::nHZwmtEKVq72/uxo:F2N7 X-Hashcash: 1:22:120811:cantor.2@osu.edu::2QHJMMAwXFPWNk74:EtoH X-Hashcash: 1:22:120811:kitten@ietf.org::9XTeJLpSLzf7P1dZ:NDLg Date: Sat, 11 Aug 2012 09:43:37 +0200 In-Reply-To: <1344624852.76552.YahooMailNeo__46092.9163652056$1344624873$gmane$org@web31812.mail.mud.yahoo.com> (William Mills's message of "Fri, 10 Aug 2012 11:54:12 -0700 (PDT)") Message-ID: <87pq6xan6e.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 07:43:50 -0000 Which brings up another question: Is the SASL mechanism intended to apply to both OAuth 2.0 and OAuth 1.0? If that is the intention, I think this should be clear from the introduction and throughout the document. This poses some challenges though, since the OAuth 1.x and OAuth 2.x terminology and semantics differs somewhat. I'm working on an implementation, and I've gone back and forth between using libraries for OAuth 1.x and Oauth 2.x. /Simon William Mills writes: > You could have an integrity guarantee for a signed profile like MAC or OAuth 1.0a. > > > > > >>________________________________ >> From: "Cantor, Scott" >>To: William Mills ; "kitten@ietf.org" >>Sent: Friday, August 10, 2012 11:39 AM >>Subject: Re: [kitten] OAUTH SASL and Channel binding >> >>On 8/10/12 2:36 PM, "William Mills" wrote: >> >>>Given Simon's recent comments about the fundamental flaw in the idea of >>>channel binding when you don't have an integrity guarantee,, as in the >>>Bearer token use case, should channel binding remain in the OAuth SASL >>>profile? >> >>If you can never have an integrity guarantee, probably not, but I wouldn't >>personally use such a mechanism in any case, so probably moot. >> >>-- Scott >> >> >> >> > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From wmills@yahoo-inc.com Sat Aug 11 09:10:24 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F40521F859B for ; Sat, 11 Aug 2012 09:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.54 X-Spam-Level: X-Spam-Status: No, score=-17.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq9ezonQnOT1 for ; Sat, 11 Aug 2012 09:10:19 -0700 (PDT) Received: from nm40-vm6.bullet.mail.bf1.yahoo.com (nm40-vm6.bullet.mail.bf1.yahoo.com [72.30.239.214]) by ietfa.amsl.com (Postfix) with ESMTP id 399F121F8599 for ; Sat, 11 Aug 2012 09:10:19 -0700 (PDT) Received: from [98.139.212.153] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 11 Aug 2012 16:10:18 -0000 Received: from [98.139.212.221] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 11 Aug 2012 16:10:18 -0000 Received: from [127.0.0.1] by omp1030.mail.bf1.yahoo.com with NNFMP; 11 Aug 2012 16:10:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 619083.5522.bm@omp1030.mail.bf1.yahoo.com Received: (qmail 39805 invoked by uid 60001); 11 Aug 2012 16:10:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344701418; bh=/avnGs3re3dQu264HUNKIEo3izwrRR9cMWW5r/tGJvI=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DpPTk3j06QA7cja4Yao7xAek4x5u5iPxd/C17zrKnVVRpXcZfg1UR/tpqigLU6GHZ67JDRnn00fEnP+JG1fXndfADyZSqpICJDKkZnj0T7z0drcoYFRxbs2LM8CAmXYpP2WNXPMh0H0uX68wW+d9dAagtgf9Rq3Tjh9KuV2hA9E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OL3yH+e7vTi45zukWC1SwyTdOsLaTpSIeiwQj0iBjc+ZiSC54BWKtTDwKewlnjJRE93s4FzkngUx5it+C/BRLkxgwDMcojTPIrb+V6QH/o6miC/bZIgv0vAKk3kbvqQXuSiqn9fYHJ2EwnBaFJWSOnatOEw7Kyz/P5ZdkAjHKFQ=; X-YMail-OSG: H9HImYsVM1kZT7VAeXD.suYWJU6SnmBgYeXmOBK9CiOde8n 5CJC99kqKcUvll73JMlVROmbcyRbe90gaElno2gWOWecFVAxole2NfRfe6R_ Db.xhuq6DPXMV.aq2Amus9hq7hCqI0K6WqAHh2m8bS9Q4LyTbCGGhu5pBhS. eG6NR_TIeVHYWevA6_vKNDjqKHVbI.eTwSUujVkBOG2eexbddMjIymk2uzdt UBij8RtBB2.9HHnG6d7iVcwGp2i2AAQS47Yt6vFDJDbW.4cxlF98KDGFlks6 q8pNg4jU47YV2F8LND3Y8ReFV6Smw8LLVnB.5R_Tmon8S3bkzko3qIJ4ATa3 UWeuz_ixOXSbnYUjCfkSJ9bulDI4ELXzWqYbL9gM8dW32NUyJSs1roeBPTIi upIu1WkgeSUKVHJhxRxtoSLi00D0UrNTxxRG8NiiIoqwdfVXXnyAjl_T8XXk J6iyVOQ-- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Sat, 11 Aug 2012 09:10:17 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> <87hasbd4yq.fsf@latte.josefsson.org> <1344641117.33923.YahooMailNeo__37551.0724298239$1344641134$gmane$org@web31812.mail.mud.yahoo.com> <87txw9anvj.fsf@latte.josefsson.org> Message-ID: <1344701417.82125.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Sat, 11 Aug 2012 09:10:17 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87txw9anvj.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-1847785979-1344701417=:82125" Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 16:10:24 -0000 --767760015-1847785979-1344701417=:82125 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable While I agree with the MUST in principal, I think in various libraries like= Cyrus SASL channel binding to TLS isn't solved.=A0 I'm reluctant to make i= t MUST knowing we're forcing people to make the choice to be non-compliant.= =0A=0A=0A=0A=0A=0A>________________________________=0A> From: Simon Josefss= on =0A>To: William Mills =0A>Cc= : "kitten@ietf.org" =0A>Sent: Saturday, August 11, 2012 1= 2:28 AM=0A>Subject: Re: Status of draft-ietf-kitten-sasl-oauth?=0A> =0A>Wil= liam Mills writes:=0A>=0A>> In re your comment on 3.= 4=A0 "Should "authorization scheme" be=0A>> "application protocol"?", autho= rization scheme is intended here.=A0=0A>> Bearer for example has a SHOULD f= or TLS so I want to carry that=0A>> through into this spec.=0A>=0A>Ah, now = I think I understand better the meaning of that paragraph.=A0 I=0A>think th= is should be a MUST.=A0 There is no sense in using an insecure=0A>over non-= TLS transports.=A0 It is like using PLAIN without TLS.=0A>=0A>/Simon=0A>=0A= >> I'm going to leave off fixing the channel binding stuff until we decide = whether it's staying.=0A>>=0A>>=0A>>=0A>>=0A>>>____________________________= ____=0A>>> From: Simon Josefsson =0A>>>To: William Mil= ls =0A>>>Cc: Ryan Troll ; "kitt= en@ietf.org" =0A>>>Sent: Thursday, August 9, 2012 4:24 PM= =0A>>>Subject: Re: Status of draft-ietf-kitten-sasl-oauth?=0A>>> =0A>>>Will= iam Mills writes:=0A>>>=0A>>>> There hasn't been a l= ot of action in any substantive way on the list=0A>>>> on this draft, and I= think it's pretty well baked.=A0 A working=0A>>>> implementation is going = to go a long way to nailing this down.=0A>>>>=0A>>>> Anyone out there with = any significant objections or proposed should=0A>>>> speak up "real soon no= w".=A0=0A>>>=0A>>>I have reviewed the -03 document, and I believe there are= some major=0A>>>issues with it.=0A>>>=0A>>>MAJOR:=0A>>>=0A>>>* The protoco= l does not appear to be compatible with the GS2 framing,=0A>>>=A0 thus the = GSS-API mechanism the document defines would not be=0A>>>=A0 wire-compatibl= e with the SASL mechanism.=A0 The SASL packets needs to=0A>>>=A0 use the GS= 2 header to be compatible.=A0 The examples reinforces my=0A>>>=A0 readings,= they don't begin with the GS2 header.=A0 Compare the SCRAM,=0A>>>=A0 OPENI= D and SAML20 mechanism to see how this should be done.=0A>>>=0A>>>* I don't= see where the mechanism transfers the SASL authorization=0A>>>=A0 identity= , which is required.=A0 This would be done by the GS2 header.=0A>>>=0A>>>* = I don't follow how the channel binding data is integrity protected.=0A>>>= =A0 Unless I'm missing some keying, this seems to open up for a MITM to=0A>= >>=A0 fake channel binding.=A0 Section 3.2:=0A>>>=0A>>>=A0 =A0 In the OAUTH= -PLUS mechanism the server examines the channel binding=0A>>>=A0 =A0 data, = extracts the channel binding unique prefix, and extracts the=0A>>>=A0 =A0 r= aw channel biding data based on the channel binding type used.=A0 It=0A>>>= =A0 =A0 then computes it's own copy of the channel binding payload and=0A>>= >=A0 =A0 compares that to the payload sent by the client in the cbdata key/= =0A>>>=A0 =A0 value.=A0 Those two must be equal for channel binding to succ= eed.=0A>>>=0A>>>=A0 Presumably the client is not authenticated when this is= sent, so the=0A>>>=A0 server might as well be talking to an attacker, whic= h sends its own=0A>>>=A0 channel binding data.=0A>>>=0A>>>=A0 I'm not sure = I see how OAuth with bearer tokens could support channel=0A>>>=A0 bindings = at all?=0A>>>=0A>>>* Section 3.4 seems confusing.=A0 Quoting:=0A>>>=0A>>>= =A0 =A0 If the specification for the underlying authorization scheme requir= es=0A>>>=A0 =A0 a security layer, such as TLS [RFC5246], the server SHOULD = only offer=0A>>>=A0 =A0 a mechanism where channel binding can be enabled.= =0A>>>=0A>>>=A0 Should "authorization scheme" be "application protocol"?=0A= >>>=0A>>>=A0 Quoting further:=0A>>>=0A>>>=A0 =A0 The channel binding data i= s computed by the client based on it's=0A>>>=A0 =A0 choice of preferred cha= nnel binding type.=0A>>>=0A>>>=A0 I think you want something similar to sec= tion 5.2 in RFC 5802 instead,=0A>>>=A0 to leave the choise of preferred cha= nnel binding type up to the=0A>>>=A0 application protocol profile (or resum= e back to a default).=0A>>>=0A>>>=A0 =A0 If the raw channel binding data is= 500=0A>>>=A0 =A0 bytes or larger then a SHA-1 [RFC3174] hash of the raw ch= annel=0A>>>=A0 =A0 binding data is computed.=0A>>>=0A>>>=A0 SHA-1?=A0 This = opens up for hash agility concerns.=0A>>>=0A>>>=A0 =A0 If the client is usi= ng tls-unique for a channel binding then the raw=0A>>>=A0 =A0 channel bindi= ng data equals the first TLS finished message.=0A>>>=0A>>>=A0 There is subt= lety with renegotiation here, I suggest to quote RFC 5929=0A>>>=A0 instead.= =0A>>>=0A>>>/Simon=0A>>>=0A>>>=0A>>>=0A>> _________________________________= ______________=0A>> Kitten mailing list=0A>> Kitten@ietf.org=0A>> https://w= ww.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> --767760015-1847785979-1344701417=:82125 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
While I agree wit= h the MUST in principal, I think in various libraries like Cyrus SASL chann= el binding to TLS isn't solved.  I'm reluctant to make it MUST knowing= we're forcing people to make the choice to be non-compliant.


From:<= /b> Simon Josefsson <simon@josefsson.org>
To: William Mills <wmills@yahoo-inc.com> Cc: "kitten@ietf.org" <kitten@i= etf.org>
Sent: Sat= urday, August 11, 2012 12:28 AM
S= ubject: Re: Status of draft-ietf-kitten-sasl-oauth?
 =

=0AWilliam Mills <wmills@yahoo-inc.com> writes:
> In re your comment on 3.4  "Should "authorization scheme" b= e
> "application protocol"?", authorization scheme is intended here.&= nbsp;
> Bearer for example has a SHOULD for TLS so I want to carry th= at
> through into this spec.

Ah, now I think I understand bett= er the meaning of that paragraph.  I
think this should be a MUST.&n= bsp; There is no sense in using an insecure
over non-TLS transports.&nbs= p; It is like using PLAIN without TLS.

/Simon

> I'm going = to leave off fixing the channel binding stuff until we decide whether it's = staying.
>
>
>
>
>>_______________________= _________
>> From: Simon Josefsson <simon@josefsson.org>
>>= ;To: William Mills <wmills@yahoo-inc.com>
>>Cc: Ry= an Troll <rtroll@googlers.com>; "kitten@ietf.org" <kitten@ietf.or= g>
>>Sent: Thursday, August 9, 2012 4:24 PM
>>Sub= ject: Re: Status of draft-ietf-kitten-sasl-oauth?
>>
>>W= illiam Mills <wmills@yahoo-inc.com> writes:
>>
&= gt;>> There hasn't been a lot of action in any substantive way on the= list
>>> on this draft, and I think it's pretty well baked.&nb= sp; A working
>>> implementation is going to go a long way to nailin= g this down.
>>>
>>> Anyone out there with any sign= ificant objections or proposed should
>>> speak up "real soon n= ow". 
>>
>>I have reviewed the -03 document, and I b= elieve there are some major
>>issues with it.
>>
>&= gt;MAJOR:
>>
>>* The protocol does not appear to be compa= tible with the GS2 framing,
>>  thus the GSS-API mechanism th= e document defines would not be
>>  wire-compatible with the = SASL mechanism.  The SASL packets needs to
>>  use the G= S2 header to be compatible.  The examples reinforces my
>>&nb= sp; readings, they don't begin with the GS2 header.  Compare the SCRAM= ,
>>  OPENID and SAML20 mechanism to see how this should be d= one.
>>
>>* I don't see where the mechanism transfers the SASL authorization
>>  identity, which is requ= ired.  This would be done by the GS2 header.
>>
>>* = I don't follow how the channel binding data is integrity protected.
>= >  Unless I'm missing some keying, this seems to open up for a MITM= to
>>  fake channel binding.  Section 3.2:
>><= br>>>    In the OAUTH-PLUS mechanism the server examines th= e channel binding
>>    data, extracts the channel bindi= ng unique prefix, and extracts the
>>    raw channel bid= ing data based on the channel binding type used.  It
>> =   then computes it's own copy of the channel binding payload and
&= gt;>    compares that to the payload sent by the client in the= cbdata key/
>>    value.  Those two must be equal = for channel binding to succeed.
>>
>>  Presumably the client is not authenticated when this is sent, so the
&g= t;>  server might as well be talking to an attacker, which sends it= s own
>>  channel binding data.
>>
>> = I'm not sure I see how OAuth with bearer tokens could support channel
&= gt;>  bindings at all?
>>
>>* Section 3.4 seems c= onfusing.  Quoting:
>>
>>    If the specif= ication for the underlying authorization scheme requires
>>  =   a security layer, such as TLS [RFC5246], the server SHOULD only offe= r
>>    a mechanism where channel binding can be enabled= .
>>
>>  Should "authorization scheme" be "applicati= on protocol"?
>>
>>  Quoting further:
>>>>    The channel binding data is computed by the client b= ased on it's
>>    choice of preferred channel binding type.
>>
>>  I think you want something sim= ilar to section 5.2 in RFC 5802 instead,
>>  to leave the cho= ise of preferred channel binding type up to the
>>  applicati= on protocol profile (or resume back to a default).
>>
>>&= nbsp;   If the raw channel binding data is 500
>>   = ; bytes or larger then a SHA-1 [RFC3174] hash of the raw channel
>>= ;    binding data is computed.
>>
>>  SHA-= 1?  This opens up for hash agility concerns.
>>
>>&n= bsp;   If the client is using tls-unique for a channel binding then th= e raw
>>    channel binding data equals the first TLS fi= nished message.
>>
>>  There is subtlety with renego= tiation here, I suggest to quote RFC 5929
>>  instead.
>= ;>
>>/Simon
>>
>>
>>
> _______________________________________________
> Kitten mailing lis= t
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitt= en


--767760015-1847785979-1344701417=:82125-- From wmills@yahoo-inc.com Sat Aug 11 09:15:55 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD3721F84A1 for ; Sat, 11 Aug 2012 09:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.541 X-Spam-Level: X-Spam-Status: No, score=-17.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AJjHq3RRc2S for ; Sat, 11 Aug 2012 09:15:54 -0700 (PDT) Received: from nm25.bullet.mail.sp2.yahoo.com (nm25.bullet.mail.sp2.yahoo.com [98.139.91.95]) by ietfa.amsl.com (Postfix) with ESMTP id C679921F8498 for ; Sat, 11 Aug 2012 09:15:54 -0700 (PDT) Received: from [98.139.91.70] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 11 Aug 2012 16:15:52 -0000 Received: from [98.139.91.60] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 11 Aug 2012 16:15:52 -0000 Received: from [127.0.0.1] by omp1060.mail.sp2.yahoo.com with NNFMP; 11 Aug 2012 16:15:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 93157.96481.bm@omp1060.mail.sp2.yahoo.com Received: (qmail 42538 invoked by uid 60001); 11 Aug 2012 16:15:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344701751; bh=Z4zTVyETmymZQn/LijLjAtG6BjiwGvt1yU6kZa0sdfI=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mCPw+07MnHpKyvHdM3n431j82+jEm5WAl3+qLvNPMZOzrMMULUJSdLh3RB+vbVN+R9YUb9dJgjsfF/4DsPq7/aI7oNMVvW4viThH3iMEXMsqYNbmVolzBDOYI+Cawk5YoDd2SlT6meVG94NrgRxkJbYREVbLOJ/WqKPIN/C/FTw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cIFIHnrAGUmyUokVAj4F05/njJ0kR3xzkQkyBO5aPE4hx9Rg1QbOQB7yZUZOWSi7q6FYY6UbxQ1wMmCPcA0TJW+DmGsndHUNBmYno6yXQWz0bCINr6U48SCBfNLsOR5tFsjeAXi1ME0vh4NRnaSiMbBwcbNQ+ZIkv8nsBWU9Zeg=; X-YMail-OSG: fZqNphMVM1nGhLOsEXDAq0p_CQwNv7fc30ggjJ65_qV8Rzb bGmpUt8lCmH6u9qTapzfo3N2rnB2Ij0Y9nX8v2pDTP5Ak9.UCl.2IahqZt0V lR4vpUF5yaqFiKogEQMq3VGyYxYa_a0tZHzvoJ2VpP0594DZFHIiSaLbubl8 m2aQbVpZPNSNKyBDMwqA8F9TlypJha3dyaiulQQuuniSxd0UYcE5xgQDCwiQ QSIP2hrg_sEeSwKIZ.9p5JbVVjt3mYHE5M8bTEzLZYgz.c5_qtnBTBB0vRTw p8dzIrZUBubCjE2RoI9orOh_tOXgKSv7Ohg4IVZZa_Y1kduxnd4hbNpVDXEQ YgiPSDaRDzzubKIxletiFNiD8g3YtVP.kBPlRSKe4THK6lE.j5NtvfO7TUrF 00s06VMMTgiX_X6XsKcgYEEynxEJqzkB0sMqaN_GXIUBGpaE0xik3AymG7HA t9c8L6fM- Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Sat, 11 Aug 2012 09:15:51 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1344623775.76296.YahooMailNeo@web31801.mail.mud.yahoo.com> <1344624852.76552.YahooMailNeo__46092.9163652056$1344624873$gmane$org@web31812.mail.mud.yahoo.com> <87pq6xan6e.fsf@latte.josefsson.org> Message-ID: <1344701751.82462.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Sat, 11 Aug 2012 09:15:51 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87pq6xan6e.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-647340386-1344701751=:82462" Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 16:15:55 -0000 ---1055047407-647340386-1344701751=:82462 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Early on there was resistance from folks to mentioning OAuth 1.0a because "= there's no point, OAuth 1.0a is dead".=A0 I can add the text back in easily= .=A0 Given the arguments about reviving the MAC draft in the OAuth WG I cou= ld change the MAC examples out to OAuth 1.0a so this draft relies on a fina= lized spec instead. =0A=0ADo people like that?=A0 Hate it?=0A=0A=0A=0A=0A= =0A>________________________________=0A> From: Simon Josefsson =0A>To: William Mills =0A>Cc: "Cantor, Scot= t" ; "kitten@ietf.org" =0A>Sent: Saturd= ay, August 11, 2012 12:43 AM=0A>Subject: Re: OAUTH SASL and Channel binding= =0A> =0A>Which brings up another question: Is the SASL mechanism intended t= o=0A>apply to both OAuth 2.0 and OAuth 1.0?=A0 If that is the intention, I= =0A>think this should be clear from the introduction and throughout the=0A>= document.=A0 This poses some challenges though, since the OAuth 1.x and=0A>= OAuth 2.x terminology and semantics differs somewhat.=0A>=0A>I'm working on= an implementation, and I've gone back and forth between=0A>using libraries= for OAuth 1.x and Oauth 2.x.=0A>=0A>/Simon=0A>=0A>William Mills writes:=0A>=0A>> You could have an integrity guarantee for a s= igned profile like MAC or OAuth 1.0a.=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>>_______= _________________________=0A>>> From: "Cantor, Scott" =0A= >>>To: William Mills ; "kitten@ietf.org" =0A>>>Sent: Friday, August 10, 2012 11:39 AM=0A>>>Subject: Re: [kitte= n] OAUTH SASL and Channel binding=0A>>> =0A>>>On 8/10/12 2:36 PM, "William = Mills" wrote:=0A>>>=0A>>>>Given Simon's recent comme= nts about the fundamental flaw in the idea of=0A>>>>channel binding when yo= u don't have an integrity guarantee,, as in the=0A>>>>Bearer token use case= , should channel binding remain in the OAuth SASL=0A>>>>profile?=0A>>>=0A>>= >If you can never have an integrity guarantee, probably not, but I wouldn't= =0A>>>personally use such a mechanism in any case, so probably moot.=0A>>>= =0A>>>-- Scott=0A>>>=0A>>>=0A>>>=0A>>>=0A>> _______________________________= ________________=0A>> Kitten mailing list=0A>> Kitten@ietf.org=0A>> https:/= /www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> ---1055047407-647340386-1344701751=:82462 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Early on there wa= s resistance from folks to mentioning OAuth 1.0a because "there's no point,= OAuth 1.0a is dead".  I can add the text back in easily.  Given = the arguments about reviving the MAC draft in the OAuth WG I could change t= he MAC examples out to OAuth 1.0a so this draft relies on a finalized spec = instead.

Do people like that?  Hate it?


<= hr size=3D"1"> From: Simon= Josefsson <simon@josefsson.org>
To:<= /span> William Mills <wmills@yahoo-inc.com>
Cc: "Cantor, Scott" <cantor.2@osu.edu>= ;; "kitten@ietf.org" <kitten@ietf.org>
Sent: Saturday, August 11, 2012 12:43 AM
Subject: Re: OAUTH SASL and Chan= nel binding

=0AWhich brings up another question: Is = the SASL mechanism intended to
apply to both OAuth 2.0 and OAuth 1.0?&nb= sp; If that is the intention, I
think this should be clear from the intr= oduction and throughout the
document.  This poses some challenges t= hough, since the OAuth 1.x and
OAuth 2.x terminology and semantics diffe= rs somewhat.

I'm working on an implementation, and I've gone back an= d forth between
using libraries for OAuth 1.x and Oauth 2.x.

/Sim= on

William Mills <wmills@yahoo-inc.com> writes:
> You could have an integrity guarantee for a signed profile like MAC = or OAuth 1.0a.
>
>
>
>
>
>>_________= _______________________
>> From: "Cantor, Scott" <cantor.2@osu.edu= >
>>To: William Mills <wmills@yahoo-inc.com>; "kitten@ietf.org" <kitten@ietf.org= >
>>Sent: Friday, August 10, 2012 11:39 AM
>>Subject:= Re: [kitten] OAUTH SASL and Channel binding
>>
>>On 8/1= 0/12 2:36 PM, "William Mills" <wmills@yahoo-inc.com> wrote:<= br>>>
>>>Given Simon's recent comments about the fundamen= tal flaw in the idea of
>>>channel binding when you don't have = an integrity guarantee,, as in the
>>>Bearer token use case, sh= ould channel binding remain in the OAuth SASL
>>>profile?
&g= t;>
>>If you can never have an integrity guarantee, probably no= t, but I wouldn't
>>personally use such a mechanism in any case, so probab= ly moot.
>>
>>-- Scott
>>
>>
>>= ;
>>
> _______________________________________________
&g= t; Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.or= g/mailman/listinfo/kitten


=
---1055047407-647340386-1344701751=:82462-- From hannes.tschofenig@gmx.net Sat Aug 11 09:53:25 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B8121F8578 for ; Sat, 11 Aug 2012 09:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTU4Fb43aYG4 for ; Sat, 11 Aug 2012 09:53:25 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id CAE4921F8599 for ; Sat, 11 Aug 2012 09:53:24 -0700 (PDT) Received: (qmail invoked by alias); 11 Aug 2012 16:53:23 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.108]) [88.115.216.191] by mail.gmx.net (mp070) with SMTP; 11 Aug 2012 18:53:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18HAhQQ/sMHegXPE9V0sjQw7YHH+DQYCW1YAVJr4x Qo+PJwslwGN1we Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <1344701751.82462.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Sat, 11 Aug 2012 19:53:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8D5D7C2F-03F6-4581-8D88-CD11F67F0798@gmx.net> References: <1344623775.76296.YahooMailNeo@web31801.mail.mud.yahoo.com> <1344624852.76552.YahooMailNeo__46092.9163652056$1344624873$gmane$org@web31812.mail.mud.yahoo.com> <87pq6xan6e.fsf@latte.josefsson.org> <1344701751.82462.YahooMailNeo@web31806.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 16:53:25 -0000 I would not worry about OAuth 1.0 since the functionality we want in = SASL OAuth is much better supported by OAuth 2.0. On Aug 11, 2012, at 7:15 PM, William Mills wrote: > Early on there was resistance from folks to mentioning OAuth 1.0a = because "there's no point, OAuth 1.0a is dead". I can add the text back = in easily. Given the arguments about reviving the MAC draft in the = OAuth WG I could change the MAC examples out to OAuth 1.0a so this draft = relies on a finalized spec instead.=20 >=20 > Do people like that? Hate it? >=20 >=20 > From: Simon Josefsson > To: William Mills =20 > Cc: "Cantor, Scott" ; "kitten@ietf.org" = =20 > Sent: Saturday, August 11, 2012 12:43 AM > Subject: Re: OAUTH SASL and Channel binding >=20 > Which brings up another question: Is the SASL mechanism intended to > apply to both OAuth 2.0 and OAuth 1.0? If that is the intention, I > think this should be clear from the introduction and throughout the > document. This poses some challenges though, since the OAuth 1.x and > OAuth 2.x terminology and semantics differs somewhat. >=20 > I'm working on an implementation, and I've gone back and forth between > using libraries for OAuth 1.x and Oauth 2.x. >=20 > /Simon >=20 > William Mills writes: >=20 > > You could have an integrity guarantee for a signed profile like MAC = or OAuth 1.0a. > > > > > > > > > > > >>________________________________ > >> From: "Cantor, Scott" > >>To: William Mills ; "kitten@ietf.org" = =20 > >>Sent: Friday, August 10, 2012 11:39 AM > >>Subject: Re: [kitten] OAUTH SASL and Channel binding > >>=20 > >>On 8/10/12 2:36 PM, "William Mills" wrote: > >> > >>>Given Simon's recent comments about the fundamental flaw in the = idea of > >>>channel binding when you don't have an integrity guarantee,, as in = the > >>>Bearer token use case, should channel binding remain in the OAuth = SASL > >>>profile? > >> > >>If you can never have an integrity guarantee, probably not, but I = wouldn't > >>personally use such a mechanism in any case, so probably moot. > >> > >>-- Scott > >> > >> > >> > >> > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten >=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From wmills@yahoo-inc.com Sat Aug 11 10:09:01 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D794621F85DD for ; Sat, 11 Aug 2012 10:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.542 X-Spam-Level: X-Spam-Status: No, score=-17.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+9mc42qxBcm for ; Sat, 11 Aug 2012 10:09:00 -0700 (PDT) Received: from nm9-vm0.bullet.mail.sp2.yahoo.com (nm9-vm0.bullet.mail.sp2.yahoo.com [98.139.91.196]) by ietfa.amsl.com (Postfix) with ESMTP id E142A21F85D6 for ; Sat, 11 Aug 2012 10:09:00 -0700 (PDT) Received: from [98.139.91.66] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 11 Aug 2012 17:08:58 -0000 Received: from [72.30.22.39] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 11 Aug 2012 17:08:58 -0000 Received: from [127.0.0.1] by omp1069.mail.sp2.yahoo.com with NNFMP; 11 Aug 2012 17:08:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 295413.11777.bm@omp1069.mail.sp2.yahoo.com Received: (qmail 69981 invoked by uid 60001); 11 Aug 2012 17:08:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344704937; bh=cbtZiP7AapKIHjhy6+lHIJh0rRYzvNhz96e+VmNIQxc=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YG/zRfoGvbwK75lviFR/hq14dk6yijVM8YjZsa0BfR91kZ5wMzbQMkAquOwvcI4Ota1qpg/Wo72KibSUTj5EScnlAe3ap6k5KURe4vxiJuuf7kkrJnQgDezeTXtgbM8HzcfDvezqB84bzPvccxILlHnaXENKAxUl/hcF78VnewA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Y6q+rVh50CESlgODW+Ty0+WrauSX2DcZPP4XUbo+TZzbRR/E01qRaKNlqM2tisktbBzB4GqYjOpazqU2mjGe9qxv8kYMFwa47Z8vh2ULNh8u8TOlx90rjaFqW/9N0ovKeev1Krz+Y3evhba1+6F95sfHWJ4KhF2xt0Byb0oIuw0=; X-YMail-OSG: 4VGceUsVM1k3nw8KG4OZB7gJYm.VfWmv8XHQhsjklkmdFhb UZkBRjTy3Hlpt2hlN3Nk6dCEE8p8W9R3zSg3OMOl1LToqC9vO1YzrBxpbuv2 QzrLDaXhnxn1_A0KUfkC4rneg7BxNkiKC0Vf6xbOIpcHurx04vuZCi_e8D4a gXIVtm_Or_RMAwfIJeICE9tSKS0JLIDfkL9hnAFyKsMVy1wmDxrgQ3I0f1gC WjnNOskIG40UQoL17cADVUtRLlVspOfvr.ZvN9B_73jHhc5y6lBKA7O60h1z YpvNsR.mx6xgrOBmMDBnA2GmZYkGhBYFRUnEaVv2AB_W1uYMgA1x_EvGNEBI XnSEtnXNoLRLx0_JCQm8QRrQn5g.EcmrrOwCoNxoSCcyZIIBPN8Thp5tGX82 YcRGQ2JPOETwtaspvu_hKT_8bEDvFvG.dAANZnfv6N4kTgUoqGkD2I7sHHTN UQ4.KI34- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Sat, 11 Aug 2012 10:08:57 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1344623775.76296.YahooMailNeo@web31801.mail.mud.yahoo.com> <1344624852.76552.YahooMailNeo__46092.9163652056$1344624873$gmane$org@web31812.mail.mud.yahoo.com> <87pq6xan6e.fsf@latte.josefsson.org> <1344701751.82462.YahooMailNeo@web31806.mail.mud.yahoo.com> <8D5D7C2F-03F6-4581-8D88-CD11F67F0798@gmx.net> Message-ID: <1344704937.48592.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Sat, 11 Aug 2012 10:08:57 -0700 (PDT) From: William Mills To: Hannes Tschofenig In-Reply-To: <8D5D7C2F-03F6-4581-8D88-CD11F67F0798@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-348224349-1344704937=:48592" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 17:09:02 -0000 --767760015-348224349-1344704937=:48592 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable That's arguable.=A0 I have use cases where without MAC actually being avail= able as a draft (which it's expired right now) where I want a signed token = for integrations and the integration includes IMAP.=A0 It's one of the reas= ons I've made sure OAuth 1.0a will work.=A0 I also do actually want a signe= d example in the spec.=0A=0A=0A-bill=0A=0A=0A=0A=0A>_______________________= _________=0A> From: Hannes Tschofenig =0A>To: Wi= lliam Mills =0A>Cc: Hannes Tschofenig ; Simon Josefsson ; "kitten@ietf.org" =0A>Sent: Saturday, August 11, 2012 9:53 AM=0A>Subject: Re: = [kitten] OAUTH SASL and Channel binding=0A> =0A>I would not worry about OAu= th 1.0 since the functionality we want in SASL OAuth is much better support= ed by OAuth 2.0.=0A>=0A>On Aug 11, 2012, at 7:15 PM, William Mills wrote:= =0A>=0A>> Early on there was resistance from folks to mentioning OAuth 1.0a= because "there's no point, OAuth 1.0a is dead".=A0 I can add the text back= in easily.=A0 Given the arguments about reviving the MAC draft in the OAut= h WG I could change the MAC examples out to OAuth 1.0a so this draft relies= on a finalized spec instead. =0A>> =0A>> Do people like that?=A0 Hate it?= =0A>> =0A>> =0A>> From: Simon Josefsson =0A>> To: Will= iam Mills =0A>> Cc: "Cantor, Scott" ; "kitten@ietf.org" =0A>> Sent: Saturday, August 11, 20= 12 12:43 AM=0A>> Subject: Re: OAUTH SASL and Channel binding=0A>> =0A>> Whi= ch brings up another question: Is the SASL mechanism intended to=0A>> apply= to both OAuth 2.0 and OAuth 1.0?=A0 If that is the intention, I=0A>> think= this should be clear from the introduction and throughout the=0A>> documen= t.=A0 This poses some challenges though, since the OAuth 1.x and=0A>> OAuth= 2.x terminology and semantics differs somewhat.=0A>> =0A>> I'm working on = an implementation, and I've gone back and forth between=0A>> using librarie= s for OAuth 1.x and Oauth 2.x.=0A>> =0A>> /Simon=0A>> =0A>> William Mills <= wmills@yahoo-inc.com> writes:=0A>> =0A>> > You could have an integrity guar= antee for a signed profile like MAC or OAuth 1.0a.=0A>> >=0A>> >=0A>> >=0A>= > >=0A>> >=0A>> >>________________________________=0A>> >> From: "Cantor, S= cott" =0A>> >>To: William Mills ; "= kitten@ietf.org" =0A>> >>Sent: Friday, August 10, 2012 11= :39 AM=0A>> >>Subject: Re: [kitten] OAUTH SASL and Channel binding=0A>> >> = =0A>> >>On 8/10/12 2:36 PM, "William Mills" wrote:= =0A>> >>=0A>> >>>Given Simon's recent comments about the fundamental flaw i= n the idea of=0A>> >>>channel binding when you don't have an integrity guar= antee,, as in the=0A>> >>>Bearer token use case, should channel binding rem= ain in the OAuth SASL=0A>> >>>profile?=0A>> >>=0A>> >>If you can never have= an integrity guarantee, probably not, but I wouldn't=0A>> >>personally use= such a mechanism in any case, so probably moot.=0A>> >>=0A>> >>-- Scott=0A= >> >>=0A>> >>=0A>> >>=0A>> >>=0A>> > ______________________________________= _________=0A>> > Kitten mailing list=0A>> > Kitten@ietf.org=0A>> > https://= www.ietf.org/mailman/listinfo/kitten=0A>> =0A>> =0A>> _____________________= __________________________=0A>> Kitten mailing list=0A>> Kitten@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A>=0A> --767760015-348224349-1344704937=:48592 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
That's arguable.&= nbsp; I have use cases where without MAC actually being available as a draf= t (which it's expired right now) where I want a signed token for integratio= ns and the integration includes IMAP.  It's one of the reasons I've ma= de sure OAuth 1.0a will work.  I also do actually want a signed exampl= e in the spec.

-b= ill

From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: William Mills <wmills@yahoo-inc.= com>
Cc: Hannes Tsc= hofenig <hannes.tschofenig@gmx.net>; Simon Josefsson <simon@josefs= son.org>; "kitten@ietf.org" <kitten@ietf.org>
Sent: Saturday, August 11, 2012 9:53 AM<= br> Subject: Re: [kitten] = OAUTH SASL and Channel binding

=0AI would not worry = about OAuth 1.0 since the functionality we want in SASL OAuth is much bette= r supported by OAuth 2.0.

On Aug 11, 2012, at 7:15 PM, William Mills= wrote:

> Early on there was resistance from folks to mentioning = OAuth 1.0a because "there's no point, OAuth 1.0a is dead".  I can add = the text back in easily.  Given the arguments about reviving the MAC d= raft in the OAuth WG I could change the MAC examples out to OAuth 1.0a so t= his draft relies on a finalized spec instead.
>
> Do people l= ike that?  Hate it?
>
>
> From: Simon Josefsson &l= t;simon@josefsson.org>
> To: William Mills <wmill= s@yahoo-inc.com>
> Cc: "Cantor, Scott" <cantor.2@osu.edu>; "kitten@ietf.org= " <kitten@ietf.org>
> Sent: Saturday, August 11, 2012 12:43 AM<= br>> Subject: Re: OAUTH SASL and Channel binding
>
> Which = brings up another question: Is the SASL mechanism intended to
> apply= to both OAuth 2.0 and OAuth 1.0?  If that is the intention, I
>= think this should be clear from the introduction and throughout the
>= ; document.  This poses some challenges though, since the OAuth 1.x an= d
> OAuth 2.x terminology and semantics differs somewhat.
> > I'm working on an implementation, and I've gone back and forth betwee= n
> using libraries for OAuth 1.x and Oauth 2.x.
>
> /Si= mon
>
> William Mills <wmills@yahoo-inc.com> writes:
>
> > You could hav= e an integrity guarantee for a signed profile like MAC or OAuth 1.0a.
&g= t; >
> >
> >
> >
> >
> >>= ;________________________________
> >> From: "Cantor, Scott" &l= t;c= antor.2@osu.edu>
> >>To: William Mills <wmills@y= ahoo-inc.com>; "kitten@ietf.org" <kitten@ietf.org>
> >= >Sent: Friday, August 10, 2012 11:39 AM
> >>Subject: Re: [ki= tten] OAUTH SASL and Channel binding
> >>
> >>On 8= /10/12 2:36 PM, "William Mills" <wmills@yahoo-inc.com> wrote:
> &= gt;>
> >>>Given Simon's recent comments about the fundame= ntal flaw in the idea of
> >>>channel binding when you don't= have an integrity guarantee,, as in the
> >>>Bearer token u= se case, should channel binding remain in the OAuth SASL
> >>&g= t;profile?
> >>
> >>If you can never have an integr= ity guarantee, probably not, but I wouldn't
> >>personally use = such a mechanism in any case, so probably moot.
> >>
> &g= t;>-- Scott
> >>
> >>
> >>
> &= gt;>
> > _______________________________________________
>= ; > Kitten mailing list
> > Kitten@ietf.org
> > ht= tps://www.ietf.org/mailman/listinfo/kitten
>
>
> __= _____________________________________________
> Kitten mailing list> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten<= /a>



--767760015-348224349-1344704937=:48592-- From hannes.tschofenig@gmx.net Sat Aug 11 10:14:42 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B8821F8617 for ; Sat, 11 Aug 2012 10:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PxiznqmUhyJ for ; Sat, 11 Aug 2012 10:14:41 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id ECA3D21F8611 for ; Sat, 11 Aug 2012 10:14:40 -0700 (PDT) Received: (qmail invoked by alias); 11 Aug 2012 17:14:39 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.108]) [88.115.216.191] by mail.gmx.net (mp031) with SMTP; 11 Aug 2012 19:14:39 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/A5A0XKlrA7M/Z411IAYFhrfPNjYUr8ngc+xNvJv HMteWMR9Of4Ikl Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <8D5D7C2F-03F6-4581-8D88-CD11F67F0798@gmx.net> Date: Sat, 11 Aug 2012 20:14:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5EDD7D12-9858-4161-885C-F22C976C0593@gmx.net> References: <1344623775.76296.YahooMailNeo@web31801.mail.mud.yahoo.com> <1344624852.76552.YahooMailNeo__46092.9163652056$1344624873$gmane$org@web31812.mail.mud.yahoo.com> <87pq6xan6e.fsf@latte.josefsson.org> <1344701751.82462.YahooMailNeo@web31806.mail.mud.yahoo.com> <8D5D7C2F-03F6-4581-8D88-CD11F67F0798@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 17:14:42 -0000 I should probably add a bit more text. We don't need the MAC or PK-based signature mechanism since they are not = 1:1 compatible with what we are doing in SASL. So, we can ignore them. = In addition, the PK-based signature mechanism has the problem that it = does not provide a story for how the client dynamically obtains the = public / private key. In a nutshell it is undeployable.=20 Depending on the timeline you have in mind we may either re-use the = Bearer Token specification or wait for the current security discussions = to settle to add a more secure mechanism. There may also be no harm to = define our own security mechanism for presenting the access token to the = resource server if we want channel binding and other security features = added since those will not likely be used in the HTTPS environment due = to TLS load balancers.=20 An important part from the OAuth specifications we want is a mechanism = for requesting an access token and to obtain the resource owners consent = prior to that step. OAuth 2.0 provides a well-written specification for = that. Additionally, there is a lot of deployment available.=20 We may, however, indicate that we only want to support the = 'Authorization Code' grant type and not the other grant types since they = are not useful in our scenario. =20 Ciao Hannes On Aug 11, 2012, at 7:53 PM, Hannes Tschofenig wrote: > I would not worry about OAuth 1.0 since the functionality we want in = SASL OAuth is much better supported by OAuth 2.0. >=20 > On Aug 11, 2012, at 7:15 PM, William Mills wrote: >=20 >> Early on there was resistance from folks to mentioning OAuth 1.0a = because "there's no point, OAuth 1.0a is dead". I can add the text back = in easily. Given the arguments about reviving the MAC draft in the = OAuth WG I could change the MAC examples out to OAuth 1.0a so this draft = relies on a finalized spec instead.=20 >>=20 >> Do people like that? Hate it? >>=20 >>=20 >> From: Simon Josefsson >> To: William Mills =20 >> Cc: "Cantor, Scott" ; "kitten@ietf.org" = =20 >> Sent: Saturday, August 11, 2012 12:43 AM >> Subject: Re: OAUTH SASL and Channel binding >>=20 >> Which brings up another question: Is the SASL mechanism intended to >> apply to both OAuth 2.0 and OAuth 1.0? If that is the intention, I >> think this should be clear from the introduction and throughout the >> document. This poses some challenges though, since the OAuth 1.x and >> OAuth 2.x terminology and semantics differs somewhat. >>=20 >> I'm working on an implementation, and I've gone back and forth = between >> using libraries for OAuth 1.x and Oauth 2.x. >>=20 >> /Simon >>=20 >> William Mills writes: >>=20 >>> You could have an integrity guarantee for a signed profile like MAC = or OAuth 1.0a. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> ________________________________ >>>> From: "Cantor, Scott" >>>> To: William Mills ; "kitten@ietf.org" = =20 >>>> Sent: Friday, August 10, 2012 11:39 AM >>>> Subject: Re: [kitten] OAUTH SASL and Channel binding >>>>=20 >>>> On 8/10/12 2:36 PM, "William Mills" wrote: >>>>=20 >>>>> Given Simon's recent comments about the fundamental flaw in the = idea of >>>>> channel binding when you don't have an integrity guarantee,, as in = the >>>>> Bearer token use case, should channel binding remain in the OAuth = SASL >>>>> profile? >>>>=20 >>>> If you can never have an integrity guarantee, probably not, but I = wouldn't >>>> personally use such a mechanism in any case, so probably moot. >>>>=20 >>>> -- Scott >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>> _______________________________________________ >>> Kitten mailing list >>> Kitten@ietf.org >>> https://www.ietf.org/mailman/listinfo/kitten >>=20 >>=20 >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten >=20 From hannes.tschofenig@gmx.net Sat Aug 11 10:16:49 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF05821F8484 for ; Sat, 11 Aug 2012 10:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1yjGCNlQYOi for ; Sat, 11 Aug 2012 10:16:48 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 893B021F847C for ; Sat, 11 Aug 2012 10:16:43 -0700 (PDT) Received: (qmail invoked by alias); 11 Aug 2012 17:16:42 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.108]) [88.115.216.191] by mail.gmx.net (mp030) with SMTP; 11 Aug 2012 19:16:42 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18qZY47IQUqqbZOZK5BzWOkiDaDiP7oiTWsHnFURw Vnk0LhsNWNw60U Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <1344704937.48592.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Sat, 11 Aug 2012 20:16:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1344623775.76296.YahooMailNeo@web31801.mail.mud.yahoo.com> <1344624852.76552.YahooMailNeo__46092.9163652056$1344624873$gmane$org@web31812.mail.mud.yahoo.com> <87pq6xan6e.fsf@latte.josefsson.org> <1344701751.82462.YahooMailNeo@web31806.mail.mud.yahoo.com> <8D5D7C2F-03F6-4581-8D88-CD11F67F0798@gmx.net> <1344704937.48592.YahooMailNeo@web31813.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 17:16:50 -0000 I provided more details in a follow-up mail and I don't think there is = value in "inheriting the OAuth 1.0 functionality" for the signature = mechanism since it is not compatible with what we are doing here anyway. = We have to write new normative text to explain what it means for this = specific usage (which is so different from HTTP), then we have = additional security needs (such as TLS with channel binding), so that it = is easier to just write the text we want in the draft ourselves.=20 On Aug 11, 2012, at 8:08 PM, William Mills wrote: > That's arguable. I have use cases where without MAC actually being = available as a draft (which it's expired right now) where I want a = signed token for integrations and the integration includes IMAP. It's = one of the reasons I've made sure OAuth 1.0a will work. I also do = actually want a signed example in the spec. >=20 > -bill >=20 > From: Hannes Tschofenig > To: William Mills =20 > Cc: Hannes Tschofenig ; Simon Josefsson = ; "kitten@ietf.org" =20 > Sent: Saturday, August 11, 2012 9:53 AM > Subject: Re: [kitten] OAUTH SASL and Channel binding >=20 > I would not worry about OAuth 1.0 since the functionality we want in = SASL OAuth is much better supported by OAuth 2.0. >=20 > On Aug 11, 2012, at 7:15 PM, William Mills wrote: >=20 > > Early on there was resistance from folks to mentioning OAuth 1.0a = because "there's no point, OAuth 1.0a is dead". I can add the text back = in easily. Given the arguments about reviving the MAC draft in the = OAuth WG I could change the MAC examples out to OAuth 1.0a so this draft = relies on a finalized spec instead.=20 > >=20 > > Do people like that? Hate it? > >=20 > >=20 > > From: Simon Josefsson > > To: William Mills =20 > > Cc: "Cantor, Scott" ; "kitten@ietf.org" = =20 > > Sent: Saturday, August 11, 2012 12:43 AM > > Subject: Re: OAUTH SASL and Channel binding > >=20 > > Which brings up another question: Is the SASL mechanism intended to > > apply to both OAuth 2.0 and OAuth 1.0? If that is the intention, I > > think this should be clear from the introduction and throughout the > > document. This poses some challenges though, since the OAuth 1.x = and > > OAuth 2.x terminology and semantics differs somewhat. > >=20 > > I'm working on an implementation, and I've gone back and forth = between > > using libraries for OAuth 1.x and Oauth 2.x. > >=20 > > /Simon > >=20 > > William Mills writes: > >=20 > > > You could have an integrity guarantee for a signed profile like = MAC or OAuth 1.0a. > > > > > > > > > > > > > > > > > >>________________________________ > > >> From: "Cantor, Scott" > > >>To: William Mills ; "kitten@ietf.org" = =20 > > >>Sent: Friday, August 10, 2012 11:39 AM > > >>Subject: Re: [kitten] OAUTH SASL and Channel binding > > >>=20 > > >>On 8/10/12 2:36 PM, "William Mills" wrote: > > >> > > >>>Given Simon's recent comments about the fundamental flaw in the = idea of > > >>>channel binding when you don't have an integrity guarantee,, as = in the > > >>>Bearer token use case, should channel binding remain in the OAuth = SASL > > >>>profile? > > >> > > >>If you can never have an integrity guarantee, probably not, but I = wouldn't > > >>personally use such a mechanism in any case, so probably moot. > > >> > > >>-- Scott > > >> > > >> > > >> > > >> > > > _______________________________________________ > > > Kitten mailing list > > > Kitten@ietf.org > > > https://www.ietf.org/mailman/listinfo/kitten > >=20 > >=20 > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten >=20 >=20 >=20 From wmills@yahoo-inc.com Sat Aug 11 10:33:07 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076E121F8613 for ; Sat, 11 Aug 2012 10:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.543 X-Spam-Level: X-Spam-Status: No, score=-17.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSI4Y9lNiTFy for ; Sat, 11 Aug 2012 10:33:05 -0700 (PDT) Received: from nm18-vm0.bullet.mail.sp2.yahoo.com (nm18-vm0.bullet.mail.sp2.yahoo.com [98.139.91.214]) by ietfa.amsl.com (Postfix) with ESMTP id 7066B21F860F for ; Sat, 11 Aug 2012 10:33:05 -0700 (PDT) Received: from [98.139.91.65] by nm18.bullet.mail.sp2.yahoo.com with NNFMP; 11 Aug 2012 17:33:05 -0000 Received: from [98.139.91.32] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 11 Aug 2012 17:33:05 -0000 Received: from [127.0.0.1] by omp1032.mail.sp2.yahoo.com with NNFMP; 11 Aug 2012 17:33:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 376833.15103.bm@omp1032.mail.sp2.yahoo.com Received: (qmail 63648 invoked by uid 60001); 11 Aug 2012 17:33:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344706384; bh=O+x8nzFQbH0ybt9Oo51e/QuRz5x3uPtUCXBIs14a2Hw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nvj5+ZD8FlTHlgAMkg1524iTJ6A9IBv8JiP5sPRua8QIczoH9pHFfoe9US2QA2tpY3Zw4BwN2voely8QgO0WPdb6dM9rFh6qXm9Fuwqp+R2ADQb/VRNpdWKdJZkPKM3XALUo3NzVIKYTq6yMd2WIzl1mrUrm44Iof6FNymNXGb8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HB+P9i8vBDNfKaPcjAr6v1XyZOJFFlJEvN2dpjDx7ab0XfviZMbdQJTwR+ujMC5yJLkHY38ubYDlKEujwgjamDsMWx7OYV8oWPnZdF5bQOVUCGO+GX7l1DccxJrNn1wMIDipOVoXte5SFImTJZBEXuqQrCiiOjVPiSkempXEa2k=; X-YMail-OSG: 1k8B5.EVM1nBjqwl0TWV03r2JqnPbhi3HJoxxVvEDhq.ObA y9ukUA5fK7aWTqwR8Y_70kgI21teHKNAqZ.FxSIuF3y.Sk9ugltHwEFGq1Si X.k965EF.WWcogIIyyuLRVwkqNA0Fp6.ZnzXgscbIuOtxKW42xTYgoQQotFh w6RETsGwy1AGkLBYLq7UTIh8OXPdgKrKIvvQ1wSgMc4hX81.Q4U3Aam2w2hf 10BWWllNnm5lvVqnrWuEXqK5DU1cRcV2yk4qySfzRKFEGIoMbJzFAgHGDlQ6 pQSqIjSc7B70w.Z342NazzeggjoAhhffOo_zmyQh5i339ryVCLOnx1llF7Pt TLoUSjoyj3jmGVcRXRZtoq_._obMB7sb8LlgqB8Qicn7eA5w1OP6bJ2ah15P VjhBjfQ3Q17nrc6LiSPL6O2goPxcnQluy3DoJQJgfLGmP2t5X16W6cSJJCsa 5eRRyxg-- Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Sat, 11 Aug 2012 10:33:04 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1344623775.76296.YahooMailNeo@web31801.mail.mud.yahoo.com> <1344624852.76552.YahooMailNeo__46092.9163652056$1344624873$gmane$org@web31812.mail.mud.yahoo.com> <87pq6xan6e.fsf@latte.josefsson.org> <1344701751.82462.YahooMailNeo@web31806.mail.mud.yahoo.com> <8D5D7C2F-03F6-4581-8D88-CD11F67F0798@gmx.net> <5EDD7D12-9858-4161-885C-F22C976C0593@gmx.net> Message-ID: <1344706384.36422.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Sat, 11 Aug 2012 10:33:04 -0700 (PDT) From: William Mills To: Hannes Tschofenig In-Reply-To: <5EDD7D12-9858-4161-885C-F22C976C0593@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-1548814758-1344706384=:36422" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 17:33:07 -0000 ---551393103-1548814758-1344706384=:36422 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable We fundamentally disagree on a number of things here.=A0 As a practical mat= ter we need to support the password grant.=A0 =0A=0APlease explain how MAC,= or a signature mechanism, is not 1:1 compatible.=A0 To me it seems a solid= fit, it was part of the design.=0A=0AI do not want to use this to define a= new way of getting tokens or PKI or define new tokens that support channel= binding.=A0 This is specifically for leveraging the OAuth infrastructure w= hich already defines much or all of this.=0A=0A-bill=0A=0A=0A=0A=0A=0A>____= ____________________________=0A> From: Hannes Tschofenig =0A>To: Hannes Tschofenig =0A>Cc: Will= iam Mills ; Simon Josefsson ; "k= itten@ietf.org" =0A>Sent: Saturday, August 11, 2012 10:14= AM=0A>Subject: Re: [kitten] OAUTH SASL and Channel binding=0A> =0A>I shoul= d probably add a bit more text.=0A>=0A>We don't need the MAC or PK-based si= gnature mechanism since they are not 1:1 compatible with what we are doing = in SASL. So, we can ignore them. In addition, the PK-based signature mechan= ism has the problem that it does not provide a story for how the client dyn= amically obtains the public / private key. In a nutshell it is undeployable= . =0A>=0A>Depending on the timeline you have in mind we may either re-use t= he Bearer Token specification or wait for the current security discussions = to settle to add a more secure mechanism. There may also be no harm to defi= ne our own security mechanism for presenting the access token to the resour= ce server if we want channel binding and other security features added sinc= e those will not likely be used in the HTTPS environment due to TLS load ba= lancers. =0A>=0A>An important part from the OAuth specifications we want is= a mechanism for requesting an access token and to obtain the resource owne= rs consent prior to that step. OAuth 2.0 provides a well-written specificat= ion for that. Additionally, there is a lot of deployment available. =0A>=0A= >We may, however, indicate that we only want to support the 'Authorization = Code' grant type and not the other grant types since they are not useful in= our scenario.=A0 =0A>=0A>Ciao=0A>Hannes=0A>=0A>On Aug 11, 2012, at 7:53 PM= , Hannes Tschofenig wrote:=0A>=0A>> I would not worry about OAuth 1.0 since= the functionality we want in SASL OAuth is much better supported by OAuth = 2.0.=0A>> =0A>> On Aug 11, 2012, at 7:15 PM, William Mills wrote:=0A>> =0A>= >> Early on there was resistance from folks to mentioning OAuth 1.0a becaus= e "there's no point, OAuth 1.0a is dead".=A0 I can add the text back in eas= ily.=A0 Given the arguments about reviving the MAC draft in the OAuth WG I = could change the MAC examples out to OAuth 1.0a so this draft relies on a f= inalized spec instead. =0A>>> =0A>>> Do people like that?=A0 Hate it?=0A>>>= =0A>>> =0A>>> From: Simon Josefsson =0A>>> To: Willia= m Mills =0A>>> Cc: "Cantor, Scott" ; "kitten@ietf.org" =0A>>> Sent: Saturday, August 11, 20= 12 12:43 AM=0A>>> Subject: Re: OAUTH SASL and Channel binding=0A>>> =0A>>> = Which brings up another question: Is the SASL mechanism intended to=0A>>> a= pply to both OAuth 2.0 and OAuth 1.0?=A0 If that is the intention, I=0A>>> = think this should be clear from the introduction and throughout the=0A>>> d= ocument.=A0 This poses some challenges though, since the OAuth 1.x and=0A>>= > OAuth 2.x terminology and semantics differs somewhat.=0A>>> =0A>>> I'm wo= rking on an implementation, and I've gone back and forth between=0A>>> usin= g libraries for OAuth 1.x and Oauth 2.x.=0A>>> =0A>>> /Simon=0A>>> =0A>>> W= illiam Mills writes:=0A>>> =0A>>>> You could have an= integrity guarantee for a signed profile like MAC or OAuth 1.0a.=0A>>>> = =0A>>>> =0A>>>> =0A>>>> =0A>>>> =0A>>>>> ________________________________= =0A>>>>> From: "Cantor, Scott" =0A>>>>> To: William Mills= ; "kitten@ietf.org" =0A>>>>> Sent:= Friday, August 10, 2012 11:39 AM=0A>>>>> Subject: Re: [kitten] OAUTH SASL = and Channel binding=0A>>>>> =0A>>>>> On 8/10/12 2:36 PM, "William Mills" wrote:=0A>>>>> =0A>>>>>> Given Simon's recent comments= about the fundamental flaw in the idea of=0A>>>>>> channel binding when yo= u don't have an integrity guarantee,, as in the=0A>>>>>> Bearer token use c= ase, should channel binding remain in the OAuth SASL=0A>>>>>> profile?=0A>>= >>> =0A>>>>> If you can never have an integrity guarantee, probably not, bu= t I wouldn't=0A>>>>> personally use such a mechanism in any case, so probab= ly moot.=0A>>>>> =0A>>>>> -- Scott=0A>>>>> =0A>>>>> =0A>>>>> =0A>>>>> =0A>>= >> _______________________________________________=0A>>>> Kitten mailing li= st=0A>>>> Kitten@ietf.org=0A>>>> https://www.ietf.org/mailman/listinfo/kitt= en=0A>>> =0A>>> =0A>>> _______________________________________________=0A>>= > Kitten mailing list=0A>>> Kitten@ietf.org=0A>>> https://www.ietf.org/mail= man/listinfo/kitten=0A>> =0A>=0A>=0A>=0A> ---551393103-1548814758-1344706384=:36422 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
We fundamentally = disagree on a number of things here.  As a practical matter we need to= support the password grant. 

Please explain how MAC, or a sig= nature mechanism, is not 1:1 compatible.  To me it seems a solid fit, = it was part of the design.

I do not want to use this to define a new= way of getting tokens or PKI or define new tokens that support channel bin= ding.  This is specifically for leveraging the OAuth infrastructure wh= ich already defines much or all of this.

-bill


From: H= annes Tschofenig <hannes.tschofenig@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gm= x.net>
Cc: William = Mills <wmills@yahoo-inc.com>; Simon Josefsson <simon@josefsson.org= >; "kitten@ietf.org" <kitten@ietf.org>
Sent: Saturday, August 11, 2012 10:14 AM
= Subject: Re: [kitten] OAUTH S= ASL and Channel binding

=0AI should probably add a b= it more text.

We don't need the MAC or PK-based signature mechanism = since they are not 1:1 compatible with what we are doing in SASL. So, we ca= n ignore them. In addition, the PK-based signature mechanism has the proble= m that it does not provide a story for how the client dynamically obtains t= he public / private key. In a nutshell it is undeployable.

Dependin= g on the timeline you have in mind we may either re-use the Bearer Token sp= ecification or wait for the current security discussions to settle to add a= more secure mechanism. There may also be no harm to define our own securit= y mechanism for presenting the access token to the resource server if we wa= nt channel binding and other security features added since those will not l= ikely be used in the HTTPS environment due to TLS load balancers.

A= n important part from the OAuth specifications we want is a mechanism for r= equesting an access token and to obtain the resource owners consent prior to that step. OAuth 2.0 provides a well-writ= ten specification for that. Additionally, there is a lot of deployment avai= lable.

We may, however, indicate that we only want to support the '= Authorization Code' grant type and not the other grant types since they are= not useful in our scenario. 

Ciao
Hannes

On Aug 11,= 2012, at 7:53 PM, Hannes Tschofenig wrote:

> I would not worry a= bout OAuth 1.0 since the functionality we want in SASL OAuth is much better= supported by OAuth 2.0.
>
> On Aug 11, 2012, at 7:15 PM, Will= iam Mills wrote:
>
>> Early on there was resistance from fo= lks to mentioning OAuth 1.0a because "there's no point, OAuth 1.0a is dead"= .  I can add the text back in easily.  Given the arguments about = reviving the MAC draft in the OAuth WG I could change the MAC examples out = to OAuth 1.0a so this draft relies on a finalized spec instead.
>>
>> Do people like that?  Hate it?
>> =
>>
>> From: Simon Josefsson <simon@josefsson.org<= /a>>
>> To: William Mills <wmills@yahoo-inc.com>=
>> Cc: "Cantor, Scott" <cantor.2@osu.edu>; "kitten@ietf.org" <kitten@ietf.org>
>> Sent: Saturday, August 11, 2012 12:4= 3 AM
>> Subject: Re: OAUTH SASL and Channel binding
>> >> Which brings up another question: Is the SASL mechanism intended= to
>> apply to both OAuth 2.0 and OAuth 1.0?  If that is the= intention, I
>> think this should be clear from the introduction and through= out the
>> document.  This poses some challenges though, sinc= e the OAuth 1.x and
>> OAuth 2.x terminology and semantics differs= somewhat.
>>
>> I'm working on an implementation, and I= 've gone back and forth between
>> using libraries for OAuth 1.x a= nd Oauth 2.x.
>>
>> /Simon
>>
>> Will= iam Mills <wmills@yahoo-inc.com> writes:
>>
>= ;>> You could have an integrity guarantee for a signed profile like M= AC or OAuth 1.0a.
>>>
>>>
>>>
>= ;>>
>>>
>>>> ___________________________= _____
>>>> From: "Cantor, Scott" <cantor.2@osu.edu>
>>>&= gt; To: William Mills <wmills@yahoo-inc.com>; "kitten@ietf.org= " <kitten@ietf.org>
>>>> Sent: Friday, August 10, = 2012 11:39 AM
>>>> Subject: Re: [kitten] OAUTH SASL and Chan= nel binding
>>>>
>>>> On 8/10/12 2:36 PM, "W= illiam Mills" <wmills@yahoo-inc.com> wrote:
>>>&= gt;
>>>>> Given Simon's recent comments about the fundam= ental flaw in the idea of
>>>>> channel binding when you = don't have an integrity guarantee,, as in the
>>>>> Beare= r token use case, should channel binding remain in the OAuth SASL
>>>>&= gt; profile?
>>>>
>>>> If you can never have= an integrity guarantee, probably not, but I wouldn't
>>>> p= ersonally use such a mechanism in any case, so probably moot.
>>&g= t;>
>>>> -- Scott
>>>>
>>>&g= t;
>>>>
>>>>
>>> _____________= __________________________________
>>> Kitten mailing list
&= gt;>> Kitten@ietf.org
>>> https://www.ietf.org/mailman/lis= tinfo/kitten
>>
>>
>> ____________________= ___________________________
>> Kitten mailing list
>> Kitten@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/kitten
>



---551393103-1548814758-1344706384=:36422-- From wmills@yahoo-inc.com Sat Aug 11 18:01:17 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409FD21F84F6 for ; Sat, 11 Aug 2012 18:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.544 X-Spam-Level: X-Spam-Status: No, score=-17.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H55D-1OROfaE for ; Sat, 11 Aug 2012 18:01:16 -0700 (PDT) Received: from nm16-vm3.bullet.mail.ne1.yahoo.com (nm16-vm3.bullet.mail.ne1.yahoo.com [98.138.91.146]) by ietfa.amsl.com (Postfix) with ESMTP id 42E2521F84F2 for ; Sat, 11 Aug 2012 18:01:16 -0700 (PDT) Received: from [98.138.90.57] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 12 Aug 2012 01:01:11 -0000 Received: from [98.138.89.198] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 12 Aug 2012 01:01:11 -0000 Received: from [127.0.0.1] by omp1056.mail.ne1.yahoo.com with NNFMP; 12 Aug 2012 01:01:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 415509.64416.bm@omp1056.mail.ne1.yahoo.com Received: (qmail 97827 invoked by uid 60001); 12 Aug 2012 01:01:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344733270; bh=B3s/ioRgBefISnNctBBmUDHEedlsiIxobCSkPA0kpjI=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rYAIIjaD/JKugu+5oByKPnXwqxw1KIB4Uw2RtaqoAzB0bkU+8+Phpd6NO88Qc8fXZCBkV/tGv/Und21S6W34UxrFDr/R6bIGS3xPoCaL16vYxwK/YnoclupoCmSol4PHHz7e+2W0DNHe27+nV02ABZnL2uB3YioBsS6YbWtON3I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iYBIStH053Xy7X3fAFAltl0sgxOGNWEmc6G/bUQvAcXL2QsoZ9pu5yBO69tnkRdq6/OoDOs9weMZSrJSX1QSGPdU5/Fwy8CzUyHfoRegKfQ/m5lUdSaQUm6nKuEK7PHjmSKtw91+4lijMROduzD8f/twD4tNuT7tL1lCAuwd0mM=; X-YMail-OSG: 7iNhVp8VM1mfI3c1qxal1ND.5hWQFGUQBqngn_ZvKprfc7k tp_cXWLZlh8alAjqIuX.aiyIuYyI9BeSz3yRUl980TuWp6.e10HyR497BsIW sDeMmCfqceGTWmSJWilfRwbUDEn89mIymnn9YgyqdV2jhF8ZnPlCJzLuiLna .ARVxT93LUqbExbbKw8LFizUQEQkoT1tbLmAOr6ihQgybhB9d9465S4tL61N nc.ZOT9cGJfEty_GnnumKFpEDYdRmfdeWMDWGaKj8GdvnnTCKwZPH9tnEbNL GqI1Tw1SjcoTCBjUbA4rpLmBgN.S367Pw_hz4OjppAkZlxq0deMe5apTt8pY FR1KfJkGRVuPm9GXtxpRHVVDuZXwG6FF88nJ5_2oSO3kZGgShLHix2toE4fZ 6.XQCslIAdQ4C_LxTtyUfpbF5J_AOJ5sz1PyBlyTj_V_eqdXjElxx.OjxXLU yKWrYn2k- Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Sat, 11 Aug 2012 18:01:10 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: Message-ID: <1344733270.87399.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Sat, 11 Aug 2012 18:01:10 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-1786910289-1344733270=:87399" Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 01:01:17 -0000 ---125733401-1786910289-1344733270=:87399 Content-Type: text/plain; charset=us-ascii I think we can make channel binding better, how about language something like "A server offering channel binding (OAUTH-PLUS) MUST only accept authorization profiles that include signing and can provide message integrity for the channel binding data, and specifically MUST NOT offer the Bearer or other profile with similar security properties." >________________________________ > From: "Cantor, Scott" >To: Nico Williams >Cc: "kitten@ietf.org" >Sent: Friday, August 10, 2012 12:50 PM >Subject: Re: [kitten] OAUTH SASL and Channel binding > >On 8/10/12 3:38 PM, "Nico Williams" wrote: >> >>Oh, good point, but, of course, that requires changes to the HTTP/TLS >>stack plumbing (since you want the client to not bother validating the >>server cert the normal way on account of the bearer token mechanism >>being about to do so via its interactions with the IdP). > >Yes, that's true. There are extant examples of that, and not just in C, >but less so as you get more scripty. > >Anyway, not trying to go off topic. My opinion as an observer is that it >would be nice if the MAC or whatever non-bearer approaches within OAuth >could be used with channel binding even if it's not possible in the bearer >case. If it actually is. The SAML EC bearer case still supports channel >binding but that's because you can sign requests and responses and still >be using bearer tokens. > >-- Scott > >_______________________________________________ >Kitten mailing list >Kitten@ietf.org >https://www.ietf.org/mailman/listinfo/kitten > > > ---125733401-1786910289-1344733270=:87399 Content-Type: text/html; charset=us-ascii
I think we can make channel binding better, how about language something like "A server offering channel binding (OAUTH-PLUS) MUST only accept authorization profiles that include signing and can provide message integrity for the channel binding data, and specifically MUST NOT offer the Bearer or other profile with similar security properties."


From: "Cantor, Scott" <cantor.2@osu.edu>
To: Nico Williams <nico@cryptonector.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Friday, August 10, 2012 12:50 PM
Subject: Re: [kitten] OAUTH SASL and Channel binding

On 8/10/12 3:38 PM, "Nico Williams" <nico@cryptonector.com> wrote:
>
>Oh, good point, but, of course, that requires changes to the HTTP/TLS
>stack plumbing (since you want the client to not bother validating the
>server cert the normal way on account of the bearer token mechanism
>being about to do so via its interactions with the IdP).

Yes, that's true. There are extant examples of that, and not just in C,
but less so as you get more scripty.

Anyway, not trying to go off topic. My opinion as an observer is that it
would be nice if the MAC or whatever non-bearer approaches within OAuth
could be used with channel binding even if it's not possible in the bearer
case. If it actually is. The SAML EC bearer case still supports channel
binding but that's because you can sign requests and responses and still
be using bearer tokens.

-- Scott

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten


---125733401-1786910289-1344733270=:87399-- From hannes.tschofenig@nsn.com Sun Aug 12 10:12:23 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1292C21F8610 for ; Sun, 12 Aug 2012 10:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.956 X-Spam-Level: X-Spam-Status: No, score=-105.956 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhGo9GOSBjNi for ; Sun, 12 Aug 2012 10:12:18 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id CAD4021F8604 for ; Sun, 12 Aug 2012 10:12:17 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7CHCGZp030441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 12 Aug 2012 19:12:16 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7CHCFg9029663; Sun, 12 Aug 2012 19:12:15 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 12 Aug 2012 19:10:48 +0200 Received: from 10.144.248.87 ([10.144.248.87]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Sun, 12 Aug 2012 17:10:47 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Sun, 12 Aug 2012 20:10:46 +0300 From: Hannes Tschofenig To: "William (Bill) Mills" , Hannes Tschofenig Message-ID: Thread-Topic: [kitten] OAUTH SASL and Channel binding Thread-Index: Ac14rWma6nOY1lmSA0+7zdpPMUMdTw== In-Reply-To: <1344706384.36422.YahooMailNeo@web31805.mail.mud.yahoo.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3427647046_22624925" X-OriginalArrivalTime: 12 Aug 2012 17:10:48.0417 (UTC) FILETIME=[6B0AFD10:01CD78AD] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 24647 X-purgate-ID: 151667::1344791536-00006F5F-6585F630/0-0/0-0 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 17:12:23 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3427647046_22624925 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Bill,=20 Thanks for the quick feedback. I think you care about providing good security support for the SASL OAuth specification as much as I do. Of course we also want to take the existing deployment into consideration as well. These two aspects often do not line up nicely (as I can tell you from my past experience in the identity management field).=20 So, how do we get there? In order to use Oauth 1.0 you have to do several things to avoid security disaster:=20 1. Avoid using the plaintext signature type without TLS. The IESG required this in the published RFC but the deployment reality may look different. 2. Use TLS when obtaining a the MAC shared key for usage with the MAC "authentication". The description of TLS for the client-to-authorization server interaction is actually quite fuzzy since the main motivation for TL= S support in Oauth was to support client deployments that don't want to support TLS (for performance reasons =8Bsee my recent mail to the Oauth mailing list with a pointer to an old slide set). 3. Avoid using PK-based authentication from Oauth 1.0 since it's descriptio= n is incomplete. This essentially means that you are down to 1. using TLS with the authorization server and 2. either using the equivalent of bearer tokens (which is the plaintext variant on top of TLS) or MAC tokens. The MAC token variant allows us to skip TLS (with loss of confidentiality protection of course; we also loose the ability to protect the entire message exchange and authentication of the server) but then for the use cas= e you worry about TLS will have to be supported also for subsequent data exchanges - accessing your emails using TLS is quite common these days. I guess you may agree. Ideally, we therefore want to have application layer security in addition t= o TLS in order to provide the proper protection. The channel binding discussion very much relates to aspect. How many Oauth 1.0 deployments are actually fulfilling these requirements out of the box? Not that many, I would say. Then, you also seem to demand the support for WebFinger. Let's assume you want to have something better than Bearer Tokens. So, what should we do? There are three choices: 1. Focus on Oauth 1.0 only (since it has a MAC specification in there). Then, you ignore all the Oauth 2.0 deployment that is out there, of which there is a lot. That would be pretty bad IMHO. 2. Copy relevant parts from http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 (of which there is almost no deployment). 3. Wait for the Oauth group to settle on a mechanism. May take time. A difficult decision. Which one do you pick? On the "grant type" issue. The "Resource Owner Password Credentials" grant type essentially requires the client to have the user's long-term username and password (at least for obtaining the access token). In some sense this is actually the use case that many wanted to avoid when using Oauth. Since you are as concerned about security as myself I am wondering whether this i= s OK for you? I think it is pretty bad. In addition to the "Resource Owner Password Credentials" grant type there are these other grant types: * the client credentials grant type? * the implict grant type? Would you also like to support them? Ciao Hannes PS: You may have noticed that the Oauth 1.0 security terminology is a bit messed up. I am not sure whether we can avoid carrying it over to the Oauth SASL specification. For example, the term "signature" is not correct if we are talking about a MAC. The correct term would be (keyed) message digest. The MAC algorithm, as defined in , RFC 5849, actually doesn't provide authentication. It provides key confirmation, i.e. It shows that the client had previously obtained a key from the authorization server but it does not tell who the client is. On 8/11/12 8:33 PM, "William (Bill) Mills" wrote: > We fundamentally disagree on a number of things here. As a practical mat= ter > we need to support the password grant. >=20 > Please explain how MAC, or a signature mechanism, is not 1:1 compatible. = To > me it seems a solid fit, it was part of the design. >=20 > I do not want to use this to define a new way of getting tokens or PKI or > define new tokens that support channel binding. This is specifically for > leveraging the OAuth infrastructure which already defines much or all of = this. >=20 > -bill >=20 >=20 >> =20 >> =20 >> =20 >> =20 >>=20 >> From: Hannes Tschofenig >> To: Hannes Tschofenig >> Cc: William Mills ; Simon Josefsson >> ; "kitten@ietf.org" >> Sent: Saturday, August 11, 2012 10:14 AM >> Subject: Re: [kitten] OAUTH SASL and Channel binding >> =20 >> =20 >> I should probably add a bit more text. >>=20 >> We don't need the MAC or PK-based signature mechanism since they are not= 1:1 >> compatible with what we are doing in SASL. So, we can ignore them. In >> addition, the PK-based signature mechanism has the problem that it does = not >> provide a story for how the client dynamically obtains the public / priv= ate >> key. In a nutshell it is undeployable. >>=20 >> Depending on the timeline you have in mind we may either re-use the Bear= er >> Token specification or wait for the current security discussions to sett= le to >> add a more secure mechanism. There may also be no harm to define our own >> security mechanism for presenting the access token to the resource serve= r if >> we want channel binding and other security features added since those wi= ll >> not likely be used in the HTTPS environment due to TLS load balancers. >>=20 >> An important part from the OAuth specifications we want is a mechanism f= or >> requesting an access token and to obtain the resource owners consent pri= or to >> that step. OAuth 2.0 provides a well-written specification for that. >> Additionally, there is a lot of deployment available. >>=20 >> We may, however, indicate that we only want to support the 'Authorizatio= n >> Code' grant type and not the other grant types since they are not useful= in >> our scenario. =20 >>=20 >> Ciao >> Hannes >>=20 >> On Aug 11, 2012, at 7:53 PM, Hannes Tschofenig wrote: >>=20 >>> > I would not worry about OAuth 1.0 since the functionality we want in = SASL >>> OAuth is much better supported by OAuth 2.0. >>> >=20 >>> > On Aug 11, 2012, at 7:15 PM, William Mills wrote: >>> >=20 >>>> >> Early on there was resistance from folks to mentioning OAuth 1.0a >>>> because "there's no point, OAuth 1.0a is dead". I can add the text ba= ck in >>>> easily. Given the arguments about reviving the MAC draft in the OAuth= WG I >>>> could change the MAC examples out to OAuth 1.0a so this draft relies o= n a >>>> finalized spec instead. >>>> >>=20 >>>> >> Do people like that? Hate it? >>>> >>=20 >>>> >>=20 >>>> >> From: Simon Josefsson >>>> >> To: William Mills >>>> >> Cc: "Cantor, Scott" ; "kitten@ietf.org" >>>> >>>> >> Sent: Saturday, August 11, 2012 12:43 AM >>>> >> Subject: Re: OAUTH SASL and Channel binding >>>> >>=20 >>>> >> Which brings up another question: Is the SASL mechanism intended to >>>> >> apply to both OAuth 2.0 and OAuth 1.0? If that is the intention, I >>>> >> think this should be clear from the introduction and throughout the >>>> >> document. This poses some challenges though, since the OAuth 1.x a= nd >>>> >> OAuth 2.x terminology and semantics differs somewhat. >>>> >>=20 >>>> >> I'm working on an implementation, and I've gone back and forth betw= een >>>> >> using libraries for OAuth 1.x and Oauth 2.x. >>>> >>=20 >>>> >> /Simon >>>> >>=20 >>>> >> William Mills writes: >>>> >>=20 >>>>> >>> You could have an integrity guarantee for a signed profile like M= AC or >>>>> OAuth 1.0a. >>>>> >>>=20 >>>>> >>>=20 >>>>> >>>=20 >>>>> >>>=20 >>>>> >>>=20 >>>>>> >>>> ________________________________ >>>>>> >>>> From: "Cantor, Scott" >>>>>> >>>> To: William Mills ; "kitten@ietf.org" >>>>>> >>>>>> >>>> Sent: Friday, August 10, 2012 11:39 AM >>>>>> >>>> Subject: Re: [kitten] OAUTH SASL and Channel binding >>>>>> >>>>=20 >>>>>> >>>> On 8/10/12 2:36 PM, "William Mills" wrot= e: >>>>>> >>>>=20 >>>>>>> >>>>> Given Simon's recent comments about the fundamental flaw in t= he >>>>>>> idea of >>>>>>> >>>>> channel binding when you don't have an integrity guarantee,, = as in the >>>>>>> >>>>> Bearer token use case, should channel binding remain in the O= Auth SASL >>>>>>> >>>>> profile? >>>>>> >>>>=20 >>>>>> >>>> If you can never have an integrity guarantee, probably not, but= I >>>>>> wouldn't >>>>>> >>>> personally use such a mechanism in any case, so probably moot. >>>>>> >>>>=20 >>>>>> >>>> -- Scott >>>>>> >>>>=20 >>>>>> >>>>=20 >>>>>> >>>>=20 >>>>>> >>>>=20 >>>>> >>> _______________________________________________ >>>>> >>> Kitten mailing list >>>>> >>> Kitten@ietf.org >>>>> >>> https://www.ietf.org/mailman/listinfo/kitten >>>> >>=20 >>>> >>=20 >>>> >> _______________________________________________ >>>> >> Kitten mailing list >>>> >> Kitten@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/kitten >>> >=20 >>=20 >>=20 >>=20 >> =20 >> =20 >> =20 > =20 >=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --B_3427647046_22624925 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [kitten] OAUTH SASL and Channel binding Hi Bill,

Thanks for the quick feedback.

I think you care about providing good security support for the SASL OAuth s= pecification as much as I do. Of course we also want to take the existing de= ployment into consideration as well. These two aspects often do not line up = nicely (as I can tell you from my past experience in the identity management= field).

So, how do we get there?

In order to use Oauth 1.0 you have to do several things to avoid security d= isaster:

  1. Avoid using the plaintext signature type without TLS= . The IESG required this in the published RFC but the deployment reality may= look different.  
  2. Use TLS when obtaining a the MAC shared key for usage wi= th the MAC "authentication". The description of TLS for the client= -to-authorization server interaction is actually quite fuzzy since the main = motivation for TLS support in Oauth was to support client deployments that d= on't want to support TLS (for performance reasons —see my recent mail = to the Oauth mailing list with a pointer to an old slide set).=20
  3. Avoid using PK-based authentication from Oauth 1.0 since= it's description is incomplete.

This essentially means that you are down to
  1. using TLS with the authorization server and
  2. either using the equivalent of bearer tokens (which is t= he plaintext variant on top of TLS) or MAC tokens.

The MAC token variant allows us to skip TLS (with loss of confidentiality p= rotection of course; we also loose the ability to protect the entire message= exchange and authentication of the server) but then for the use case you wo= rry about TLS will have to be supported also for subsequent data exchanges -= accessing your emails using TLS is quite common these days. I guess you may= agree.

Ideally, we therefore want to have application layer security in addition t= o TLS in order to provide the proper protection. The channel binding discuss= ion very much relates to aspect.

How many Oauth 1.0 deployments are actually fulfilling these requirements o= ut of the box? Not that many, I would say. Then, you also seem to demand the= support for WebFinger.

Let's assume you want to have something better than Bearer Tokens. So, what= should we do? There are three choices:

  1. Focus on Oauth 1.0 only (since it has a MAC specific= ation in there). Then, you ignore all the Oauth 2.0 deployment that is out t= here, of which there is a lot. That would be pretty bad IMHO.
  2. Copy relevant parts from http://tools.ietf.org/html/draft-ietf-= oauth-v2-http-mac-01 (of which there is almost no deployment).
  3. Wait for the Oauth group to settle on a mechanism. May t= ake time.

A difficult decision.

Which one do you pick?

On the "grant type" issue. The "Resource Owner Password Cred= entials" grant type essentially requires the client to have the user's = long-term username and password (at least for obtaining the access token). I= n some sense this is actually the use case that many wanted to avoid when us= ing Oauth. Since you are as concerned about security as myself I am wonderin= g whether this is OK for you? I think it is pretty bad.

In addition to the "Resource Owner Password Credentials" grant ty= pe there are these other grant types:
  • the client credentials grant type?=20
  • the implict grant type?

Would you also like to support them?

Ciao
Hannes

PS: You may have noticed that the Oauth 1.0 security terminology is a bit m= essed up. I am not sure whether we can avoid carrying it over to the Oauth S= ASL specification. For example, the term "signature" is not correc= t if we are talking about a MAC. The correct term would be (keyed) message d= igest. The MAC algorithm, as defined in , RFC 5849, actually doesn't provide= authentication. It provides key confirmation, i.e. It shows that the client= had previously obtained a key from the authorization server but it does not= tell who the client is.  


On 8/11/12 8:33 PM, "William (Bill) Mills" <wmills@yahoo-inc.com> wrote:

We fundamentally disagree on a number of things here. &n= bsp;As a practical matter we need to support the password grant.  

Please explain how MAC, or a signature mechanism, is not 1:1 compatible. &n= bsp;To me it seems a solid fit, it was part of the design.

I do not want to use this to define a new way of getting tokens or PKI or d= efine new tokens that support channel binding.  This is specifically fo= r leveraging the OAuth infrastructure which already defines much or all of t= his.

-bill


 
 
 
 From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
 To: Hannes Tschofenig <= hannes.tschofenig@gmx.net>
Cc: William Mills <wmills@yahoo-in= c.com>; Simon Josefsson <simon@josef= sson.org>; "kitten@ietf.org" = <kitten@ietf.org>
 Sent: Saturday, August 11, 2012 10:14 AM
 Subject: Re: [kitten] OAUTH SASL and Channel binding
 
 
I should probably add a bit more text.

We don't need the MAC or PK-based signature mechanism since they are not 1:= 1 compatible with what we are doing in SASL. So, we can ignore them. In addi= tion, the PK-based signature mechanism has the problem that it does not prov= ide a story for how the client dynamically obtains the public / private key.= In a nutshell it is undeployable.

Depending on the timeline you have in mind we may either re-use the Bearer = Token specification or wait for the current security discussions to settle t= o add a more secure mechanism. There may also be no harm to define our own s= ecurity mechanism for presenting the access token to the resource server if = we want channel binding and other security features added since those will n= ot likely be used in the HTTPS environment due to TLS load balancers.

An important part from the OAuth specifications we want is a mechanism for = requesting an access token and to obtain the resource owners consent prior t= o that step. OAuth 2.0 provides a well-written specification for that. Addit= ionally, there is a lot of deployment available.

We may, however, indicate that we only want to support the 'Authorization C= ode' grant type and not the other grant types since they are not useful in o= ur scenario.  

Ciao
Hannes

On Aug 11, 2012, at 7:53 PM, Hannes Tschofenig wrote:

> I would not worry about OAuth 1.0 since the functionality we want in S= ASL OAuth is much better supported by OAuth 2.0.
>
> On Aug 11, 2012, at 7:15 PM, William Mills wrote:
>
>> Early on there was resistance from folks to mentioning OAuth 1.0a = because "there's no point, OAuth 1.0a is dead".  I can add th= e text back in easily.  Given the arguments about reviving the MAC draf= t in the OAuth WG I could change the MAC examples out to OAuth 1.0a so this = draft relies on a finalized spec instead.
>>
>> Do people like that?  Hate it?
>>
>>
>> From: Simon Josefsson <simon@jose= fsson.org>
>> To: William Mills <wmills@yahoo-= inc.com>
>> Cc: "Cantor, Scott" <canto= r.2@osu.edu>; "kitten@ietf.org&quo= t; <kitten@ietf.org>
>> Sent: Saturday, August 11, 2012 12:43 AM
>> Subject: Re: OAUTH SASL and Channel binding
>>
>> Which brings up another question: Is the SASL mechanism intended t= o
>> apply to both OAuth 2.0 and OAuth 1.0?  If that is the intent= ion, I
>> think this should be clear from the introduction and throughout th= e
>> document.  This poses some challenges though, since the OAuth= 1.x and
>> OAuth 2.x terminology and semantics differs somewhat.
>>
>> I'm working on an implementation, and I've gone back and forth bet= ween
>> using libraries for OAuth 1.x and Oauth 2.x.
>>
>> /Simon
>>
>> William Mills <wmills@yahoo-inc.= com> writes:
>>
>>> You could have an integrity guarantee for a signed profile lik= e MAC or OAuth 1.0a.
>>>
>>>
>>>
>>>
>>>
>>>> ________________________________
>>>> From: "Cantor, Scott" <cantor.2@osu.edu>
>>>> To: William Mills <wmill= s@yahoo-inc.com>; "kitten@ietf.org= " <kitten@ietf.org>
>>>> Sent: Friday, August 10, 2012 11:39 AM
>>>> Subject: Re: [kitten] OAUTH SASL and Channel binding
>>>>
>>>> On 8/10/12 2:36 PM, "William Mills" <wmills@yahoo-inc.com> wrote:
>>>>
>>>>> Given Simon's recent comments about the fundamental fl= aw in the idea of
>>>>> channel binding when you don't have an integrity guara= ntee,, as in the
>>>>> Bearer token use case, should channel binding remain i= n the OAuth SASL
>>>>> profile?
>>>>
>>>> If you can never have an integrity guarantee, probably not= , but I wouldn't
>>>> personally use such a mechanism in any case, so probably m= oot.
>>>>
>>>> -- Scott
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Kitten mailing list
>>> Kitten@ietf.org
>>> https:/= /www.ietf.org/mailman/listinfo/kitten
>>
>>
>> _______________________________________________
>> Kitten mailing list
>> Kitten@ietf.org
>> https://www= .ietf.org/mailman/listinfo/kitten
>



 
 
<= SPAN STYLE=3D'font-size:14pt'>   

___________= ____________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org= /mailman/listinfo/kitten
--B_3427647046_22624925-- From wmills@yahoo-inc.com Sun Aug 12 20:31:23 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E615A21F85D6 for ; Sun, 12 Aug 2012 20:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.511 X-Spam-Level: X-Spam-Status: No, score=-17.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiePxq0he1N0 for ; Sun, 12 Aug 2012 20:31:22 -0700 (PDT) Received: from nm5.bullet.mail.sp2.yahoo.com (nm5.bullet.mail.sp2.yahoo.com [98.139.91.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3B521F85D1 for ; Sun, 12 Aug 2012 20:31:18 -0700 (PDT) Received: from [72.30.22.78] by nm5.bullet.mail.sp2.yahoo.com with NNFMP; 13 Aug 2012 03:31:12 -0000 Received: from [98.139.91.17] by tm12.bullet.mail.sp2.yahoo.com with NNFMP; 13 Aug 2012 03:31:12 -0000 Received: from [127.0.0.1] by omp1017.mail.sp2.yahoo.com with NNFMP; 13 Aug 2012 03:31:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 600151.20104.bm@omp1017.mail.sp2.yahoo.com Received: (qmail 32994 invoked by uid 60001); 13 Aug 2012 03:31:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344828671; bh=zv83x8gqf+TyR/hyAtiFj/EFLiJuBUE7Ksujoi0zzUA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YXJ9RfIUpxQXj2WJxFofTDsMqrsgBX0H97WVlbQAQrr4F+7hxsA/Osmi9JsyIgza5d0vy4r1naNEw97R4/YeTNM4zuO0lrHwOhOO2FpIZ1U6rtRIk0pYV1oeSxfXp1s2OQjEr90yuTzRqzGvsx1CyXzqnxcnegGsIZe3laeB1ks= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Zpd/tn+FDOKzhGz2mH72vrnRlzcx2WnWqv7o8mw/WRQkcbVqvn2QSzIeTsFoaYvM7voS6n+JM4N2ovmneLnAPEYb6QofN5UpStmvZW0MDHW85EPzK7o8Pxg99cfysKljKpqh7JMoCyhCylnfD7yWoXNdSTDaTlt3rWz88MtAdXA=; X-YMail-OSG: BYgblnkVM1kMQ0dXYfrvdCzmjHYZOTok6FuWCHu_9MImkqu FY.pXfU6kjpcthmvojHZlZrAcvHjdcIrdscWU_XBjrjHbQ.mvxVymhCArAeT TbGevsDOadWu9J.VUmN63o_GEeVKqlFS54b0y.L6r5Ztjl.O71jFAMsFTngK bXw8eCZ2XE05.FNGrz__W_zQ4DRG5nM33TCluK.EDPnnzFZGzmeopmtugBVi 8nSU854wRO9mvoBu0Ltx8_OCaUK_Gu8tvkrjBdY7xR567W1IGjn1EY6_8U11 oErczJT_J.N2RuC6cSiCMZ9XIQWkkXpjp2uSQBnYjhGlpCYwDTB5tYcooH4s _.szL9S.qBpwYQYw51fELuV8o_Zgt.vPcwz6xbZV2TNn7H.Tw2HbmjylHrJP ncXowjyQNQLFKGS0zRQg5g_aVOn4wR1lj5OnzY8LNMUc- Received: from [99.31.212.42] by web31810.mail.mud.yahoo.com via HTTP; Sun, 12 Aug 2012 20:31:11 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1344706384.36422.YahooMailNeo@web31805.mail.mud.yahoo.com> Message-ID: <1344828671.93823.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Sun, 12 Aug 2012 20:31:11 -0700 (PDT) From: William Mills To: Hannes Tschofenig , Hannes Tschofenig In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1935884094-1797151612-1344828671=:93823" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 03:31:24 -0000 --1935884094-1797151612-1344828671=:93823 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable For a complete solution for clients what I demand is auth endpoint discover= y for standalone cleints.=C2=A0 Webfinger/SWD seems to solve my problem, it= 's functional and I can work with it.=C2=A0 I really *DO NOT CARE* how this= problem gets solved, but it must be solved. =0A=0A=0ASeveral more things:= =0A=0A-=C2=A0=C2=A0=C2=A0 OAuth 1.0a style credentials solve some problems = for me because we have extant integrations that could use SASL/OAUTH profil= e immediately.=0A-=C2=A0=C2=A0=C2=A0 I don't want to solve OAuth 1.0a's pro= blems in this draft.=0A=0A-=C2=A0=C2=A0=C2=A0 I don't want to wait for MAC = since it's now apparently going back to committee to be completely re-evalu= ated.=0A=0AI'm willing to accept that we're going to have a number of compr= omises here.=C2=A0 Bearer tokens are only slightly better than cookies (bec= ause the browser as a confused deputy is sort of fixed).=C2=A0 OAuth 1.0a w= ith plaintext (it is to laugh) secrets are similarly bad.=C2=A0 =0A=0A=0AI = take it as fact that we will have additional signed OAuth 2 profiles, and s= o I want to provide examples for this type of profile.=C2=A0 I am not willi= ng to make this incompatible with 1.0a or write it out of the spec as not a= llowed. =0A=0A=0AIn fact, while we shoudl make sure the draft isn't fundame= ntally broken, Like having channel binding wit bearer tokens whihc is usele= ss, my intent is to punt all of the security considerations for using 1.0a = or Bearer or JWT et al back ot those specs.=0A=0A-bill=0A=0A=0A=0A=0A=0A=0A= >________________________________=0A> From: Hannes Tschofenig =0A>To: William (Bill) Mills ; Hannes T= schofenig =0A>Cc: "kitten@ietf.org" ; Simon Josefsson =0A>Sent: Sunday, August 12, = 2012 10:10 AM=0A>Subject: Re: [kitten] OAUTH SASL and Channel binding=0A> = =0A>=0A>Re: [kitten] OAUTH SASL and Channel binding =0A>Hi Bill, =0A>=0A>Th= anks for the quick feedback.=0A>=0A>I think you care about providing good s= ecurity support for the SASL OAuth specification as much as I do. Of course= we also want to take the existing deployment into consideration as well. T= hese two aspects often do not line up nicely (as I can tell you from my pas= t experience in the identity management field). =0A>=0A>So, how do we get t= here? =0A>=0A>In order to use Oauth 1.0 you have to do several things to av= oid security disaster: =0A>=0A>=0A>=091. Avoid using the plaintext signatur= e type without TLS. The IESG required this in the published RFC but the dep= loyment reality may look different. =C2=A0 =0A>=092. Use TLS when obtaining= a the MAC shared key for usage with the MAC "authentication". The descript= ion of TLS for the client-to-authorization server interaction is actually q= uite fuzzy since the main motivation for TLS support in Oauth was to suppor= t client deployments that don't want to support TLS (for performance reason= s =E2=80=94see my recent mail to the Oauth mailing list with a pointer to a= n old slide set). =0A>=093. Avoid using PK-based authentication from Oauth = 1.0 since it's description is incomplete.=0A>=0A>This essentially means tha= t you are down to =0A>=0A>=091. using TLS with the authorization server and= =0A>=092. either using the equivalent of bearer tokens (which is the plain= text variant on top of TLS) or MAC tokens. =0A>=0A>The MAC token variant al= lows us to skip TLS (with loss of confidentiality protection of course; we = also loose the ability to protect the entire message exchange and authentic= ation of the server) but then for the use case you worry about TLS will hav= e to be supported also for subsequent data exchanges - accessing your email= s using TLS is quite common these days. I guess you may agree. =0A>=0A>Idea= lly, we therefore want to have application layer security in addition to TL= S in order to provide the proper protection. The channel binding discussion= very much relates to aspect.=0A>=0A>How many Oauth 1.0 deployments are act= ually fulfilling these requirements out of the box? Not that many, I would = say. Then, you also seem to demand the support for WebFinger.=0A>=0A>Let's = assume you want to have something better than Bearer Tokens. So, what shoul= d we do? There are three choices:=0A>=0A>=0A>=091. Focus on Oauth 1.0 only = (since it has a MAC specification in there). Then, you ignore all the Oauth= 2.0 deployment that is out there, of which there is a lot. That would be p= retty bad IMHO. =0A>=092. Copy relevant parts from http://tools.ietf.org/ht= ml/draft-ietf-oauth-v2-http-mac-01 (of which there is almost no deployment)= . =0A>=093. Wait for the Oauth group to settle on a mechanism. May take tim= e. =0A>=0A>A difficult decision. =0A>=0A>Which one do you pick? =0A>=0A>On = the "grant type" issue. The "Resource Owner Password Credentials" grant typ= e essentially requires the client to have the user's long-term username and= password (at least for obtaining the access token). In some sense this is = actually the use case that many wanted to avoid when using Oauth. Since you= are as concerned about security as myself I am wondering whether this is O= K for you? I think it is pretty bad. =0A>=0A>In addition to the "Resource O= wner Password Credentials" grant type there are these other grant types: = =0A>=0A>=09* the client credentials grant type? =0A>=09* the implict grant = type? =0A>=0A>Would you also like to support them?=0A>=0A>Ciao=0A>Hannes=0A= >=0A>PS: You may have noticed that the Oauth 1.0 security terminology is a = bit messed up. I am not sure whether we can avoid carrying it over to the O= auth SASL specification. For example, the term "signature" is not correct i= f we are talking about a MAC. The correct term would be (keyed) message dig= est. The MAC algorithm, as defined in , RFC 5849, actually doesn't provide = authentication. It provides key confirmation, i.e. It shows that the client= had previously obtained a key from the authorization server but it does no= t tell who the client is. =C2=A0=0A>=0A>=0A>On 8/11/12 8:33 PM, "William (B= ill) Mills" wrote:=0A>=0A>=0A>We fundamentally disag= ree on a number of things here. =C2=A0As a practical matter we need to supp= ort the password grant. =C2=A0=0A>>=0A>>Please explain how MAC, or a signat= ure mechanism, is not 1:1 compatible. =C2=A0To me it seems a solid fit, it = was part of the design.=0A>>=0A>>I do not want to use this to define a new = way of getting tokens or PKI or define new tokens that support channel bind= ing. =C2=A0This is specifically for leveraging the OAuth infrastructure whi= ch already defines much or all of this.=0A>>=0A>>-bill=0A>>=0A>>=0A>>=0A>>= =C2=A0=0A>>>=C2=A0=0A>>>=0A>>>=C2=A0=0A>>>>>>______________________________= __=0A>>> =C2=A0From:Hannes Tschofenig =0A>>>=C2= =A0To: Hannes Tschofenig =0A>>>Cc: William Mill= s ; Simon Josefsson ; "kitten@ie= tf.org" =0A>>>=C2=A0Sent: Saturday, August 11, 2012 10:14= AM=0A>>>=C2=A0Subject: Re: [kitten] OAUTH SASL and Channel binding=0A>>>= =C2=A0=0A>>>=C2=A0=0A>>>I should probably add a bit more text.=0A>>>=0A>>>W= e don't need the MAC or PK-based signature mechanism since they are not 1:1= compatible with what we are doing in SASL. So, we can ignore them. In addi= tion, the PK-based signature mechanism has the problem that it does not pro= vide a story for how the client dynamically obtains the public / private ke= y. In a nutshell it is undeployable. =0A>>>=0A>>>Depending on the timeline = you have in mind we may either re-use the Bearer Token specification or wai= t for the current security discussions to settle to add a more secure mecha= nism. There may also be no harm to define our own security mechanism for pr= esenting the access token to the resource server if we want channel binding= and other security features added since those will not likely be used in t= he HTTPS environment due to TLS load balancers. =0A>>>=0A>>>An important pa= rt from the OAuth specifications we want is a mechanism for requesting an a= ccess token and to obtain the resource owners consent prior to that step. O= Auth 2.0 provides a well-written specification for that. Additionally, ther= e is a lot of deployment available. =0A>>>=0A>>>We may, however, indicate t= hat we only want to support the 'Authorization Code' grant type and not the= other grant types since they are not useful in our scenario. =C2=A0=0A>>>= =0A>>>Ciao=0A>>>Hannes=0A>>>=0A>>>On Aug 11, 2012, at 7:53 PM, Hannes Tscho= fenig wrote:=0A>>>=0A>>>> I would not worry about OAuth 1.0 since the funct= ionality we want in SASL OAuth is much better supported by OAuth 2.0.=0A>>>= > =0A>>>> On Aug 11, 2012, at 7:15 PM, William Mills wrote:=0A>>>> =0A>>>>>= Early on there was resistance from folks to mentioning OAuth 1.0a because = "there's no point, OAuth 1.0a is dead". =C2=A0I can add the text back in ea= sily. =C2=A0Given the arguments about reviving the MAC draft in the OAuth W= G I could change the MAC examples out to OAuth 1.0a so this draft relies on= a finalized spec instead. =0A>>>>> =0A>>>>> Do people like that? =C2=A0Hat= e it?=0A>>>>> =0A>>>>> =0A>>>>> From: Simon Josefsson = =0A>>>>> To: William Mills =0A>>>>> Cc: "Cantor, Sco= tt" ; "kitten@ietf.org" =0A>>>>> Sent: = Saturday, August 11, 2012 12:43 AM=0A>>>>> Subject: Re: OAUTH SASL and Chan= nel binding=0A>>>>> =0A>>>>> Which brings up another question: Is the SASL = mechanism intended to=0A>>>>> apply to both OAuth 2.0 and OAuth 1.0? =C2=A0= If that is the intention, I=0A>>>>> think this should be clear from the int= roduction and throughout the=0A>>>>> document. =C2=A0This poses some challe= nges though, since the OAuth 1.x and=0A>>>>> OAuth 2.x terminology and sema= ntics differs somewhat.=0A>>>>> =0A>>>>> I'm working on an implementation, = and I've gone back and forth between=0A>>>>> using libraries for OAuth 1.x = and Oauth 2.x.=0A>>>>> =0A>>>>> /Simon=0A>>>>> =0A>>>>> William Mills writes:=0A>>>>> =0A>>>>>> You could have an integrity gua= rantee for a signed profile like MAC or OAuth 1.0a.=0A>>>>>> =0A>>>>>> =0A>= >>>>> =0A>>>>>> =0A>>>>>> =0A>>>>>>> ________________________________=0A>>>= >>>> From: "Cantor, Scott" =0A>>>>>>> To: William Mills <= wmills@yahoo-inc.com>; "kitten@ietf.org" =0A>>>>>>> Sent:= Friday, August 10, 2012 11:39 AM=0A>>>>>>> Subject: Re: [kitten] OAUTH SAS= L and Channel binding=0A>>>>>>> =0A>>>>>>> On 8/10/12 2:36 PM, "William Mil= ls" wrote:=0A>>>>>>> =0A>>>>>>>> Given Simon's recen= t comments about the fundamental flaw in the idea of=0A>>>>>>>> channel bin= ding when you don't have an integrity guarantee,, as in the=0A>>>>>>>> Bear= er token use case, should channel binding remain in the OAuth SASL=0A>>>>>>= >> profile?=0A>>>>>>> =0A>>>>>>> If you can never have an integrity guarant= ee, probably not, but I wouldn't=0A>>>>>>> personally use such a mechanism = in any case, so probably moot.=0A>>>>>>> =0A>>>>>>> -- Scott=0A>>>>>>> =0A>= >>>>>> =0A>>>>>>> =0A>>>>>>> =0A>>>>>> ____________________________________= ___________=0A>>>>>> Kitten mailing list=0A>>>>>> Kitten@ietf.org=0A>>>>>> = https://www.ietf.org/mailman/listinfo/kitten=0A>>>>> =0A>>>>> =0A>>>>> ____= ___________________________________________=0A>>>>> Kitten mailing list=0A>= >>>> Kitten@ietf.org=0A>>>>> https://www.ietf.org/mailman/listinfo/kitten= =0A>>>> =0A>>>=0A>>>=0A>>>=0A>>>=C2=A0=0A>>>=0A>>>=C2=A0=0A>>>=C2=A0=C2=A0= =0A>>=0A>>>>________________________________=0A>>__________________________= _____________________=0A>>Kitten mailing list=0A>>Kitten@ietf.org=0A>>https= ://www.ietf.org/mailman/listinfo/kitten=0A>>=0A>=0A> --1935884094-1797151612-1344828671=:93823 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
For a complete so= lution for clients what I demand is auth endpoint discovery for standalone = cleints.  Webfinger/SWD seems to solve my problem, it's functional and= I can work with it.  I really *DO NOT CARE* how this problem gets sol= ved, but it must be solved.

Several more things:

-  &nb= sp; OAuth 1.0a style credentials solve some problems for me because = we have extant integrations that could use SASL/OAUTH profile immediately.<= /div>
-    I don't want to so= lve OAuth 1.0a's problems in this draft.
-    I don't want to wait for MAC since it's n= ow apparently going back to committee to be completely re-evaluated.=

I'm willing to accept that we're going to have a number of compr= omises here.  Bearer tokens are only slightly better than cookies (bec= ause the browser as a confused deputy is sort of fixed).  OAuth 1.0a w= ith plaintext (it is to laugh) secrets are similarly bad. 
<= div style=3D"color: rgb(0, 0, 0); font-size: 18.6667px; font-family: Courie= r New,courier,monaco,monospace,sans-serif; background-color: transparent; font-style: normal;">
I take it as fact that= we will have additional signed OAuth 2 profiles, and so I want to provide = examples for this type of profile.  I am not willing to make this inco= mpatible with 1.0a or write it out of the spec as not allowed.

In fact, while we shoudl make sure the draft isn't f= undamentally broken, Like having channel binding wit bearer tokens whihc is= useless, my intent is to punt all of the security considerations for using= 1.0a or Bearer or JWT et al back ot those specs.

-bill


From: Hannes Tschofenig <Hann= es.Tschofenig@nsn.com>
To: William (Bill) Mills <wmills@yahoo-inc.com>; Hannes Tschofeni= g <Hannes.Tschofenig@gmx.net>
Cc: "kitten@ietf.org" <kitten@ietf.org>; Simon Josefsso= n <simon@josefsson.org>
Se= nt: Sunday, August 12, 2012 10:10 AM
Subject: Re: [kitten] OAUTH SASL and Channel bind= ing

=0A
=0A=0ARe: [ki= tten] OAUTH SASL and Channel binding=0A=0A
=0AHi Bill, <= br>=0A
=0AThanks for the quick feedback.
=0A
=0AI think you care a= bout providing good security support for the SASL OAuth specification as mu= ch as I do. Of course we also want to take the existing deployment into con= sideration as well. These two aspects often do not line up nicely (as I can= tell you from my past experience in the identity management field).
= =0A
=0ASo, how do we get there?
=0A
=0AIn order to use Oauth 1.0 = you have to do several things to avoid security disaster:
=0A
=0A
  1. Avoid using the plaintext signature type without = TLS. The IESG required this in the published RFC but the deployment reality= may look different.  =0A
  2. Use TLS when ob= taining a the MAC shared key for usage with the MAC "authentication". The d= escription of TLS for the client-to-authorization server interaction is act= ually quite fuzzy since the main motivation for TLS support in Oauth was to= support client deployments that don't want to support TLS (for performance= reasons =E2=80=94see my recent mail to the Oauth mailing list with a point= er to an old slide set). =0A
  3. Avoid using PK-ba= sed authentication from Oauth 1.0 since it's description is incomplete.
    = =0A

=0AThis essentially means that you ar= e down to
=0A
  1. using TLS with the authorizat= ion server and=0A
  2. either using the equivalent = of bearer tokens (which is the plaintext variant on top of TLS) or MAC toke= ns.
    =0A

=0AThe MAC token variant allo= ws us to skip TLS (with loss of confidentiality protection of course; we al= so loose the ability to protect the entire message exchange and authenticat= ion of the server) but then for the use case you worry about TLS will have = to be supported also for subsequent data exchanges - accessing your emails = using TLS is quite common these days. I guess you may agree.
=0A
=0A= Ideally, we therefore want to have application layer security in addition t= o TLS in order to provide the proper protection. The channel binding discus= sion very much relates to aspect.
=0A
=0AHow many Oauth 1.0 deploymen= ts are actually fulfilling these requirements out of the box? Not that many= , I would say. Then, you also seem to demand the support for WebFinger.
= =0A
=0ALet's assume you want to have something better than Bearer Tokens= . So, what should we do? There are three choices:
=0A
=0A
  1. Focus on Oauth 1.0 only (since it has a MAC specification = in there). Then, you ignore all the Oauth 2.0 deployment that is out there,= of which there is a lot. That would be pretty bad IMHO.=0A
  2. Copy relevant parts from http://tools.ietf.org/html/draft-iet= f-oauth-v2-http-mac-01 (of which there is almost no deployment).=0A<= /font>
  3. Wait for the Oauth group to settle on a mechanism. Ma= y take time.
    =0A

=0AA difficult decis= ion.
=0A
=0AWhich one do you pick?
=0A
=0AOn the "grant type"= issue. The "Resource Owner Password Credentials" grant type essentially re= quires the client to have the user's long-term username and password (at le= ast for obtaining the access token). In some sense this is actually the use= case that many wanted to avoid when using Oauth. Since you are as concerne= d about security as myself I am wondering whether this is OK for you? I thi= nk it is pretty bad.
=0A
=0AIn addition to the "Resource Owner Passw= ord Credentials" grant type there are these other grant types:
=0A
  • the client credentials grant type? =0A
  • the implict grant type?
    =0A

=0AWould you also like to support them?
=0A
=0ACiao
=0AHan= nes
=0A
=0APS: You may have noticed that the Oauth 1.0 security termi= nology is a bit messed up. I am not sure whether we can avoid carrying it o= ver to the Oauth SASL specification. For example, the term "signature" is n= ot correct if we are talking about a MAC. The correct term would be (keyed)= message digest. The MAC algorithm, as defined in , RFC 5849, actually does= n't provide authentication. It provides key confirmation, i.e. It shows tha= t the client had previously obtained a key from the authorization server bu= t it does not tell who the client is.  
=0A
=0A
=0AOn 8/11/12= 8:33 PM, "William (Bill) Mills" <wmills@y= ahoo-inc.com> wrote:
=0A
=0A
We fund= amentally disagree on a number of things here.  As a practical matter = we need to support the password grant.  
=0A
=0APlease explain h= ow MAC, or a signature mechanism, is not 1:1 compatible.  To me it see= ms a solid fit, it was part of the design.
=0A
=0AI do not want to us= e this to define a new way of getting tokens or PKI or define new tokens th= at support channel binding.  This is specifically for leveraging the O= Auth infrastructure which already defines much or all of this.
=0A
= =0A-bill
=0A
=0A
=0A
 
= =0A 
=0A
=0A <= span style=3D"font-size:11pt;">
=0A
 From: Hanne= s Tschofenig <hannes.tschofenig@gmx.net>
=0A To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
=0ACc: William Mills <= ;wmills@yahoo-inc.com>; Simon Josefsso= n <simon@josefsson.org>; "kitten@ietf.org" <kitten@ietf.org>
=0A Sent: Saturday, August 11, 2= 012 10:14 AM
=0A Subject: Re: [kitten] OAUTH SASL and Channe= l binding
=0A 
=0A 
=0AI should probably add a bit mo= re text.
=0A
=0AWe don't need the MAC or PK-based signature mechanism= since they are not 1:1 compatible with what we are doing in SASL. So, we c= an ignore them. In addition, the PK-based signature mechanism has the probl= em that it does not provide a story for how the client dynamically obtains = the public / private key. In a nutshell it is undeployable.
=0A
=0AD= epending on the timeline you have in mind we may either re-use the Bearer T= oken specification or wait for the current security discussions to settle t= o add a more secure mechanism. There may also be no harm to define our own = security mechanism for presenting the access token to the resource server i= f we want channel binding and other security features added since those wil= l not likely be used in the HTTPS environment due to TLS load balancers. =0A
=0AAn important part from the OAuth specifications we want is a me= chanism for requesting an access token and to obtain the resource owners co= nsent prior to that step. OAuth 2.0 provides a well-written specification f= or that. Additionally, there is a lot of deployment available.
=0A
= =0AWe may, however, indicate that we only want to support the 'Authorizatio= n Code' grant type and not the other grant types since they are not useful = in our scenario.  
=0A
=0ACiao
=0AHannes
=0A
=0AOn Aug = 11, 2012, at 7:53 PM, Hannes Tschofenig wrote:
=0A
=0A> I would no= t worry about OAuth 1.0 since the functionality we want in SASL OAuth is mu= ch better supported by OAuth 2.0.
=0A>
=0A> On Aug 11, 2012, a= t 7:15 PM, William Mills wrote:
=0A>
=0A>> Early on there w= as resistance from folks to mentioning OAuth 1.0a because "there's no point= , OAuth 1.0a is dead".  I can add the text back in easily.  Given= the arguments about reviving the MAC draft in the OAuth WG I could change = the MAC examples out to OAuth 1.0a so this draft relies on a finalized spec= instead.
=0A>>
=0A>> Do people like that?  Hate i= t?
=0A>>
=0A>>
=0A>> From: Simon Josefsson <= ;simon@josefsson.org>
=0A>> T= o: William Mills <wmills@yahoo-inc.com= >
=0A>> Cc: "Cantor, Scott" <= cantor.2@osu.edu>; "kitten@ietf.org" <kitten@ietf.org>
=0A>>= ; Sent: Saturday, August 11, 2012 12:43 AM
=0A>> Subject: Re: OAUT= H SASL and Channel binding
=0A>>
=0A>> Which brings up a= nother question: Is the SASL mechanism intended to
=0A>> apply to = both OAuth 2.0 and OAuth 1.0?  If that is the intention, I
=0A>&= gt; think this should be clear from the introduction and throughout the
= =0A>> document.  This poses some challenges though, since the OA= uth 1.x and
=0A>> OAuth 2.x terminology and semantics differs some= what.
=0A>>
=0A>> I'm working on an implementation, and = I've gone back and forth between
=0A>> using libraries for OAuth 1= .x and Oauth 2.x.
=0A>>
=0A>> /Simon
=0A>>
= =0A>> William Mills <wmills@yahoo-in= c.com> writes:
=0A>>
=0A>>> You could have an = integrity guarantee for a signed profile like MAC or OAuth 1.0a.
=0A>= >>
=0A>>>
=0A>>>
=0A>>>
= =0A>>>
=0A>>>> ________________________________=0A>>>> From: "Cantor, Scott" <cantor.2@osu.edu>
=0A>>>> To: William Mills <wmills@yahoo-inc.com>; "kitten@ietf.org" <kitten= @ietf.org>
=0A>>>> Sent: Friday, August 10, 2012 11:= 39 AM
=0A>>>> Subject: Re: [kitten] OAUTH SASL and Channel b= inding
=0A>>>>
=0A>>>> On 8/10/12 2:36 PM, "= William Mills" <wmills@yahoo-inc.com&g= t; wrote:
=0A>>>>
=0A>>>>> Given Simon's = recent comments about the fundamental flaw in the idea of
=0A>>>= ;>> channel binding when you don't have an integrity guarantee,, as i= n the
=0A>>>>> Bearer token use case, should channel bind= ing remain in the OAuth SASL
=0A>>>>> profile?
=0A>= >>>
=0A>>>> If you can never have an integrity gua= rantee, probably not, but I wouldn't
=0A>>>> personally use = such a mechanism in any case, so probably moot.
=0A>>>>
= =0A>>>> -- Scott
=0A>>>>
=0A>>>>=
=0A>>>>
=0A>>>>
=0A>>> ______= _________________________________________
=0A>>> Kitten mailing= list
=0A>>> Kitten@ietf.org<= br>=0A>>> https://www.ietf.org/mailman/listinfo/k= itten
=0A>>
=0A>>
=0A>> __________________= _____________________________
=0A>> Kitten mailing list
=0A>= > Kitten@ietf.org
=0A>> https://www.ietf.org/mailman/listinfo/kitten
=0A> =0A
=0A
=0A
=0A 
=0A
=0A 
=0A<= /span>
  
=0A=
=0A
<= font size=3D"2">_______________________________________________
=0A= Kitten mailing list
=0AKitten@ietf.org=
=0Ahttps://www.ietf.org/mailman/listinfo/kitten=0A
=0A
=0A=0A=0A


--1935884094-1797151612-1344828671=:93823-- From internet-drafts@ietf.org Mon Aug 13 11:08:32 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBB421F86D6; Mon, 13 Aug 2012 11:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFCMzysiTMrQ; Mon, 13 Aug 2012 11:08:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBFA21F86C3; Mon, 13 Aug 2012 11:08:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120813180831.11375.1808.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2012 11:08:31 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 18:08:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. Title : SAML Enhanced Client SASL and GSS-API Mechanisms Author(s) : Scott Cantor Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-ec-02.txt Pages : 32 Date : 2012-08-13 Abstract: Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-saml-ec-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Hannes.Tschofenig@gmx.net Tue Aug 14 22:35:57 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BC721E80AB for ; Tue, 14 Aug 2012 22:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1As+NXco0eC for ; Tue, 14 Aug 2012 22:35:56 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B499921E8086 for ; Tue, 14 Aug 2012 22:35:55 -0700 (PDT) Received: (qmail invoked by alias); 15 Aug 2012 05:35:53 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp004) with SMTP; 15 Aug 2012 07:35:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX197rT57LKV7jWQ9ySdH+jdKL9WeeoZR59zgu1jour RKRcAYWbVsGKPX Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: <1344828671.93823.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Wed, 15 Aug 2012 08:35:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5CAFEC4F-3468-4EC8-82AF-31BBCBB085E6@gmx.net> References: <1344706384.36422.YahooMailNeo@web31805.mail.mud.yahoo.com> <1344828671.93823.YahooMailNeo@web31810.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 05:35:57 -0000 Hi Bill,=20 you may be surprised to hear that there is not that much difference = between the different security mechanisms. See an early writeup I made = when we had the discussions on the OAuth list in 2010. Not that anyone = had ever read my draft but here it is: = http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt (What is not mentioned in the draft is that bearer and the MAC token is = equally insecure when using a client that is unable to keep a secret = confidential.) Anyway, I presented three choices in my previous mail to you about the = next possible steps and I didn't understood which one you picked: > =95 Focus on Oauth 1.0 only (since it has a MAC specification in = there). Then, you ignore all the Oauth 2.0 deployment that is out there, = of which there is a lot. That would be pretty bad IMHO. > =95 Copy relevant parts from = http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 (of which = there is almost no deployment). > =95 Wait for the Oauth group to settle on a mechanism. May take = time.=20 Ciao Hannes On Aug 13, 2012, at 6:31 AM, William Mills wrote: > For a complete solution for clients what I demand is auth endpoint = discovery for standalone cleints. Webfinger/SWD seems to solve my = problem, it's functional and I can work with it. I really *DO NOT CARE* = how this problem gets solved, but it must be solved.=20 >=20 > Several more things: >=20 > - OAuth 1.0a style credentials solve some problems for me because = we have extant integrations that could use SASL/OAUTH profile = immediately. > - I don't want to solve OAuth 1.0a's problems in this draft. > - I don't want to wait for MAC since it's now apparently going back = to committee to be completely re-evaluated. >=20 > I'm willing to accept that we're going to have a number of compromises = here. Bearer tokens are only slightly better than cookies (because the = browser as a confused deputy is sort of fixed). OAuth 1.0a with = plaintext (it is to laugh) secrets are similarly bad. =20 >=20 > I take it as fact that we will have additional signed OAuth 2 = profiles, and so I want to provide examples for this type of profile. I = am not willing to make this incompatible with 1.0a or write it out of = the spec as not allowed.=20 >=20 > In fact, while we shoudl make sure the draft isn't fundamentally = broken, Like having channel binding wit bearer tokens whihc is useless, = my intent is to punt all of the security considerations for using 1.0a = or Bearer or JWT et al back ot those specs. >=20 > -bill >=20 >=20 >=20 > From: Hannes Tschofenig > To: William (Bill) Mills ; Hannes Tschofenig = =20 > Cc: "kitten@ietf.org" ; Simon Josefsson = =20 > Sent: Sunday, August 12, 2012 10:10 AM > Subject: Re: [kitten] OAUTH SASL and Channel binding >=20 > Hi Bill,=20 >=20 > Thanks for the quick feedback. >=20 > I think you care about providing good security support for the SASL = OAuth specification as much as I do. Of course we also want to take the = existing deployment into consideration as well. These two aspects often = do not line up nicely (as I can tell you from my past experience in the = identity management field).=20 >=20 > So, how do we get there?=20 >=20 > In order to use Oauth 1.0 you have to do several things to avoid = security disaster:=20 >=20 > =95 Avoid using the plaintext signature type without TLS. The = IESG required this in the published RFC but the deployment reality may = look different. =20 > =95 Use TLS when obtaining a the MAC shared key for usage with = the MAC "authentication". The description of TLS for the = client-to-authorization server interaction is actually quite fuzzy since = the main motivation for TLS support in Oauth was to support client = deployments that don't want to support TLS (for performance reasons =97see= my recent mail to the Oauth mailing list with a pointer to an old slide = set). > =95 Avoid using PK-based authentication from Oauth 1.0 since = it's description is incomplete. >=20 > This essentially means that you are down to=20 > =95 using TLS with the authorization server and > =95 either using the equivalent of bearer tokens (which is the = plaintext variant on top of TLS) or MAC tokens.=20 >=20 > The MAC token variant allows us to skip TLS (with loss of = confidentiality protection of course; we also loose the ability to = protect the entire message exchange and authentication of the server) = but then for the use case you worry about TLS will have to be supported = also for subsequent data exchanges - accessing your emails using TLS is = quite common these days. I guess you may agree.=20 >=20 > Ideally, we therefore want to have application layer security in = addition to TLS in order to provide the proper protection. The channel = binding discussion very much relates to aspect. >=20 > How many Oauth 1.0 deployments are actually fulfilling these = requirements out of the box? Not that many, I would say. Then, you also = seem to demand the support for WebFinger. >=20 > Let's assume you want to have something better than Bearer Tokens. So, = what should we do? There are three choices: >=20 > =95 Focus on Oauth 1.0 only (since it has a MAC specification in = there). Then, you ignore all the Oauth 2.0 deployment that is out there, = of which there is a lot. That would be pretty bad IMHO. > =95 Copy relevant parts from = http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 (of which = there is almost no deployment). > =95 Wait for the Oauth group to settle on a mechanism. May take = time.=20 >=20 > A difficult decision.=20 >=20 > Which one do you pick?=20 >=20 > On the "grant type" issue. The "Resource Owner Password Credentials" = grant type essentially requires the client to have the user's long-term = username and password (at least for obtaining the access token). In some = sense this is actually the use case that many wanted to avoid when using = Oauth. Since you are as concerned about security as myself I am = wondering whether this is OK for you? I think it is pretty bad.=20 >=20 > In addition to the "Resource Owner Password Credentials" grant type = there are these other grant types:=20 > =95 the client credentials grant type? > =95 the implict grant type?=20 >=20 > Would you also like to support them? >=20 > Ciao > Hannes >=20 > PS: You may have noticed that the Oauth 1.0 security terminology is a = bit messed up. I am not sure whether we can avoid carrying it over to = the Oauth SASL specification. For example, the term "signature" is not = correct if we are talking about a MAC. The correct term would be (keyed) = message digest. The MAC algorithm, as defined in , RFC 5849, actually = doesn't provide authentication. It provides key confirmation, i.e. It = shows that the client had previously obtained a key from the = authorization server but it does not tell who the client is. =20 >=20 >=20 > On 8/11/12 8:33 PM, "William (Bill) Mills" = wrote: >=20 > We fundamentally disagree on a number of things here. As a practical = matter we need to support the password grant. =20 >=20 > Please explain how MAC, or a signature mechanism, is not 1:1 = compatible. To me it seems a solid fit, it was part of the design. >=20 > I do not want to use this to define a new way of getting tokens or PKI = or define new tokens that support channel binding. This is specifically = for leveraging the OAuth infrastructure which already defines much or = all of this. >=20 > -bill >=20 >=20 > =20 > =20 >=20 > =20 > From: Hannes Tschofenig > To: Hannes Tschofenig =20 > Cc: William Mills ; Simon Josefsson = ; "kitten@ietf.org" =20 > Sent: Saturday, August 11, 2012 10:14 AM > Subject: Re: [kitten] OAUTH SASL and Channel binding > =20 > =20 > I should probably add a bit more text. >=20 > We don't need the MAC or PK-based signature mechanism since they are = not 1:1 compatible with what we are doing in SASL. So, we can ignore = them. In addition, the PK-based signature mechanism has the problem that = it does not provide a story for how the client dynamically obtains the = public / private key. In a nutshell it is undeployable.=20 >=20 > Depending on the timeline you have in mind we may either re-use the = Bearer Token specification or wait for the current security discussions = to settle to add a more secure mechanism. There may also be no harm to = define our own security mechanism for presenting the access token to the = resource server if we want channel binding and other security features = added since those will not likely be used in the HTTPS environment due = to TLS load balancers.=20 >=20 > An important part from the OAuth specifications we want is a mechanism = for requesting an access token and to obtain the resource owners consent = prior to that step. OAuth 2.0 provides a well-written specification for = that. Additionally, there is a lot of deployment available.=20 >=20 > We may, however, indicate that we only want to support the = 'Authorization Code' grant type and not the other grant types since they = are not useful in our scenario. =20 >=20 > Ciao > Hannes >=20 > On Aug 11, 2012, at 7:53 PM, Hannes Tschofenig wrote: >=20 > > I would not worry about OAuth 1.0 since the functionality we want in = SASL OAuth is much better supported by OAuth 2.0. > >=20 > > On Aug 11, 2012, at 7:15 PM, William Mills wrote: > >=20 > >> Early on there was resistance from folks to mentioning OAuth 1.0a = because "there's no point, OAuth 1.0a is dead". I can add the text back = in easily. Given the arguments about reviving the MAC draft in the = OAuth WG I could change the MAC examples out to OAuth 1.0a so this draft = relies on a finalized spec instead.=20 > >>=20 > >> Do people like that? Hate it? > >>=20 > >>=20 > >> From: Simon Josefsson > >> To: William Mills =20 > >> Cc: "Cantor, Scott" ; "kitten@ietf.org" = =20 > >> Sent: Saturday, August 11, 2012 12:43 AM > >> Subject: Re: OAUTH SASL and Channel binding > >>=20 > >> Which brings up another question: Is the SASL mechanism intended to > >> apply to both OAuth 2.0 and OAuth 1.0? If that is the intention, I > >> think this should be clear from the introduction and throughout the > >> document. This poses some challenges though, since the OAuth 1.x = and > >> OAuth 2.x terminology and semantics differs somewhat. > >>=20 > >> I'm working on an implementation, and I've gone back and forth = between > >> using libraries for OAuth 1.x and Oauth 2.x. > >>=20 > >> /Simon > >>=20 > >> William Mills writes: > >>=20 > >>> You could have an integrity guarantee for a signed profile like = MAC or OAuth 1.0a. > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>> ________________________________ > >>>> From: "Cantor, Scott" > >>>> To: William Mills ; "kitten@ietf.org" = =20 > >>>> Sent: Friday, August 10, 2012 11:39 AM > >>>> Subject: Re: [kitten] OAUTH SASL and Channel binding > >>>>=20 > >>>> On 8/10/12 2:36 PM, "William Mills" wrote: > >>>>=20 > >>>>> Given Simon's recent comments about the fundamental flaw in the = idea of > >>>>> channel binding when you don't have an integrity guarantee,, as = in the > >>>>> Bearer token use case, should channel binding remain in the = OAuth SASL > >>>>> profile? > >>>>=20 > >>>> If you can never have an integrity guarantee, probably not, but I = wouldn't > >>>> personally use such a mechanism in any case, so probably moot. > >>>>=20 > >>>> -- Scott > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>> _______________________________________________ > >>> Kitten mailing list > >>> Kitten@ietf.org > >>> https://www.ietf.org/mailman/listinfo/kitten > >>=20 > >>=20 > >> _______________________________________________ > >> Kitten mailing list > >> Kitten@ietf.org > >> https://www.ietf.org/mailman/listinfo/kitten > >=20 >=20 >=20 >=20 > =20 >=20 > =20 > =20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 >=20 From wmills@yahoo-inc.com Tue Aug 14 22:58:46 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF4211E80A5 for ; Tue, 14 Aug 2012 22:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.545 X-Spam-Level: X-Spam-Status: No, score=-17.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huGostXoAsIE for ; Tue, 14 Aug 2012 22:58:44 -0700 (PDT) Received: from nm18-vm1.bullet.mail.ne1.yahoo.com (nm18-vm1.bullet.mail.ne1.yahoo.com [98.138.91.64]) by ietfa.amsl.com (Postfix) with SMTP id ACA4511E8099 for ; Tue, 14 Aug 2012 22:58:42 -0700 (PDT) Received: from [98.138.90.51] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 15 Aug 2012 05:58:38 -0000 Received: from [98.138.89.233] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 15 Aug 2012 05:58:37 -0000 Received: from [127.0.0.1] by omp1048.mail.ne1.yahoo.com with NNFMP; 15 Aug 2012 05:58:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 978439.21822.bm@omp1048.mail.ne1.yahoo.com Received: (qmail 38115 invoked by uid 60001); 15 Aug 2012 05:58:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345010317; bh=GAInSrxUHWlfzMWfecV5+D6a65W6nZVfaYhk8DMUNNo=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ljc9Q2PmdmrcEA6Ccnu7xXR0U0bYhyw9t5ZuR8PcdBxXbidT8H7ODouFs6Y4B7IfBzH8WlJ+dBb7vQfQzG8dAl9rugmAZqGimGg113gCI65Q4PZvOvIa5cJRSMRnlkzf1nK97ebS1qZh0nneqvoAheWlXhJI3bNCChejkU9lJwc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nP9bEsEYv5mkxFe9yohws66fKJX3oH9sl1DDINCbaNTPln0KuQ/gnXu759Emvk8RQQxEq8+iTLTKdNLgJRbI+pcvpiYFJoKa4X8Yfs0vY4vrhg50kSsRV//ChQrCJ0fEFdzBSCeYf5pZr7UqLlNk0cIjMzNEpozQ+RDj1lS7enQ=; X-YMail-OSG: 427HN8cVM1nJWQQTCop3ZyX0YO.ChZtOe4iun4xFUyz3ymk GL9yjXMGPTVGOm.ippMgeXbST9MOKVQeBDcubvtyvBg59IEwSRi6lNfwIlzW qd7drQn7p2MsDHdqB4h1JeyaPms8AQ.ZhrYqUeXZ8sKVtMlvN9xIjE6E4HfO sbfbXukJiWofbUQwu19p8Qsmu1NFxCZUVTvIEJxvm_2AFKU45vRTXzICr3SP hefa2WIOo944c2FtoiXBGoIxCOSBAhy8.IbbiGJLbUj803fPG245ySJbd0Ax ssN_h_A_woGqJU7AB79Em2pQaFtqr7U6yjVO1fal9WHHYIsNqBu6e3BuIeyh tfdIkOzWb7qLRmarOXzq3JMvNVHaCH5B56jxDgv2tl1vOK1qGpyuYTxo0tXq QcJhunnkJI9DbFQBu16T5RKP1LRs6g86gAOpkG7WdFL42o._qhOafl5456nA 7T8eyKkM- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Tue, 14 Aug 2012 22:58:37 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1344706384.36422.YahooMailNeo@web31805.mail.mud.yahoo.com> <1344828671.93823.YahooMailNeo@web31810.mail.mud.yahoo.com> <5CAFEC4F-3468-4EC8-82AF-31BBCBB085E6@gmx.net> Message-ID: <1345010317.37566.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Tue, 14 Aug 2012 22:58:37 -0700 (PDT) From: William Mills To: Hannes Tschofenig In-Reply-To: <5CAFEC4F-3468-4EC8-82AF-31BBCBB085E6@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-2082713088-1345010317=:37566" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 05:58:46 -0000 --1458549034-2082713088-1345010317=:37566 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sure, if you can't keep a secret you're done, there's no secure model.=C2= =A0 I think you're talking an edge case and generalizing that, saying "if w= e have no client confidentiality then all things are equally insecure". Is = that truly worth considering?=C2=A0 =0A=0A=0AThe advantages of MAC and 1.0a= over Bearer when you CAN keep a secret are: that you can make securely aut= horized protected resource transactions without TLS or other transport secu= rity, and that the client requires 2 pieces of information (token and secre= t) which can be stored separately.=C2=A0 Are you arguing that MAC and Beare= r are equivalent when the clients cankeep a secret?=0A=0A-bill=0A=0A=0A=0A= =0A=0A>________________________________=0A> From: Hannes Tschofenig =0A>To: William Mills =0A>Cc: Ha= nnes Tschofenig ; Hannes Tschofenig ; "kitten@ietf.org" ; Simon Josefsson =0A>Sent: Tuesday, August 14, 2012 10:35 PM=0A>Subject: Re= : [kitten] OAUTH SASL and Channel binding=0A> =0A>Hi Bill, =0A>=0A>you may = be surprised to hear that there is not that much difference between the dif= ferent security mechanisms. See an early writeup I made when we had the dis= cussions on the OAuth list in 2010. Not that anyone had ever read my draft = but here it is:=0A>http://tools.ietf.org/id/draft-tschofenig-oauth-signatur= e-thoughts-00.txt=0A>=0A>(What is not mentioned in the draft is that bearer= and the MAC token is equally insecure when using a client that is unable t= o keep a secret confidential.)=0A>=0A>Anyway, I presented three choices in = my previous mail to you about the next possible steps and I didn't understo= od which one you picked:=0A>=0A>> =C2=A0=C2=A0=C2=A0 =E2=80=A2 Focus on Oau= th 1.0 only (since it has a MAC specification in there). Then, you ignore a= ll the Oauth 2.0 deployment that is out there, of which there is a lot. Tha= t would be pretty bad IMHO.=0A>> =C2=A0=C2=A0=C2=A0 =E2=80=A2 Copy relevant= parts from http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 (of = which there is almost no deployment).=0A>> =C2=A0=C2=A0=C2=A0 =E2=80=A2 Wai= t for the Oauth group to settle on a mechanism. May take time. =0A>=0A>Ciao= =0A>Hannes=0A>=0A>On Aug 13, 2012, at 6:31 AM, William Mills wrote:=0A>=0A>= > For a complete solution for clients what I demand is auth endpoint discov= ery for standalone cleints.=C2=A0 Webfinger/SWD seems to solve my problem, = it's functional and I can work with it.=C2=A0 I really *DO NOT CARE* how th= is problem gets solved, but it must be solved. =0A>> =0A>> Several more thi= ngs:=0A>> =0A>> -=C2=A0 =C2=A0 OAuth 1.0a style credentials solve some prob= lems for me because we have extant integrations that could use SASL/OAUTH p= rofile immediately.=0A>> -=C2=A0 =C2=A0 I don't want to solve OAuth 1.0a's = problems in this draft.=0A>> -=C2=A0 =C2=A0 I don't want to wait for MAC si= nce it's now apparently going back to committee to be completely re-evaluat= ed.=0A>> =0A>> I'm willing to accept that we're going to have a number of c= ompromises here.=C2=A0 Bearer tokens are only slightly better than cookies = (because the browser as a confused deputy is sort of fixed).=C2=A0 OAuth 1.= 0a with plaintext (it is to laugh) secrets are similarly bad.=C2=A0 =0A>> = =0A>> I take it as fact that we will have additional signed OAuth 2 profile= s, and so I want to provide examples for this type of profile.=C2=A0 I am n= ot willing to make this incompatible with 1.0a or write it out of the spec = as not allowed. =0A>> =0A>> In fact, while we shoudl make sure the draft is= n't fundamentally broken, Like having channel binding wit bearer tokens whi= hc is useless, my intent is to punt all of the security considerations for = using 1.0a or Bearer or JWT et al back ot those specs.=0A>> =0A>> -bill=0A>= > =0A>> =0A>> =0A>> From: Hannes Tschofenig =0A>= > To: William (Bill) Mills ; Hannes Tschofenig =0A>> Cc: "kitten@ietf.org" ; Simon = Josefsson =0A>> Sent: Sunday, August 12, 2012 10:10 A= M=0A>> Subject: Re: [kitten] OAUTH SASL and Channel binding=0A>> =0A>> Hi B= ill, =0A>> =0A>> Thanks for the quick feedback.=0A>> =0A>> I think you care= about providing good security support for the SASL OAuth specification as = much as I do. Of course we also want to take the existing deployment into c= onsideration as well. These two aspects often do not line up nicely (as I c= an tell you from my past experience in the identity management field). =0A>= > =0A>> So, how do we get there? =0A>> =0A>> In order to use Oauth 1.0 you = have to do several things to avoid security disaster: =0A>> =0A>> =C2=A0=C2= =A0=C2=A0 =E2=80=A2 Avoid using the plaintext signature type without TLS. T= he IESG required this in the published RFC but the deployment reality may l= ook different.=C2=A0 =0A>> =C2=A0=C2=A0=C2=A0 =E2=80=A2 Use TLS when obtain= ing a the MAC shared key for usage with the MAC "authentication". The descr= iption of TLS for the client-to-authorization server interaction is actuall= y quite fuzzy since the main motivation for TLS support in Oauth was to sup= port client deployments that don't want to support TLS (for performance rea= sons =E2=80=94see my recent mail to the Oauth mailing list with a pointer t= o an old slide set).=0A>> =C2=A0=C2=A0=C2=A0 =E2=80=A2 Avoid using PK-based= authentication from Oauth 1.0 since it's description is incomplete.=0A>> = =0A>> This essentially means that you are down to =0A>> =C2=A0=C2=A0=C2=A0 = =E2=80=A2 using TLS with the authorization server and=0A>> =C2=A0=C2=A0=C2= =A0 =E2=80=A2 either using the equivalent of bearer tokens (which is the pl= aintext variant on top of TLS) or MAC tokens. =0A>> =0A>> The MAC token var= iant allows us to skip TLS (with loss of confidentiality protection of cour= se; we also loose the ability to protect the entire message exchange and au= thentication of the server) but then for the use case you worry about TLS w= ill have to be supported also for subsequent data exchanges - accessing you= r emails using TLS is quite common these days. I guess you may agree. =0A>>= =0A>> Ideally, we therefore want to have application layer security in add= ition to TLS in order to provide the proper protection. The channel binding= discussion very much relates to aspect.=0A>> =0A>> How many Oauth 1.0 depl= oyments are actually fulfilling these requirements out of the box? Not that= many, I would say. Then, you also seem to demand the support for WebFinger= .=0A>> =0A>> Let's assume you want to have something better than Bearer Tok= ens. So, what should we do? There are three choices:=0A>> =0A>> =C2=A0=C2= =A0=C2=A0 =E2=80=A2 Focus on Oauth 1.0 only (since it has a MAC specificati= on in there). Then, you ignore all the Oauth 2.0 deployment that is out the= re, of which there is a lot. That would be pretty bad IMHO.=0A>> =C2=A0=C2= =A0=C2=A0 =E2=80=A2 Copy relevant parts from http://tools.ietf.org/html/dra= ft-ietf-oauth-v2-http-mac-01 (of which there is almost no deployment).=0A>>= =C2=A0=C2=A0=C2=A0 =E2=80=A2 Wait for the Oauth group to settle on a mecha= nism. May take time. =0A>> =0A>> A difficult decision. =0A>> =0A>> Which on= e do you pick? =0A>> =0A>> On the "grant type" issue. The "Resource Owner P= assword Credentials" grant type essentially requires the client to have the= user's long-term username and password (at least for obtaining the access = token). In some sense this is actually the use case that many wanted to avo= id when using Oauth. Since you are as concerned about security as myself I = am wondering whether this is OK for you? I think it is pretty bad. =0A>> = =0A>> In addition to the "Resource Owner Password Credentials" grant type t= here are these other grant types: =0A>> =C2=A0=C2=A0=C2=A0 =E2=80=A2 the cl= ient credentials grant type?=0A>> =C2=A0=C2=A0=C2=A0 =E2=80=A2 the implict = grant type? =0A>> =0A>> Would you also like to support them?=0A>> =0A>> Cia= o=0A>> Hannes=0A>> =0A>> PS: You may have noticed that the Oauth 1.0 securi= ty terminology is a bit messed up. I am not sure whether we can avoid carry= ing it over to the Oauth SASL specification. For example, the term "signatu= re" is not correct if we are talking about a MAC. The correct term would be= (keyed) message digest. The MAC algorithm, as defined in , RFC 5849, actua= lly doesn't provide authentication. It provides key confirmation, i.e. It s= hows that the client had previously obtained a key from the authorization s= erver but it does not tell who the client is.=C2=A0 =0A>> =0A>> =0A>> On 8/= 11/12 8:33 PM, "William (Bill) Mills" wrote:=0A>> = =0A>> We fundamentally disagree on a number of things here.=C2=A0 As a prac= tical matter we need to support the password grant.=C2=A0 =0A>> =0A>> Pleas= e explain how MAC, or a signature mechanism, is not 1:1 compatible.=C2=A0 T= o me it seems a solid fit, it was part of the design.=0A>> =0A>> I do not w= ant to use this to define a new way of getting tokens or PKI or define new = tokens that support channel binding.=C2=A0 This is specifically for leverag= ing the OAuth infrastructure which already defines much or all of this.=0A>= > =0A>> -bill=0A>> =0A>> =0A>>=C2=A0 =0A>>=C2=A0 =0A>> =0A>>=C2=A0 =0A>>=C2= =A0 From: Hannes Tschofenig =0A>>=C2=A0 To: Hann= es Tschofenig =0A>> Cc: William Mills ; Simon Josefsson ; "kitten@ietf.org" =0A>>=C2=A0 Sent: Saturday, August 11, 2012 10:14 AM=0A>>=C2= =A0 Subject: Re: [kitten] OAUTH SASL and Channel binding=0A>>=C2=A0 =0A>>= =C2=A0 =0A>> I should probably add a bit more text.=0A>> =0A>> We don't nee= d the MAC or PK-based signature mechanism since they are not 1:1 compatible= with what we are doing in SASL. So, we can ignore them. In addition, the P= K-based signature mechanism has the problem that it does not provide a stor= y for how the client dynamically obtains the public / private key. In a nut= shell it is undeployable. =0A>> =0A>> Depending on the timeline you have in= mind we may either re-use the Bearer Token specification or wait for the c= urrent security discussions to settle to add a more secure mechanism. There= may also be no harm to define our own security mechanism for presenting th= e access token to the resource server if we want channel binding and other = security features added since those will not likely be used in the HTTPS en= vironment due to TLS load balancers. =0A>> =0A>> An important part from the= OAuth specifications we want is a mechanism for requesting an access token= and to obtain the resource owners consent prior to that step. OAuth 2.0 pr= ovides a well-written specification for that. Additionally, there is a lot = of deployment available. =0A>> =0A>> We may, however, indicate that we only= want to support the 'Authorization Code' grant type and not the other gran= t types since they are not useful in our scenario.=C2=A0 =0A>> =0A>> Ciao= =0A>> Hannes=0A>> =0A>> On Aug 11, 2012, at 7:53 PM, Hannes Tschofenig wrot= e:=0A>> =0A>> > I would not worry about OAuth 1.0 since the functionality w= e want in SASL OAuth is much better supported by OAuth 2.0.=0A>> > =0A>> > = On Aug 11, 2012, at 7:15 PM, William Mills wrote:=0A>> > =0A>> >> Early on = there was resistance from folks to mentioning OAuth 1.0a because "there's n= o point, OAuth 1.0a is dead".=C2=A0 I can add the text back in easily.=C2= =A0 Given the arguments about reviving the MAC draft in the OAuth WG I coul= d change the MAC examples out to OAuth 1.0a so this draft relies on a final= ized spec instead. =0A>> >> =0A>> >> Do people like that?=C2=A0 Hate it?=0A= >> >> =0A>> >> =0A>> >> From: Simon Josefsson =0A>> >>= To: William Mills =0A>> >> Cc: "Cantor, Scott" ; "kitten@ietf.org" =0A>> >> Sent: Saturday= , August 11, 2012 12:43 AM=0A>> >> Subject: Re: OAUTH SASL and Channel bind= ing=0A>> >> =0A>> >> Which brings up another question: Is the SASL mechanis= m intended to=0A>> >> apply to both OAuth 2.0 and OAuth 1.0?=C2=A0 If that = is the intention, I=0A>> >> think this should be clear from the introductio= n and throughout the=0A>> >> document.=C2=A0 This poses some challenges tho= ugh, since the OAuth 1.x and=0A>> >> OAuth 2.x terminology and semantics di= ffers somewhat.=0A>> >> =0A>> >> I'm working on an implementation, and I've= gone back and forth between=0A>> >> using libraries for OAuth 1.x and Oaut= h 2.x.=0A>> >> =0A>> >> /Simon=0A>> >> =0A>> >> William Mills writes:=0A>> >> =0A>> >>> You could have an integrity guarantee f= or a signed profile like MAC or OAuth 1.0a.=0A>> >>> =0A>> >>> =0A>> >>> = =0A>> >>> =0A>> >>> =0A>> >>>> ________________________________=0A>> >>>> F= rom: "Cantor, Scott" =0A>> >>>> To: William Mills ; "kitten@ietf.org" =0A>> >>>> Sent: Frida= y, August 10, 2012 11:39 AM=0A>> >>>> Subject: Re: [kitten] OAUTH SASL and = Channel binding=0A>> >>>> =0A>> >>>> On 8/10/12 2:36 PM, "William Mills" wrote:=0A>> >>>> =0A>> >>>>> Given Simon's recent comm= ents about the fundamental flaw in the idea of=0A>> >>>>> channel binding w= hen you don't have an integrity guarantee,, as in the=0A>> >>>>> Bearer tok= en use case, should channel binding remain in the OAuth SASL=0A>> >>>>> pro= file?=0A>> >>>> =0A>> >>>> If you can never have an integrity guarantee, pr= obably not, but I wouldn't=0A>> >>>> personally use such a mechanism in any= case, so probably moot.=0A>> >>>> =0A>> >>>> -- Scott=0A>> >>>> =0A>> >>>>= =0A>> >>>> =0A>> >>>> =0A>> >>> __________________________________________= _____=0A>> >>> Kitten mailing list=0A>> >>> Kitten@ietf.org=0A>> >>> https:= //www.ietf.org/mailman/listinfo/kitten=0A>> >> =0A>> >> =0A>> >> __________= _____________________________________=0A>> >> Kitten mailing list=0A>> >> K= itten@ietf.org=0A>> >> https://www.ietf.org/mailman/listinfo/kitten=0A>> > = =0A>> =0A>> =0A>> =0A>>=C2=A0 =0A>> =0A>>=C2=A0 =0A>>=C2=A0 =0A>> =0A>> ___= ____________________________________________=0A>> Kitten mailing list=0A>> = Kitten@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/kitten=0A>> =0A>= > =0A>=0A>=0A>=0A> --1458549034-2082713088-1345010317=:37566 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Sure, if = you can't keep a secret you're done, there's no secure model.  I think= you're talking an edge case and generalizing that, saying "if we have no c= lient confidentiality then all things are equally insecure". Is that truly = worth considering? 

The advantage= s of MAC and 1.0a over Bearer when you CAN keep a secret are: that you can = make securely authorized protected resource transactions without TLS or oth= er transport security, and that the client requires 2 pieces of information= (token and secret) which can be stored separately.  Are you arguing t= hat MAC and Bearer are equivalent when the clients cankeep a secret?
<= div>
-bill

=
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: William Mills <wmills@yahoo-= inc.com>
Cc: Hannes= Tschofenig <Hannes.Tschofenig@gmx.net>; Hannes Tschofenig <Hannes.Tschofenig@nsn.com>; "kitten@ietf.org" <kitten@ietf.org&g= t;; Simon Josefsson <simon@josefsson.org>
Sent: Tuesday, August 14, 2012 10:35 PM
<= span style=3D"font-weight: bold;">Subject: Re: [kitten] OAUTH SA= SL and Channel binding

Hi Bill,

you may be s= urprised to hear that there is not that much difference between the differe= nt security mechanisms. See an early writeup I made when we had the discuss= ions on the OAuth list in 2010. Not that anyone had ever read my draft but = here it is:
http://tools.ietf.org/id/draft-= tschofenig-oauth-signature-thoughts-00.txt

(What is not mentione= d in the draft is that bearer and the MAC token is equally insecure when us= ing a client that is unable to keep a secret confidential.)

Anyway, = I presented three choices in my previous mail to you about the next possible= steps and I didn't understood which one you picked:

>  &nbs= p;  =E2=80=A2 Focus on Oauth 1.0 only (since it has a MAC specificatio= n in there). Then, you ignore all the Oauth 2.0 deployment that is out ther= e, of which there is a lot. That would be pretty bad IMHO.
>  &n= bsp;  =E2=80=A2 Copy relevant parts from http://tools.ie= tf.org/html/draft-ietf-oauth-v2-http-mac-01 (of which there is almost n= o deployment).
>     =E2=80=A2 Wait for the Oauth grou= p to settle on a mechanism. May take time.

Ciao
Hannes

On= Aug 13, 2012, at 6:31 AM, William Mills wrote:

> For a complete = solution for clients what I demand is auth endpoint discovery for standalon= e cleints.  Webfinger/SWD seems to solve my problem, it's functional a= nd I can work with it.  I really *DO NOT CARE* how this problem gets solved, but it= must be solved.
>
> Several more things:
>
> -&= nbsp;   OAuth 1.0a style credentials solve some problems for me becaus= e we have extant integrations that could use SASL/OAUTH profile immediately= .
> -    I don't want to solve OAuth 1.0a's problems in thi= s draft.
> -    I don't want to wait for MAC since it's now= apparently going back to committee to be completely re-evaluated.
> =
> I'm willing to accept that we're going to have a number of comprom= ises here.  Bearer tokens are only slightly better than cookies (becau= se the browser as a confused deputy is sort of fixed).  OAuth 1.0a wit= h plaintext (it is to laugh) secrets are similarly bad. 
>
= > I take it as fact that we will have additional signed OAuth 2 profiles= , and so I want to provide examples for this type of profile.  I am not willing to make this incompatible with 1.0a or write it out of th= e spec as not allowed.
>
> In fact, while we shoudl make sure= the draft isn't fundamentally broken, Like having channel binding wit bear= er tokens whihc is useless, my intent is to punt all of the security consid= erations for using 1.0a or Bearer or JWT et al back ot those specs.
>=
> -bill
>
>
>
> From: Hannes Tschofenig = <Hannes.Tschofenig@nsn.com>
> To: William (B= ill) Mills <wmills@yahoo-inc.com>; Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
> Cc: "kitten@ietf.org"= <kitten@= ietf.org>; Simon Josefsson <simon@josefsson.org>
&g= t; Sent: Sunday, August 12, 2012 10:10 AM
> Subject: Re: [kitten] OAU= TH SASL and Channel binding
>
> Hi Bill,
>
> Tha= nks for the quick feedback.
>
> I think you care about providi= ng good security support for the SASL OAuth specification as much as I do. = Of course we also want to take the existing deployment into consideration a= s well. These two aspects often do not line up nicely (as I can tell you fr= om my past experience in the identity management field).
>
> = So, how do we get there?
>
> In order to use Oauth 1.0 you ha= ve to do several things to avoid security disaster:
>
>  = ;   =E2=80=A2 Avoid using the plaintext signature type without TL= S. The IESG required this in the published RFC but the deployment reality may loo= k different. 
>     =E2=80=A2 Use TLS when obtai= ning a the MAC shared key for usage with the MAC "authentication". The desc= ription of TLS for the client-to-authorization server interaction is actual= ly quite fuzzy since the main motivation for TLS support in Oauth was to su= pport client deployments that don't want to support TLS (for performance re= asons =E2=80=94see my recent mail to the Oauth mailing list with a pointer = to an old slide set).
>     =E2=80=A2 Avoid using PK-b= ased authentication from Oauth 1.0 since it's description is incomplete.>
> This essentially means that you are down to
>  &= nbsp;  =E2=80=A2 using TLS with the authorization server and
> &= nbsp;   =E2=80=A2 either using the equivalent of bearer tokens (w= hich is the plaintext variant on top of TLS) or MAC tokens.
>
&g= t; The MAC token variant allows us to skip TLS (with loss of confidentiality protection of = course; we also loose the ability to protect the entire message exchange an= d authentication of the server) but then for the use case you worry about T= LS will have to be supported also for subsequent data exchanges - accessing= your emails using TLS is quite common these days. I guess you may agree. <= br>>
> Ideally, we therefore want to have application layer secur= ity in addition to TLS in order to provide the proper protection. The chann= el binding discussion very much relates to aspect.
>
> How man= y Oauth 1.0 deployments are actually fulfilling these requirements out of t= he box? Not that many, I would say. Then, you also seem to demand the suppo= rt for WebFinger.
>
> Let's assume you want to have something = better than Bearer Tokens. So, what should we do? There are three choices:<= br>>
>     =E2=80=A2 Focus on Oauth 1.0 only (since it has a MAC specification in there). Then, you ignore all the Oaut= h 2.0 deployment that is out there, of which there is a lot. That would be = pretty bad IMHO.
>     =E2=80=A2 Copy relevant parts f= rom http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-0= 1 (of which there is almost no deployment).
>     = =E2=80=A2 Wait for the Oauth group to settle on a mechanism. May take time.=
>
> A difficult decision.
>
> Which one do you= pick?
>
> On the "grant type" issue. The "Resource Owner Pas= sword Credentials" grant type essentially requires the client to have the u= ser's long-term username and password (at least for obtaining the access to= ken). In some sense this is actually the use case that many wanted to avoid= when using Oauth. Since you are as concerned about security as myself I am wondering whether this is OK for you? I think it is pretty bad.
> <= br>> In addition to the "Resource Owner Password Credentials" grant type= there are these other grant types:
>     =E2=80=A2 t= he client credentials grant type?
>     =E2=80=A2 the = implict grant type?
>
> Would you also like to support them?<= br>>
> Ciao
> Hannes
>
> PS: You may have noti= ced that the Oauth 1.0 security terminology is a bit messed up. I am not su= re whether we can avoid carrying it over to the Oauth SASL specification. F= or example, the term "signature" is not correct if we are talking about a M= AC. The correct term would be (keyed) message digest. The MAC algorithm, as= defined in , RFC 5849, actually doesn't provide authentication. It provide= s key confirmation, i.e. It shows that the client had previously obtained a= key from the authorization server but it does not tell who the client is.&= nbsp;
>
>
> On 8/11/12 8:33 PM, "William (Bill) Mills" <= wmills@yahoo-inc.com> wrote:
>
> We fundamentally = disagree on a number of things here.  As a practical matter we need to= support the password grant. 
>
> Please explain how MAC= , or a signature mechanism, is not 1:1 compatible.  To me it seems a s= olid fit, it was part of the design.
>
> I do not want to use = this to define a new way of getting tokens or PKI or define new tokens that= support channel binding.  This is specifically for leveraging the OAu= th infrastructure which already defines much or all of this.
>
&g= t; -bill
>
>
> 
> 
>
>&n= bsp;
>  From: Hannes Tschofenig <hannes.tschofenig@gmx.net>= ;
>  To: Hannes Tschofenig <hannes.tschofenig@= gmx.net>
> Cc: William Mills <wmills@yahoo-inc.com>; Simon Josefsson <simon@josefsson.org>; "kitten@ietf.org" <kitten@ietf.org>
>  Sent: Saturday, August 11, 2012 10= :14 AM
>  Subject: Re: [kitten] OAUTH SASL and Channel binding> 
> 
> I should probably add a bit more text= .
>
> We don't need the MAC or PK-based signature mechanism si= nce they are not 1:1 compatible with what we are doing in SASL. So, we can ignore them. In = addition, the PK-based signature mechanism has the problem that it does not= provide a story for how the client dynamically obtains the public / privat= e key. In a nutshell it is undeployable.
>
> Depending on the= timeline you have in mind we may either re-use the Bearer Token specificat= ion or wait for the current security discussions to settle to add a more se= cure mechanism. There may also be no harm to define our own security mechan= ism for presenting the access token to the resource server if we want chann= el binding and other security features added since those will not likely be= used in the HTTPS environment due to TLS load balancers.
>
>= An important part from the OAuth specifications we want is a mechanism for= requesting an access token and to obtain the resource owners consent prior= to that step. OAuth 2.0 provides a well-written specification for that. Additionally, there is a lot of deployment available.
>
&= gt; We may, however, indicate that we only want to support the 'Authorizati= on Code' grant type and not the other grant types since they are not useful= in our scenario. 
>
> Ciao
> Hannes
>
&= gt; On Aug 11, 2012, at 7:53 PM, Hannes Tschofenig wrote:
>
> = > I would not worry about OAuth 1.0 since the functionality we want in S= ASL OAuth is much better supported by OAuth 2.0.
> >
> >= On Aug 11, 2012, at 7:15 PM, William Mills wrote:
> >
> &g= t;> Early on there was resistance from folks to mentioning OAuth 1.0a be= cause "there's no point, OAuth 1.0a is dead".  I can add the text back= in easily.  Given the arguments about reviving the MAC draft in the O= Auth WG I could change the MAC examples out to OAuth 1.0a so this draft rel= ies on a finalized spec instead.
> >>
> >> Do people like that?  Hate it?
> >>
> >> > >> From: Simon Josefsson <simon@josefsson.org>
= > >> To: William Mills <wmills@yahoo-inc.com>
&= gt; >> Cc: "Cantor, Scott" <cantor.2@osu.edu>; "kitten@ietf.org= " <kitten@ietf.org>
> >> Sent: Saturday, August 11, 2012 = 12:43 AM
> >> Subject: Re: OAUTH SASL and Channel binding
&g= t; >>
> >> Which brings up another question: Is the SASL= mechanism intended to
> >> apply to both OAuth 2.0 and OAuth 1= .0?  If that is the intention, I
> >> think this should be clear from = the introduction and throughout the
> >> document.  This p= oses some challenges though, since the OAuth 1.x and
> >> OAuth= 2.x terminology and semantics differs somewhat.
> >>
> = >> I'm working on an implementation, and I've gone back and forth bet= ween
> >> using libraries for OAuth 1.x and Oauth 2.x.
> = >>
> >> /Simon
> >>
> >> Willia= m Mills <wmills@yahoo-inc.com> writes:
> >>
= > >>> You could have an integrity guarantee for a signed profil= e like MAC or OAuth 1.0a.
> >>>
> >>>
&g= t; >>>
> >>>
> >>>
> >&g= t;>> ________________________________
> >>>> From: "Cantor, Scott" <cantor.2@osu.edu>
> >>>> T= o: William Mills <wmills@yahoo-inc.com>; "kitten@ietf.org" &l= t;kit= ten@ietf.org>
> >>>> Sent: Friday, August 10, 201= 2 11:39 AM
> >>>> Subject: Re: [kitten] OAUTH SASL and Ch= annel binding
> >>>>
> >>>> On 8/10/12= 2:36 PM, "William Mills" <wmills@yahoo-inc.com> wrote:
&= gt; >>>>
> >>>>> Given Simon's recent com= ments about the fundamental flaw in the idea of
> >>>>>= ; channel binding when you don't have an integrity guarantee,, as in the
> >= ;>>>> Bearer token use case, should channel binding remain in t= he OAuth SASL
> >>>>> profile?
> >>>>= ;
> >>>> If you can never have an integrity guarantee, p= robably not, but I wouldn't
> >>>> personally use such a = mechanism in any case, so probably moot.
> >>>>
> = >>>> -- Scott
> >>>>
> >>>>= ;
> >>>>
> >>>>
> >>>= _______________________________________________
> >>> Kitte= n mailing list
> >>> Kitten@ietf.org
> >>> htt= ps://www.ietf.org/mailman/listinfo/kitten
> >>
> >>
> >> _______________________________________________=
> >> Kitten mailing list
> >> Kitten@ietf.org
&g= t; >> https://www.ietf.org/mailman/listinfo/kitten
> > <= br>>
>
>
> 
>
> 
>&n= bsp;
>
> _______________________________________________
= > Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.or= g/mailman/listinfo/kitten
>
>



--1458549034-2082713088-1345010317=:37566-- From nico@cryptonector.com Wed Aug 15 09:34:22 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2453F21F8804 for ; Wed, 15 Aug 2012 09:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.191 X-Spam-Level: X-Spam-Status: No, score=-3.191 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij-xtYFc+sMC for ; Wed, 15 Aug 2012 09:34:21 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 94CCD21F87E6 for ; Wed, 15 Aug 2012 09:34:21 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 242A26B007E for ; Wed, 15 Aug 2012 09:34:21 -0700 (PDT) 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; s=cryptonector.com; bh=VitNKi7ZaBmGDYM6ntMK YJSo2hU=; b=iivLDmLfA6MvkMsHUcIfPvTCWyfP/z+Eu+unhqUBEYpzBR6y8UEc MNodxb8B20WvC4DQoVvx0I+N0+iG0eYe4TYNeiUuMpLnZ11iYwXDMrYu/qIP85F/ OWHnhR1whJSvj6jvc9IcSFoUm5w6kmFK2XyG35XQFMAJBSZ2/41vFJs= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 058FB6B007B for ; Wed, 15 Aug 2012 09:34:20 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so48697pbb.31 for ; Wed, 15 Aug 2012 09:34:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.130.67 with SMTP id oc3mr41398926pbb.18.1345048460535; Wed, 15 Aug 2012 09:34:20 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Wed, 15 Aug 2012 09:34:17 -0700 (PDT) In-Reply-To: <5CAFEC4F-3468-4EC8-82AF-31BBCBB085E6@gmx.net> References: <1344706384.36422.YahooMailNeo@web31805.mail.mud.yahoo.com> <1344828671.93823.YahooMailNeo@web31810.mail.mud.yahoo.com> <5CAFEC4F-3468-4EC8-82AF-31BBCBB085E6@gmx.net> Date: Wed, 15 Aug 2012 11:34:17 -0500 Message-ID: From: Nico Williams To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 16:34:22 -0000 On Wed, Aug 15, 2012 at 12:35 AM, Hannes Tschofenig wrote: > (What is not mentioned in the draft is that bearer and the MAC token is equally insecure when using a client that is unable to keep a secret confidential.) The fatal flaw in all of our security protocols is that we assume local security. From a protocol perspective it's not clear how we can possibly do better: given local security we can build network security with relative ease, but we don't know how to do the reverse. So we assume local security. Which means that we can't consider a bearer token system and a "MAC token" system as equivalents. And we should want to have a MAC token, not a bearer token. Nico -- From Hannes.Tschofenig@gmx.net Wed Aug 15 23:50:33 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CBC21F8598 for ; Wed, 15 Aug 2012 23:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.608 X-Spam-Level: X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 euH7QZHNczao for ; Wed, 15 Aug 2012 23:50:32 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 128E321F84D8 for ; Wed, 15 Aug 2012 23:50:31 -0700 (PDT) Received: (qmail invoked by alias); 16 Aug 2012 06:50:30 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp019) with SMTP; 16 Aug 2012 08:50:30 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+xjB8SDW6xaH3UEnUviaGBstceZKTwk5gZSZ/Enm gfP1x+X92s19Oq Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 16 Aug 2012 09:50:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1344706384.36422.YahooMailNeo@web31805.mail.mud.yahoo.com> <1344828671.93823.YahooMailNeo@web31810.mail.mud.yahoo.com> <5CAFEC4F-3468-4EC8-82AF-31BBCBB085E6@gmx.net> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 06:50:33 -0000 I do not believe that the term "equivalent" is appropriate here since = the mechanisms we are discussing provide different security properties. = The question we always had been struggling with was "what are the = desired security properties given certain deployment constraints".=20 I personally do not have a particular preference for one or the other = security mechanisms. I had looked at them and compiled a writeup in = draft-tschofenig-oauth-signature-thoughts-00.txt when the initial = discussions surfaced. What I am not happy with are statements such as "I = like mechanism X" without actually knowing why someone likes it. Even = worse is the case when bogus arguments are being presented. Some folks, = for example, have always been arguing against TLS (because they consider = it broken). While that may be a popular thought it does not help when = the same security mechanism requires TLS to be used between the client = and the authorization server. I would at least demand that the line of = argument is consistent for the entire protocol -- not just for one = communication leg.=20 So, my exercise has been to find out what properties and constraints = people have when they say "I like mechanism X".=20 I hope that this makes sense.=20 =20 > So we assume local security. Which means that we can't consider a > bearer token system and a "MAC token" system as equivalents. And we > should want to have a MAC token, not a bearer token. >=20 > Nico > -- From nico@cryptonector.com Thu Aug 16 00:08:50 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8731B21F8608 for ; Thu, 16 Aug 2012 00:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.177 X-Spam-Level: X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ROAp+mKKTHcI for ; Thu, 16 Aug 2012 00:08:47 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id E697121F85AE for ; Thu, 16 Aug 2012 00:08:47 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 8CA82508069 for ; Thu, 16 Aug 2012 00:08:47 -0700 (PDT) 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=ysq1BM63XwV9tLTOjxejcwme9fo=; b=RCFHJ+fk1ux fOU12ESLyrMv39/lmmsQun1IGoWdPJ6qu9POowcVM8UFI7QevEun2WR00HgmhsnE t80nyBfDY9q4lFGI6jzhb8vySlA1wcJsd9RM0f6udOezEgsIAMfvG0LShRN4oKix EkrR9navLBlGkNjxbDr835dW3ht08qZM= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 71CD5508064 for ; Thu, 16 Aug 2012 00:08:47 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1114940pbb.31 for ; Thu, 16 Aug 2012 00:08:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.222.40 with SMTP id qj8mr1269711pbc.139.1345100927067; Thu, 16 Aug 2012 00:08:47 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Thu, 16 Aug 2012 00:08:46 -0700 (PDT) In-Reply-To: References: <1344706384.36422.YahooMailNeo@web31805.mail.mud.yahoo.com> <1344828671.93823.YahooMailNeo@web31810.mail.mud.yahoo.com> <5CAFEC4F-3468-4EC8-82AF-31BBCBB085E6@gmx.net> Date: Thu, 16 Aug 2012 02:08:46 -0500 Message-ID: From: Nico Williams To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 07:08:50 -0000 On Thu, Aug 16, 2012 at 1:50 AM, Hannes Tschofenig wrote: > I do not believe that the term "equivalent" is appropriate here since the= mechanisms we are discussing provide different security properties. The qu= estion we always had been struggling with was "what are the desired securit= y properties given certain deployment constraints". I said they weren't equivalent. But, at any rate, let's look at properties= : - both bearer tokens and "signature tokens" (let's call them that for argument's sakes) can authenticate a client to a service - bearer tokens cannot authenticate a service to a client, but by using TLS and validating the cert at the token issuer a bearer token system can still authenticate the service to the client; the same applies to signature mechanisms if they use a half round trip - both can do channel binding, though in the case of the bearer token it's practically the same thing as authenticating the server - both can exchange session keys if they should be desired, but bearer tokens can only do this with TLS - bearer tokens *must* be used with TLS, whereas signature tokens can be used with and without TLS (the whole world is not web/HTTP, so this is of some importance) - both require cryptography somewhere; bearer tokens require it in TLS and between the client and the token issuer. Is that about right? I think you could make an argument that bearer tokens are not so bad, but I would argue that they are not so general. Nico -- From Hannes.Tschofenig@gmx.net Thu Aug 16 00:36:57 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B2521F8578 for ; Thu, 16 Aug 2012 00:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 YcrHxh213mx5 for ; Thu, 16 Aug 2012 00:36:57 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9C06921F8575 for ; Thu, 16 Aug 2012 00:36:56 -0700 (PDT) Received: (qmail invoked by alias); 16 Aug 2012 07:36:55 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp012) with SMTP; 16 Aug 2012 09:36:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+TUMt3IluTQNO2qSRy/Wo4c2KmSjiibo7+YB2OYX 4+YvPen0z22BL8 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 16 Aug 2012 10:36:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <20536B9E-EB2A-4534-B570-1B753F8108A4@gmx.net> References: <1344706384.36422.YahooMailNeo@web31805.mail.mud.yahoo.com> <1344828671.93823.YahooMailNeo@web31810.mail.mud.yahoo.com> <5CAFEC4F-3468-4EC8-82AF-31BBCBB085E6@gmx.net> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 07:36:57 -0000 Hi Nico,=20 On Aug 16, 2012, at 10:08 AM, Nico Williams wrote: > On Thu, Aug 16, 2012 at 1:50 AM, Hannes Tschofenig > wrote: >> I do not believe that the term "equivalent" is appropriate here since = the mechanisms we are discussing provide different security properties. = The question we always had been struggling with was "what are the = desired security properties given certain deployment constraints". >=20 > I said they weren't equivalent. But, at any rate, let's look at = properties: The OAuth entities are: client (which may be a Web site, or a = downloadable application, a JavaScript application running in your = browser, etc.) and the resource server. I believe you call the resource = server the "service". Note that we are not at all talking about the = resource owner her (which is the user granting access to the protected = resource).=20 >=20 > - both bearer tokens and "signature tokens" (let's call them that for > argument's sakes) can authenticate a client to a service Actually neither of them authenticates the client to the resource = server. Client authentication is a separate mechanism independent of the = discussed security mechanisms in the spec.=20 >=20 > - bearer tokens cannot authenticate a service to a client, but by > using TLS and validating the cert at the token issuer a bearer token > system can still authenticate the service to the client; the same > applies to signature mechanisms if they use a half round trip >=20 When I talk about "Bearer Tokens" then I refer to the entire = specification rather than about the token itself.=20 As such, I would say that bearer tokens provide authentication of the = resource server to the client via the help of the TLS using PK-based = authentication.=20 > - both can do channel binding, though in the case of the bearer token > it's practically the same thing as authenticating the server If we are talking about the currently defined OAuth mechanisms (and not = about the ideas we toss around in the OAuth SASL spec) then I have to = say that channel binding is not defined for either one of them.=20 With MAC TLS is not used for the client-to-resource server interaction = (but at least theoretically has to be used when obtaining the shared = secret and the token from the authorization server -- even though this = is vaguely specified).=20 With the Bearer Token spec the token is not linked to the underlying TLS = authentication in any way. In fact I believe with existing TLS APIs this = could be quite tricky. =20 >=20 > - both can exchange session keys if they should be desired, but > bearer tokens can only do this with TLS True.=20 >=20 > - bearer tokens *must* be used with TLS, whereas signature tokens can > be used with and without TLS (the whole world is not web/HTTP, so this > is of some importance) Yes, bearer tokens must be used with TLS.=20 TLS is not only used in the Web. >=20 > - both require cryptography somewhere; bearer tokens require it in > TLS and between the client and the token issuer. >=20 Bearer tokens require TLS between the client and the authorization = server (to obtain the token) and between the client and the resource = server (when presenting the token).=20 MAC tokens require (in my opinion - but not in the spec) TLS between the = client and the resource server (to obtain the token and the shared = secret) but not between the client and the resource server (unless = confidentiality protection, integrity protection of the entire message = exchange, or server-side authentication is a desire). Then, there is = also the step where the shared secret needs to travel from the = authorization server and the resource server. When you replace the terms = s/authorization server/identity provider and s/resource server/relying = party then you may see the need to have a solution for cross domain = communication.=20 > Is that about right? I think you could make an argument that bearer > tokens are not so bad, but I would argue that they are not so general. Yes, about right.=20 Ciao Hannes >=20 > Nico > -- From hannes.tschofenig@gmx.net Thu Aug 16 02:57:26 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB3421F861E for ; Thu, 16 Aug 2012 02:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 24Zkr4J9YdMN for ; Thu, 16 Aug 2012 02:57:25 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5A00921F8610 for ; Thu, 16 Aug 2012 02:57:25 -0700 (PDT) Received: (qmail invoked by alias); 16 Aug 2012 09:57:23 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp017) with SMTP; 16 Aug 2012 11:57:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18TIKBB/vETbFb4xRZLcMTIr67GwhdVNW7utaXxA6 tvuzMpwmE2Fr1R From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Aug 2012 12:54:21 +0300 Message-Id: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> To: kitten@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 09:57:26 -0000 Hi all,=20 given the discussions on the list about the OAuth SASL mechanism I = thought I would summarize my conclusions so far. The current SASL OAuth specification offers a range of different = security mechanisms, namely=20 * OAuth 1.0 MAC Token * OAuth 2.0 Bearer Token (On top of that there is the channel binding support as well).=20 Of course it would be desirable to only have a single mechanism (or at = least using the same foundation, such as OAuth 2.0) but the security = properties of the two mechanisms seem to attract different groups. Bill = definitely feels that MAC tokens are more secure than Bearer Tokens and = he needs them for his use cases.=20 In some sense the desire to have mechanisms with different properties = shouldn't be all that surprising given that motivated the concept of = authentication frameworks (like SASL, EAP, and GSS-API) altogether.=20 Luckily, there is a built-in mechanism for negotiation between the SASL = endpoints. The discovery mechanism to be used for the interaction with = the authorization server has, unfortunately, not yet been standardized.=20= I do not want to convince Bill that the Bearer Token mechanism is the = only security mechanism he needs for his use cases. I even believe that = we should extend the OAuth SASL specification as we make progress in the = OAuth WG.=20 Having said that I still appreciate any feedback, like the recent = comment from Nico, that helps us making progress in the OAuth security = discussions.=20 Ciao Hannes From nico@cryptonector.com Thu Aug 16 07:48:39 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB4C21F85AD for ; Thu, 16 Aug 2012 07:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 FnASxAgKc28T for ; Thu, 16 Aug 2012 07:48:38 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 73F2221F8550 for ; Thu, 16 Aug 2012 07:48:38 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 0FB3C598058 for ; Thu, 16 Aug 2012 07:48:38 -0700 (PDT) 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; s=cryptonector.com; bh=hJCTLybAIScIotUYnVsv cXLswNY=; b=KF6Al/sl003QA3n/a2vquLsUA7qxmoUaRIB4NHpCq++Yem1RQWya KyyPGJl/esGfEWxKBEo1z50JjPdlB8n6BTjNY5cioZVw9RREnMdTEm0NaSkcmRoK CAdqqr4vTHD66rjMYG/yyVKWSig/pUvxKP8mjAx1AZuzvtPYxIQYOSA= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id EF131598055 for ; Thu, 16 Aug 2012 07:48:37 -0700 (PDT) Received: by dakr19 with SMTP id r19so489285dak.31 for ; Thu, 16 Aug 2012 07:48:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.197.228 with SMTP id ix4mr3925877pbc.40.1345128202797; Thu, 16 Aug 2012 07:43:22 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Thu, 16 Aug 2012 07:43:22 -0700 (PDT) In-Reply-To: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> Date: Thu, 16 Aug 2012 09:43:22 -0500 Message-ID: From: Nico Williams To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 14:48:39 -0000 On Thu, Aug 16, 2012 at 4:54 AM, Hannes Tschofenig wrote: > In some sense the desire to have mechanisms with different properties shouldn't be all that surprising given that motivated the concept of authentication frameworks (like SASL, EAP, and GSS-API) altogether. I would say it's not about the framework but about the applications that might use these mechanisms. Not all are web/HTTP apps, nor are all apps that use or can use TLS either. No TLS almost implies no bearer tokens. Nico -- From nico@cryptonector.com Thu Aug 16 08:03:44 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFC121F852A for ; Thu, 16 Aug 2012 08:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.152 X-Spam-Level: X-Spam-Status: No, score=-3.152 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 aS+TQUnF3Vly for ; Thu, 16 Aug 2012 08:03:43 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 82F2521F8494 for ; Thu, 16 Aug 2012 08:03:43 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id CA7BB264079 for ; Thu, 16 Aug 2012 08:03:42 -0700 (PDT) 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=1tnqyDrci7JsGtlDUID8BfC5bT0=; b=CJdw7ic7B4Q s2mM+aAO3Lg46npofBv3RuvOcw8p4xNUzs4ac6lj2VXrhBzC9/f+NXd2Sr7A+8kC GGqP8fSy92IqhiR5MZCncSbNSWNHwwLBzCulDnZtzhv/EAtRaDXn4x0MBmpkyGWs BOnRnzj9Uen+86dJYK/8rpEunlo6ggnc= Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 988F126406A for ; Thu, 16 Aug 2012 08:03:42 -0700 (PDT) Received: by ggnh4 with SMTP id h4so3294404ggn.31 for ; Thu, 16 Aug 2012 08:03:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.167 with SMTP id if7mr3995048pbc.50.1345129421545; Thu, 16 Aug 2012 08:03:41 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Thu, 16 Aug 2012 08:03:41 -0700 (PDT) In-Reply-To: <20536B9E-EB2A-4534-B570-1B753F8108A4@gmx.net> References: <1344706384.36422.YahooMailNeo@web31805.mail.mud.yahoo.com> <1344828671.93823.YahooMailNeo@web31810.mail.mud.yahoo.com> <5CAFEC4F-3468-4EC8-82AF-31BBCBB085E6@gmx.net> <20536B9E-EB2A-4534-B570-1B753F8108A4@gmx.net> Date: Thu, 16 Aug 2012 10:03:41 -0500 Message-ID: From: Nico Williams To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 15:03:44 -0000 On Thu, Aug 16, 2012 at 2:36 AM, Hannes Tschofenig wrote: > On Aug 16, 2012, at 10:08 AM, Nico Williams wrote: >> On Thu, Aug 16, 2012 at 1:50 AM, Hannes Tschofenig >> wrote: >>> I do not believe that the term "equivalent" is appropriate here since t= he mechanisms we are discussing provide different security properties. The = question we always had been struggling with was "what are the desired secur= ity properties given certain deployment constraints". >> >> I said they weren't equivalent. But, at any rate, let's look at propert= ies: > > The OAuth entities are: client (which may be a Web site, or a downloadabl= e application, a JavaScript application running in your browser, etc.) and = the resource server. I believe you call the resource server the "service". = Note that we are not at all talking about the resource owner her (which is = the user granting access to the protected resource). I was trying to address bearer vs. not-beader token mechanisms in general, not OAuth specifically. >> - both bearer tokens and "signature tokens" (let's call them that for >> argument's sakes) can authenticate a client to a service > > Actually neither of them authenticates the client to the resource server.= Client authentication is a separate mechanism independent of the discussed= security mechanisms in the spec. See above. They authenticate something. Whether that something be an assertion of identity or an assertion of access to resources. >> - bearer tokens cannot authenticate a service to a client, but by >> using TLS and validating the cert at the token issuer a bearer token >> system can still authenticate the service to the client; the same >> applies to signature mechanisms if they use a half round trip > > When I talk about "Bearer Tokens" then I refer to the entire specificatio= n rather than about the token itself. > > As such, I would say that bearer tokens provide authentication of the res= ource server to the client via the help of the TLS using PK-based authentic= ation. In particular it's very difficult for bearer token systems to do better than the TLS PKI for server authentication. Scott talked about how it can be done, but I'm skeptical. This, and the requirement for transport security being up before the token is sent, are the biggest problems with bearer tokens IMO. ... >> - bearer tokens *must* be used with TLS, whereas signature tokens can >> be used with and without TLS (the whole world is not web/HTTP, so this >> is of some importance) > > Yes, bearer tokens must be used with TLS. > TLS is not only used in the Web. More importantly: TLS is not used in every application protocol. Examples where it's not used: - SSHv2 - NFSv4 (and all ONC RPC apps) - AFS (and all rx apps) - SMB - all MSRPC apps - DNS updates >> - both require cryptography somewhere; bearer tokens require it in >> TLS and between the client and the token issuer. >> > Bearer tokens require TLS between the client and the authorization server= (to obtain the token) and between the client and the resource server (when= presenting the token). > > MAC tokens require (in my opinion - but not in the spec) TLS between the = client and the resource server (to obtain the token and the shared secret) = but not between the client and the resource server (unless confidentiality = protection, integrity protection of the entire message exchange, or server-= side authentication is a desire). Then, there is also the step where the sh= ared secret needs to travel from the authorization server and the resource = server. When you replace the terms s/authorization server/identity provider= and s/resource server/relying party then you may see the need to have a so= lution for cross domain communication. That step can be Needham-Schroeder-like (i.e., like Kerberos). >> Is that about right? I think you could make an argument that bearer >> tokens are not so bad, but I would argue that they are not so general. > Yes, about right. Maybe we should write this down somewhere. Nico -- From cantor.2@osu.edu Thu Aug 16 08:09:28 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6EF21F85BB for ; Thu, 16 Aug 2012 08:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 RYoRGCjhIBNc for ; Thu, 16 Aug 2012 08:09:28 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id CCECF21F85AC for ; Thu, 16 Aug 2012 08:09:27 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7GF8vEl023886; Thu, 16 Aug 2012 11:09:21 -0400 Received: from CIO-TNC-HT07.osuad.osu.edu (164.107.81.174) by CIO-KRC-HT02.osuad.osu.edu (164.107.81.40) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 16 Aug 2012 11:08:55 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.02.0309.002; Thu, 16 Aug 2012 11:08:55 -0400 From: "Cantor, Scott" To: Nico Williams , Hannes Tschofenig Thread-Topic: [kitten] OAUTH SASL and Channel binding Thread-Index: AQHNe8BSHGdoCl4WY0+O4QBdMhqIS5dcipsA Date: Thu, 16 Aug 2012 15:08:53 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <3FBE5C6513FAA24496BE99526C72F984@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 15:09:28 -0000 On 8/16/12 11:03 AM, "Nico Williams" wrote: > >In particular it's very difficult for bearer token systems to do >better than the TLS PKI for server authentication. Scott talked about >how it can be done, but I'm skeptical. This, and the requirement for >transport security being up before the token is sent, are the biggest >problems with bearer tokens IMO. Something apropos of this that addresses something Hannes mentioned: while it is true that you may still need TLS on the other traffic legs even if you do holder of key tokens, that leg between the client and the authorization server (in OAuth terms) or in the case of SAML, the IdP, is a much more restricted set of systems which you have to provision into the client somehow anyway (unless you're just ignoring phishing). In other words, it's more tractable to address that TLS leg in a more advanced manner than it is to try and fix all the TLS usage between the client and the relying parties, of which there are more, and which have no general relationship to the user. -- Scott From nico@cryptonector.com Thu Aug 16 08:40:09 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB0921F84BF for ; Thu, 16 Aug 2012 08:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 y8gmsxv73500 for ; Thu, 16 Aug 2012 08:40:08 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id B6ECB21F84A7 for ; Thu, 16 Aug 2012 08:40:08 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 83BB72C806E for ; Thu, 16 Aug 2012 08:40:08 -0700 (PDT) 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; s=cryptonector.com; bh=zXNsjP2AARN7MYsxHaZO 3WKz7yg=; b=GO0nRvptes6O4sP9IKV5wiDQUQbv9FTzxNq9hKSs5lA7Qpreb9et M7lc6QYC0HMF1mPnAAoM8rsNEYQXhYZDFjQks0XdpPlw6d3cFu1pS6kzyIjriMnp Wf4eZUpV36i4cb+5j3z24LEbHCLDA5K2gwP7gKhqlkfQE65vOYucbLg= Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 5CFAA2C806C for ; Thu, 16 Aug 2012 08:40:08 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3340119ghb.31 for ; Thu, 16 Aug 2012 08:40:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.197.202 with SMTP id iw10mr3935803pbc.161.1345131607518; Thu, 16 Aug 2012 08:40:07 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Thu, 16 Aug 2012 08:40:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Aug 2012 10:40:07 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 15:40:09 -0000 On Thu, Aug 16, 2012 at 10:08 AM, Cantor, Scott wrote: > On 8/16/12 11:03 AM, "Nico Williams" wrote: >> >>In particular it's very difficult for bearer token systems to do >>better than the TLS PKI for server authentication. Scott talked about >>how it can be done, but I'm skeptical. This, and the requirement for >>transport security being up before the token is sent, are the biggest >>problems with bearer tokens IMO. > > Something apropos of this that addresses something Hannes mentioned: while > it is true that you may still need TLS on the other traffic legs even if > you do holder of key tokens, that leg between the client and the > authorization server (in OAuth terms) or in the case of SAML, the IdP, is > a much more restricted set of systems which you have to provision into the > client somehow anyway (unless you're just ignoring phishing). Indeed, but that's not the leg I'm worried about. Nico -- From hannes.tschofenig@gmx.net Thu Aug 16 08:56:36 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C7621F8464 for ; Thu, 16 Aug 2012 08:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5A6fw2GbNzNH for ; Thu, 16 Aug 2012 08:56:36 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9305521F8555 for ; Thu, 16 Aug 2012 08:56:35 -0700 (PDT) Received: (qmail invoked by alias); 16 Aug 2012 15:56:33 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp040) with SMTP; 16 Aug 2012 17:56:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+XqI93hD6XxGNumKe8kWUZUqVeUjBaQAM+hqyQsh fM+syQAyziEPF4 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 16 Aug 2012 18:56:32 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: kitten@ietf.org Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 15:56:36 -0000 Hi Nico,=20 On Aug 16, 2012, at 5:43 PM, Nico Williams wrote: > On Thu, Aug 16, 2012 at 4:54 AM, Hannes Tschofenig > wrote: >> In some sense the desire to have mechanisms with different properties = shouldn't be all that surprising given that motivated the concept of = authentication frameworks (like SASL, EAP, and GSS-API) altogether. >=20 > I would say it's not about the framework but about the applications > that might use these mechanisms. Not all are web/HTTP apps, nor are > all apps that use or can use TLS either. No TLS almost implies no > bearer tokens. I agree with you. For applications that cannot use TLS (or DTLS) bearer tokens are not = usable. Ciao Hannes >=20 > Nico > -- From wmills@yahoo-inc.com Thu Aug 16 09:01:43 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBFC21F8523 for ; Thu, 16 Aug 2012 09:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.523 X-Spam-Level: X-Spam-Status: No, score=-17.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 ulcKjHnopMLm for ; Thu, 16 Aug 2012 09:01:42 -0700 (PDT) Received: from nm12.bullet.mail.sp2.yahoo.com (nm12.bullet.mail.sp2.yahoo.com [98.139.91.82]) by ietfa.amsl.com (Postfix) with SMTP id BA32121F853D for ; Thu, 16 Aug 2012 09:01:42 -0700 (PDT) Received: from [72.30.22.92] by nm12.bullet.mail.sp2.yahoo.com with NNFMP; 16 Aug 2012 16:01:40 -0000 Received: from [98.139.91.60] by tm14.bullet.mail.sp2.yahoo.com with NNFMP; 16 Aug 2012 16:01:40 -0000 Received: from [127.0.0.1] by omp1060.mail.sp2.yahoo.com with NNFMP; 16 Aug 2012 16:01:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 151167.72373.bm@omp1060.mail.sp2.yahoo.com Received: (qmail 5349 invoked by uid 60001); 16 Aug 2012 16:01:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345132899; bh=DQTt2KQrZSzsuI8+3WzCuK3n0UukdzPWOFQt2xQLuJ8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=okb1hVRQdufPDBRfDo8jK9pWDVPVhYNVU45gQv9htJLwqjoydgTYhNfLOqC5TRrPWZaUjsoFb0fm2cUas4ly2mAJt/nDEDeXf3VgLc1Q+GfU3D2ATXfzJSS1zlA+6WBQxCmQAnHdu7V96KjVam4JXGzrfCB8NLoX/0ihiaUT1PY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SoBVzsgA1fvuPv1DIQLw8PuRnHeiJA2yVDdrcEnGa70HdAMEQkbhIZU6ITf3OmTD8aj6lS20o1O/IFn1ccWu+EtKWfEqUZgNiq5rCVtbXs8fn8263Xg6PVvnjTUXWH0vlcq4sJ+cjLZGbrptuMID/a0ql53JlgQYMTiySyS2fp4=; X-YMail-OSG: WYC40WwVM1m1vjNmjftr4xHkbyUO2pZrtvO8FEljAXyn7lE vzxeatJsBOykKTrJWHAgSHbNGKhgbxSZJ0APeT4Yz4kEDaFKxHhATYrefxlt 5vFXIsgeUR9z300TpX1TIyw3istqnWe5iBShSk4XPPUevYgFrhBhUJlJ4txc xDelKUU33vI7ws7Ngf9Y7IuSWDJ4MdZxx2NNgc.HxWRbol7sK40M9Dh25JpN nRwutWgJU1_lMZLC0mbckwlvWkr3RTK3R8sLXduXnp.bp8Kz7sewV.BOKxPl ghnFUeEMSzXs_E0zq8mLKcp6xJP.4dwUre3GU1nmQJnNEozehF6plhsx16jk vUk1p5DVnUxYv7v7llV_iBSn36azA8bZ2GCcUlUEsnLWHJJUFa76YgEXGYwc 0hTm99I_XSLnVgTCQE3WJmtblJD6laZCRmtKSzgefhIaN Received: from [99.31.212.42] by web31806.mail.mud.yahoo.com via HTTP; Thu, 16 Aug 2012 09:01:39 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> <87hasbd4yq.fsf@latte.josefsson.org> Message-ID: <1345132899.4152.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Thu, 16 Aug 2012 09:01:39 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87hasbd4yq.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-805757131-1345132899=:4152" Cc: "kitten@ietf.org" Subject: [kitten] Channel binding language changes Re: Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:01:43 -0000 ---1055047407-805757131-1345132899=:4152 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Simon,=0A=0AOn the channel binding stuff I changed the language to refer to= the definition in the channel binding spec:=0A=0A=A0=A0=A0 The channel bin= ding payload is the raw data from the channel binding=0A=A0=A0=A0 type. Fo= r example, if the client is using tls-unique for channel binding then =0A= =A0=A0=A0 the raw channel binding data is the TLS finished message as speci= fied in section =0A=0A=A0=A0=A0 3.1 of =0A=0AI al= so struck the concept entirely of hashing the channel binding payload if it= 's large. =0A=0A=0A-bill=0A=0A=0A=0A=0A=0A=0A>_____________________________= ___=0A> From: Simon Josefsson =0A>To: William Mills =0A>Cc: Ryan Troll ; "kitten@ietf= .org" =0A>Sent: Thursday, August 9, 2012 4:24 PM=0A>Subje= ct: Re: Status of draft-ietf-kitten-sasl-oauth?=0A> =0A>William Mills writes:=0A>=0A>> There hasn't been a lot of action in any= substantive way on the list=0A>> on this draft, and I think it's pretty we= ll baked.=A0 A working=0A>> implementation is going to go a long way to nai= ling this down.=0A>>=0A>> Anyone out there with any significant objections = or proposed should=0A>> speak up "real soon now".=A0=0A>=0A>I have reviewed= the -03 document, and I believe there are some major=0A>issues with it.=0A= >=0A>MAJOR:=0A>=0A>* The protocol does not appear to be compatible with the= GS2 framing,=0A>=A0 thus the GSS-API mechanism the document defines would = not be=0A>=A0 wire-compatible with the SASL mechanism.=A0 The SASL packets = needs to=0A>=A0 use the GS2 header to be compatible.=A0 The examples reinfo= rces my=0A>=A0 readings, they don't begin with the GS2 header.=A0 Compare t= he SCRAM,=0A>=A0 OPENID and SAML20 mechanism to see how this should be done= .=0A>=0A>* I don't see where the mechanism transfers the SASL authorization= =0A>=A0 identity, which is required.=A0 This would be done by the GS2 heade= r.=0A>=0A>* I don't follow how the channel binding data is integrity protec= ted.=0A>=A0 Unless I'm missing some keying, this seems to open up for a MIT= M to=0A>=A0 fake channel binding.=A0 Section 3.2:=0A>=0A>=A0 =A0 In the OAU= TH-PLUS mechanism the server examines the channel binding=0A>=A0 =A0 data, = extracts the channel binding unique prefix, and extracts the=0A>=A0 =A0 raw= channel biding data based on the channel binding type used.=A0 It=0A>=A0 = =A0 then computes it's own copy of the channel binding payload and=0A>=A0 = =A0 compares that to the payload sent by the client in the cbdata key/=0A>= =A0 =A0 value.=A0 Those two must be equal for channel binding to succeed.= =0A>=0A>=A0 Presumably the client is not authenticated when this is sent, s= o the=0A>=A0 server might as well be talking to an attacker, which sends it= s own=0A>=A0 channel binding data.=0A>=0A>=A0 I'm not sure I see how OAuth = with bearer tokens could support channel=0A>=A0 bindings at all?=0A>=0A>* S= ection 3.4 seems confusing.=A0 Quoting:=0A>=0A>=A0 =A0 If the specification= for the underlying authorization scheme requires=0A>=A0 =A0 a security lay= er, such as TLS [RFC5246], the server SHOULD only offer=0A>=A0 =A0 a mechan= ism where channel binding can be enabled.=0A>=0A>=A0 Should "authorization = scheme" be "application protocol"?=0A>=0A>=A0 Quoting further:=0A>=0A>=A0 = =A0 The channel binding data is computed by the client based on it's=0A>=A0= =A0 choice of preferred channel binding type.=0A>=0A>=A0 I think you want = something similar to section 5.2 in RFC 5802 instead,=0A>=A0 to leave the c= hoise of preferred channel binding type up to the=0A>=A0 application protoc= ol profile (or resume back to a default).=0A>=0A>=A0 =A0 If the raw channel= binding data is 500=0A>=A0 =A0 bytes or larger then a SHA-1 [RFC3174] hash= of the raw channel=0A>=A0 =A0 binding data is computed.=0A>=0A>=A0 SHA-1?= =A0 This opens up for hash agility concerns.=0A>=0A>=A0 =A0 If the client i= s using tls-unique for a channel binding then the raw=0A>=A0 =A0 channel bi= nding data equals the first TLS finished message.=0A>=0A>=A0 There is subtl= ety with renegotiation here, I suggest to quote RFC 5929=0A>=A0 instead.=0A= >=0A>/Simon=0A>=0A>=0A> ---1055047407-805757131-1345132899=:4152 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Simon,
On the channel binding stuff I changed the language to refer to the de= finition in the channel binding spec:

 &nbs= p;  The channel binding payload is the raw data from the channe= l binding=0A
    type. For example, if the client is using t= ls-unique for channel binding then
=0A
    the raw chan= nel binding data is the TLS finished message as specified in section
=0A
=     3.1 of <xref target=3D"RFC5056"/>

I also struck the concept entirely of ha= shing the channel binding payload if it's large.

-bill



<= div dir=3D"ltr">
From: Simon Josefsson <simon@jos= efsson.org>
To: Wil= liam Mills <wmills@yahoo-inc.com>
Cc: Ryan Troll <rtroll@googlers.com>; "kitten@ietf.= org" <kitten@ietf.org>
Sen= t: Thursday, August 9, 2012 4:24 PM
Subject: Re: Status of draft-ietf-kitten-sasl-oauth?

William Mills <wmills@yahoo-inc.com> writes:
> There hasn't been a lot of action in any substantive way on the l= ist
> on this draft, and I think it's pretty well baked.  A work= ing
> implementation is going to go a long way to nailing this down.<= br>>
> Anyone out there with any significant objections or propose= d should
> speak up "real soon now". 

I have reviewed the= -03 document, and I believe there are some major
issues with it.
MAJOR:

* The protocol does not appear to be compatible with the GS2= framing,
  thus the GSS-API mechanism the document defines would n= ot be
  wire-compatible with the SASL mechanism.  The SASL packets needs to
  use the GS2 header to be compatible.  The = examples reinforces my
  readings, they don't begin with the GS2 he= ader.  Compare the SCRAM,
  OPENID and SAML20 mechanism to see= how this should be done.

* I don't see where the mechanism transfer= s the SASL authorization
  identity, which is required.  This = would be done by the GS2 header.

* I don't follow how the channel bi= nding data is integrity protected.
  Unless I'm missing some keying= , this seems to open up for a MITM to
  fake channel binding. = Section 3.2:

    In the OAUTH-PLUS mechanism the server e= xamines the channel binding
    data, extracts the channel bin= ding unique prefix, and extracts the
    raw channel biding da= ta based on the channel binding type used.  It
    then c= omputes it's own copy of the channel binding payload and
    compares that to the payload sent by the client in the cbdata key/<= br>    value.  Those two must be equal for channel binding t= o succeed.

  Presumably the client is not authenticated when th= is is sent, so the
  server might as well be talking to an attacker= , which sends its own
  channel binding data.

  I'm not= sure I see how OAuth with bearer tokens could support channel
  bi= ndings at all?

* Section 3.4 seems confusing.  Quoting:

=     If the specification for the underlying authorization scheme = requires
    a security layer, such as TLS [RFC5246], the serv= er SHOULD only offer
    a mechanism where channel binding can= be enabled.

  Should "authorization scheme" be "application pr= otocol"?

  Quoting further:

    The channel bi= nding data is computed by the client based on it's
    choice of preferred channel binding type.

  I think you want s= omething similar to section 5.2 in RFC 5802 instead,
  to leave the= choise of preferred channel binding type up to the
  application p= rotocol profile (or resume back to a default).

    If the = raw channel binding data is 500
    bytes or larger then a SHA= -1 [RFC3174] hash of the raw channel
    binding data is compu= ted.

  SHA-1?  This opens up for hash agility concerns.
    If the client is using tls-unique for a channel binding = then the raw
    channel binding data equals the first TLS fin= ished message.

  There is subtlety with renegotiation here, I s= uggest to quote RFC 5929
  instead.

/Simon


---1055047407-805757131-1345132899=:4152-- From wmills@yahoo-inc.com Thu Aug 16 09:20:19 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4442A21F847A for ; Thu, 16 Aug 2012 09:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.532 X-Spam-Level: X-Spam-Status: No, score=-17.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 2kqNEZzh18AL for ; Thu, 16 Aug 2012 09:20:18 -0700 (PDT) Received: from nm30-vm2.bullet.mail.ne1.yahoo.com (nm30-vm2.bullet.mail.ne1.yahoo.com [98.138.91.130]) by ietfa.amsl.com (Postfix) with SMTP id 56A1E21F8476 for ; Thu, 16 Aug 2012 09:20:18 -0700 (PDT) Received: from [98.138.90.56] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 16 Aug 2012 16:20:12 -0000 Received: from [98.138.89.193] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 16 Aug 2012 16:20:12 -0000 Received: from [127.0.0.1] by omp1051.mail.ne1.yahoo.com with NNFMP; 16 Aug 2012 16:20:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 639144.79078.bm@omp1051.mail.ne1.yahoo.com Received: (qmail 79131 invoked by uid 60001); 16 Aug 2012 16:20:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345134012; bh=v56lB0t+a1+K8+0XsghQ10487YTvVq0vOxjuse4CAXI=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=h1rkd785oANl6pVxsumuZnB11YPLz6Q3rVXmyM3MdVhxcDa0boa9e8mlD/DtKTmTLftjyf6mUYFohzY4oGPnb+4IfTehl1ES188mOLWHj+VXeCDFqTUQQWRb+vGJbg0yp2h/qGJAaVENyGtji80bENCOHp7zNG4y3zsNrLBZZ04= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mfm+L0ZqXqpc/aYhZjGw9j3IumnI4GcrLi8vNvhSp7obzYy7ecDu3FtE8YfDOnI4JLFLRTFst9ul3s1rxUPLV/ysWbZa/7al70briXdJrDldb1iJ6bC39Q6DJj5tc8PtVKCUzGUxXj8LV7ZTsE7RZz4Wk37B6OqzFg9ntYluNZA=; X-YMail-OSG: d4aVVswVM1kAkT0Zt6yiICDuQKhctd46tB3bnPG_D8NPddy hpu0CpIdIBveb_XCLu6DT1ZbD5EJF4smUBce_2YiyoHImvaB7O.u6cqrA.YL _.E2.PM.xvmE8W8Ifs4GsQg0jCiTHNG72X47VLycgvSCn08UViktJSkKlxJz dhjJ9T0yQSn4ZjZk0ZdctaV2YVfY0ZZ3JKfrx5FLl5bKz7wGJUKntVmgY9MR vQrLs6pZaLVNbujfVsAlab_UJbag2puAoWRekk94DjjFklJDdCkuI5c4ecfa .RSh8FbyU9ZxNh6zuFnL_XYhNsLAi3uIUvR7fygR04dkl8LcAI4LOMfkcM2r p5w3es8Ampq.XrXnUJO3kcojLmPRqiyWHb7BCJAYz8VMWiT_z8ACd75RhDzY _kSM6bZG24Hukdb6oEod5ZOa3i4uxhM3.9QDl6UH6.OE- Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Thu, 16 Aug 2012 09:20:11 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> Message-ID: <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Thu, 16 Aug 2012 09:20:11 -0700 (PDT) From: William Mills To: Hannes Tschofenig , Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-1649064423-1345134011=:76328" Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:20:19 -0000 --764183289-1649064423-1345134011=:76328 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable While I agree with you form a security stance, I must point out that FB was= using bearer tokens in the clear for about a year I think until the rolled= out HTTPS.=A0 People will in fact make that choice, just as they use cooki= es for authorization in the clear.=0A=0A=0A=0A=0A=0A>______________________= __________=0A> From: Hannes Tschofenig =0A>To: N= ico Williams =0A>Cc: kitten@ietf.org =0A>Sent: Thur= sday, August 16, 2012 8:56 AM=0A>Subject: Re: [kitten] SASL OAuth - My Conc= lusion So Far=0A> =0A>Hi Nico, =0A>=0A>On Aug 16, 2012, at 5:43 PM, Nico Wi= lliams wrote:=0A>=0A>> On Thu, Aug 16, 2012 at 4:54 AM, Hannes Tschofenig= =0A>> wrote:=0A>>> In some sense the desire to = have mechanisms with different properties shouldn't be all that surprising = given that motivated the concept of authentication frameworks (like SASL, E= AP, and GSS-API) altogether.=0A>> =0A>> I would say it's not about the fram= ework but about the applications=0A>> that might use these mechanisms.=A0 N= ot all are web/HTTP apps, nor are=0A>> all apps that use or can use TLS eit= her.=A0 No TLS almost implies no=0A>> bearer tokens.=0A>=0A>I=A0 agree with= you.=0A>=0A>For applications that cannot use TLS (or DTLS) bearer tokens a= re not usable.=0A>=0A>Ciao=0A>Hannes=0A>=0A>> =0A>> Nico=0A>> --=0A>=0A>___= ____________________________________________=0A>Kitten mailing list=0A>Kitt= en@ietf.org=0A>https://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> --764183289-1649064423-1345134011=:76328 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
While I a= gree with you form a security stance, I must point out that FB was using be= arer tokens in the clear for about a year I think until the rolled out HTTP= S.  People will in fact make that choice, just as they use cookies for= authorization in the clear.


<= div dir=3D"ltr">
From: Hannes Tschofenig <hannes.= tschofenig@gmx.net>
To:= Nico Williams <nico@cryptonector.com>
Cc: kitten@ietf.org
Sent: Thursday, August 16, 2012 8:56 AM
Subject: Re: [kitten] SASL OAuth - My Co= nclusion So Far

Hi Nico,

On Aug 16, 2012, at= 5:43 PM, Nico Williams wrote:

> On Thu, Aug 16, 2012 at 4:54 AM,= Hannes Tschofenig
> <hannes.tschofenig@gmx.net= > wrote:
>> In some sense the desire to have mechanisms with di= fferent properties shouldn't be all that surprising given that motivated th= e concept of authentication frameworks (like SASL, EAP, and GSS-API) altoge= ther.
>
> I would say it's not about the framework but about t= he applications
> that might use these mechanisms.  Not all are web/HTTP apps, nor are
> all apps that use or can use TLS either.&nb= sp; No TLS almost implies no
> bearer tokens.

I  agree wi= th you.

For applications that cannot use TLS (or DTLS) bearer tokens= are not usable.

Ciao
Hannes

>
> Nico
> --=

_______________________________________________
Kitten mailing l= ist
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

--764183289-1649064423-1345134011=:76328-- From nico@cryptonector.com Thu Aug 16 09:20:37 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E64F21F84D7 for ; Thu, 16 Aug 2012 09:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.128 X-Spam-Level: X-Spam-Status: No, score=-3.128 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 3TxzFLRaKOdD for ; Thu, 16 Aug 2012 09:20:37 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 86E4D21F84D5 for ; Thu, 16 Aug 2012 09:20:36 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 2258D1B4059 for ; Thu, 16 Aug 2012 09:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=rho1hy+g/SNDK1Z7C/x3oBJohMk=; b=jWdddMFaLRM dkE3aTVL4ryqUBAGfB1agW3soEz2kXG/D2YR8dBkY+HZkEQ4+QNetCjYmkuQo9Xu hjumnHJPTsR4t7XYW1vTon8JcpJC3PpZWsVBclAVRo+9U1V47KsUk+yNR3LRhjHe uJhbICs/rKpnn4Hkmd6Mrj4YqjPeqYbQ= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 089111B4058 for ; Thu, 16 Aug 2012 09:20:35 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1825180pbb.31 for ; Thu, 16 Aug 2012 09:20:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.41 with SMTP id or9mr4274911pbb.115.1345134035580; Thu, 16 Aug 2012 09:20:35 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Thu, 16 Aug 2012 09:20:35 -0700 (PDT) Date: Thu, 16 Aug 2012 11:20:35 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] Bearer vs. non-bearer (Re: OAUTH SASL and Channel binding) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:20:37 -0000 FWIW, I seethe appeal of bearer tokens. If you trust the TLS server PKI then bearer tokens can be implemented with no changes to the HTTP/TLS stack and *no additional crypto* on the client side. Heck, it's even possible to implement bearer token schemes with no additional crypto anywhere. This sounds too wonderful too be true, but it is true, no? But once you're stuck with a bearer token you're also stuck with either trusting the TLS server PKI fully, or making changes to the HTTP/TLS stack. That seems like an awful bind to me. So, in principle bearer and signature tokens can both offer reasonable security (if one adheres to their respective security considerations). In practice there are differences, which I hope I captured succinctly enough above. I believe the downside of bearer tokens overwhelm the upside -- a proposition that no doubt requires more discussion. Nico -- From nico@cryptonector.com Thu Aug 16 10:21:57 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC5321F866A for ; Thu, 16 Aug 2012 10:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.116 X-Spam-Level: X-Spam-Status: No, score=-3.116 tagged_above=-999 required=5 tests=[AWL=-1.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 zUyqYE-sJWwd for ; Thu, 16 Aug 2012 10:21:56 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 60EB321F85C7 for ; Thu, 16 Aug 2012 10:21:54 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id D66DF76806C for ; Thu, 16 Aug 2012 10:21:53 -0700 (PDT) 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; s=cryptonector.com; bh=FoCoW417bgvjqec3okAR K3JkI9M=; b=dToVvQUfv3P34fkjpvomgKgP2Eox5id8wjJvQt8dQ/jPLvjpdVhk UkgSJ+JLqfjWUSfCkGSkLY6q1Z3UG3EroCs7sxxaemIHWppe3HtKwEYJjDUoun9F JI01/kzU7GXcxlez2rFDHtNE5PcRnMY5dxVnCF8MMjf80EgPuXdmTAg= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id B8F0776805C for ; Thu, 16 Aug 2012 10:21:53 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1897563pbb.31 for ; Thu, 16 Aug 2012 10:21:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.41 with SMTP id or9mr4690870pbb.115.1345137713331; Thu, 16 Aug 2012 10:21:53 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Thu, 16 Aug 2012 10:21:53 -0700 (PDT) In-Reply-To: <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Thu, 16 Aug 2012 12:21:53 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:21:57 -0000 On Thu, Aug 16, 2012 at 11:20 AM, William Mills wrote: > While I agree with you form a security stance, I must point out that FB was > using bearer tokens in the clear for about a year I think until the rolled > out HTTPS. People will in fact make that choice, just as they use cookies > for authorization in the clear. Cookies themselves are a form of bearer token, but at least one can set different cookies for use with HTTP vs. HTTPS. Bearer tokens are too valuable to send without using TLS. A signature token is far more secure in the absence of TLS, but if you'll use HTTP and cookies w/o TLS at all then your sessions can still be hijacked, in which case bearer or signature makes little difference. For me the main thing is that bearer tokens simply have no useful existence w/o TLS or equivalent, which means they are not applicable to a non-trivial class of application protocols. I.e., bearer tokens are less general. There's also the problem that bearer tokens cannot improve server authentication without rototilling the HTTP/TLS stacks. Nico -- From nico@cryptonector.com Thu Aug 16 13:09:14 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DF121F858A for ; Thu, 16 Aug 2012 13:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.105 X-Spam-Level: X-Spam-Status: No, score=-3.105 tagged_above=-999 required=5 tests=[AWL=-1.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 drOCeKAUbkY3 for ; Thu, 16 Aug 2012 13:09:14 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 11A2F21F852E for ; Thu, 16 Aug 2012 13:09:14 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 9AE53584059 for ; Thu, 16 Aug 2012 13:09:13 -0700 (PDT) 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; s=cryptonector.com; bh=SGp/aqrHGP72ObyaPLc9 OVVlSgs=; b=lh0xfDcNCUHQCbDMb6ZjFzFpS5Q49bCj98eBfSWwKvil1NsbOlO6 8tQGWUIu0XEvk6+UunvuuJKiqh1nt/eT3zBg0mejkD9lWwQ1NqjFp0hHqGGq7XJC XDi8NPEU71nSjEst29oLApV0YTaOkGeZoHYB3V0eKkft8wEqSTZV8NY= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 7FC7C584058 for ; Thu, 16 Aug 2012 13:09:13 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so2097905pbb.31 for ; Thu, 16 Aug 2012 13:09:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.167 with SMTP id if7mr5939244pbc.50.1345147753022; Thu, 16 Aug 2012 13:09:13 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Thu, 16 Aug 2012 13:09:12 -0700 (PDT) In-Reply-To: <1345132899.4152.YahooMailNeo@web31806.mail.mud.yahoo.com> References: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> <87hasbd4yq.fsf@latte.josefsson.org> <1345132899.4152.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Thu, 16 Aug 2012 15:09:12 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Channel binding language changes Re: Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 20:09:14 -0000 On Thu, Aug 16, 2012 at 11:01 AM, William Mills wrote: > On the channel binding stuff I changed the language to refer to the > definition in the channel binding spec: > > The channel binding payload is the raw data from the channel binding > type. For example, if the client is using tls-unique for channel binding > then > the raw channel binding data is the TLS finished message as specified in > section > 3.1 of It's actually RFC5929 that specifies tls-unique. RFC5056 recommends prefixing the channel bindint type name, ':', to the CB data. > I also struck the concept entirely of hashing the channel binding payload if > it's large. Yeah, don't do that: you end up having to provide hash agility. The tls-server-end-point and tls-unique CB types are already fixed-sized and small anyways. Nico -- From wmills@yahoo-inc.com Thu Aug 16 15:58:56 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8765211E808E for ; Thu, 16 Aug 2012 15:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.546 X-Spam-Level: X-Spam-Status: No, score=-17.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 erm7T1HZLt8N for ; Thu, 16 Aug 2012 15:58:56 -0700 (PDT) Received: from nm28-vm0.bullet.mail.ne1.yahoo.com (nm28-vm0.bullet.mail.ne1.yahoo.com [98.138.91.22]) by ietfa.amsl.com (Postfix) with SMTP id D3C2711E808A for ; Thu, 16 Aug 2012 15:58:55 -0700 (PDT) Received: from [98.138.90.50] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 16 Aug 2012 22:58:44 -0000 Received: from [98.138.87.12] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 16 Aug 2012 22:58:44 -0000 Received: from [127.0.0.1] by omp1012.mail.ne1.yahoo.com with NNFMP; 16 Aug 2012 22:58:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 564246.52578.bm@omp1012.mail.ne1.yahoo.com Received: (qmail 19368 invoked by uid 60001); 16 Aug 2012 22:58:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345157924; bh=XAP/GT/ZkfoNN8P6KNDaWcUNqov9ECYau0O/OLkJyw4=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IkoQ/S7TBc6Ni5gLz+VafPzwiG9k3IDXz506y49l8Diwnljh8d7ihDktvhas/NUBjQCz4W3GBdNAeOiyeYdSNMSz+qpayFGyNXdRqKbwixfOB+BUhVYWY1B5yBr39SfApkbvcoAM/EF5FYiVVfDdWkdeZnUxQw1ODN0b0h2hMsQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aDElX2U8M/pMTsrHp2W7dOAfjRVUw/arRL/C7RVY1SJ39Vj1U8ROlIIKh6GNGbL3f2GItuQK5ifm6DP8ePQ4BqJb8t2KW5Eot3KwWnCA3VLZ7FhbxdQ3+T3wVLcO9P3DyRIDBEb03rJHCUx6lTQCHIYGzoqegFdEgRkcxKO1ZoI=; X-YMail-OSG: EarWZBcVM1llv1qKUAM2_rckkbern22cIAihcVmDVhNECyV SiUYwGyBE2VtVP3_rmhIZzWGrK35aRRafDQLKl4_3dAbD7bfGPIQPuCCTFAa xUqQ1TRwTfP.N2Auobw2zRqVkQBuEN5hhZ5SrB7dQcGLtnETqQTkcRK6zl5P N_lmOIBM1GWtU3L3dxA_CeJHPykkmHuCQKe9Xa_rsFIEh2ZtRwI068fpt5jt 6eescs_uTvloi_V5dHhTt8pH7saBdOq2y28O9U7bxoJHezdrXAITz40HacLC 3fKerTK2YmziFNQ7hP1x_YLvWR5oseLvxxFpwo9ABjoMK5HxCtdY3vgiZuCZ DCe3HnnXa5aumRCkQH8eqCjiWtZgjGXhCV5m5t9ENuK1kqJmxhA_Pw2Bt6At _kq07LAJKv6Tl2SfZTeij_TeGtpuZpGZ8CAR9lZ4jYVhjpISzl3lOX671zcK wUjBD.Q-- Received: from [209.131.62.113] by web31813.mail.mud.yahoo.com via HTTP; Thu, 16 Aug 2012 15:58:44 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1344548823.23915.YahooMailNeo__7438.20652501217$1344548833$gmane$org@web31808.mail.mud.yahoo.com> <87hasbd4yq.fsf@latte.josefsson.org> <1345132899.4152.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: <1345157924.15638.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Thu, 16 Aug 2012 15:58:44 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-466593134-1345157924=:15638" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Channel binding language changes Re: Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 22:58:56 -0000 --767760015-466593134-1345157924=:15638 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Fixed the RFC reference, thanks.=0A=0A=0A=0A=0A=0A>________________________= ________=0A> From: Nico Williams =0A>To: William Mil= ls =0A>Cc: Simon Josefsson ; "k= itten@ietf.org" =0A>Sent: Thursday, August 16, 2012 1:09 = PM=0A>Subject: Re: [kitten] Channel binding language changes Re: Status of = draft-ietf-kitten-sasl-oauth?=0A> =0A>On Thu, Aug 16, 2012 at 11:01 AM, Wil= liam Mills wrote:=0A>> On the channel binding stuff = I changed the language to refer to the=0A>> definition in the channel bindi= ng spec:=0A>>=0A>>=A0 =A0 The channel binding payload is the raw data from= the channel binding=0A>>=A0 =A0 type. For example, if the client is using= tls-unique for channel binding=0A>> then=0A>>=A0 =A0 the raw channel bind= ing data is the TLS finished message as specified in=0A>> section=0A>>=A0 = =A0 3.1 of =0A>=0A>It's actually RFC5929 that sp= ecifies tls-unique.=0A>=0A>RFC5056 recommends prefixing the channel bindint= type name, ':', to the CB data.=0A>=0A>> I also struck the concept entirel= y of hashing the channel binding payload if=0A>> it's large.=0A>=0A>Yeah, d= on't do that: you end up having to provide hash agility.=A0 The=0A>tls-serv= er-end-point and tls-unique CB types are already fixed-sized=0A>and small a= nyways.=0A>=0A>Nico=0A>--=0A>=0A>=0A> --767760015-466593134-1345157924=:15638 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Fixed the= RFC reference, thanks.

From: Nico Williams <nico@cryptonector= .com>
To: William M= ills <wmills@yahoo-inc.com>
Cc: Simon Josefsson <simon@josefsson.org>; "kitten@ietf.o= rg" <kitten@ietf.org>
Sent= : Thursday, August 16, 2012 1:09 PM
wmills@yahoo-inc.com> wrot= e:
> On the channel binding stuff I changed the language to refer to = the
> definition in the channel binding spec:
>
>  &= nbsp; The channel binding payload is the raw data from the channel binding=
>    type. For example, if the client is using tls-unique= for channel binding
> then
>    the raw channel bin= ding data is the TLS finished message as specified in
> section
&g= t;    3.1 of <xref target=3D"RFC5056"/>

It's actual= ly RFC5929 that specifies tls-unique.

RFC5056 recommends prefixing the channel bindint type name, ':', to the CB data.

> I also str= uck the concept entirely of hashing the channel binding payload if
> = it's large.

Yeah, don't do that: you end up having to provide hash a= gility.  The
tls-server-end-point and tls-unique CB types are alrea= dy fixed-sized
and small anyways.

Nico
--


<= /div>
--767760015-466593134-1345157924=:15638-- From mrex@sap.com Thu Aug 16 17:19:20 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3BB11E80A3 for ; Thu, 16 Aug 2012 17:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.17 X-Spam-Level: X-Spam-Status: No, score=-10.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 J82RE+6Z8bCT for ; Thu, 16 Aug 2012 17:19:20 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 19F8211E808E for ; Thu, 16 Aug 2012 17:19:19 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q7H0JFPa017502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Aug 2012 02:19:15 +0200 (MEST) In-Reply-To: To: Nico Williams Date: Fri, 17 Aug 2012 02:19:15 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120817001915.3C9011A18C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Channel binding language changes Re: Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 00:19:20 -0000 Nico Williams wrote: > > It's actually RFC5929 that specifies tls-unique. > > > I also struck the concept entirely of hashing the channel binding payload if > > it's large. > > Yeah, don't do that: you end up having to provide hash agility. The > tls-server-end-point and tls-unique CB types are already fixed-sized > and small anyways. Uh-oh, that latter information is incorrect. tls-unique is _not_ fixed-size (the way I understand this term). It's 36 octets for SSLv3, 12 octets for TLSv1.0 & TLSv1.1, and officially ciphersuite-dependent for TLSv1.2 (with a default size of 12 octets). -Martin From wmills@yahoo-inc.com Thu Aug 16 17:30:32 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D584721F84D3 for ; Thu, 16 Aug 2012 17:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.547 X-Spam-Level: X-Spam-Status: No, score=-17.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 lsEz6zs95BeC for ; Thu, 16 Aug 2012 17:30:32 -0700 (PDT) Received: from nm2-vm0.bullet.mail.bf1.yahoo.com (nm2-vm0.bullet.mail.bf1.yahoo.com [98.139.213.127]) by ietfa.amsl.com (Postfix) with SMTP id 2E8C321F84A5 for ; Thu, 16 Aug 2012 17:30:29 -0700 (PDT) Received: from [98.139.214.32] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 17 Aug 2012 00:30:29 -0000 Received: from [98.139.212.242] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 17 Aug 2012 00:30:29 -0000 Received: from [127.0.0.1] by omp1051.mail.bf1.yahoo.com with NNFMP; 17 Aug 2012 00:30:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 490629.61327.bm@omp1051.mail.bf1.yahoo.com Received: (qmail 27429 invoked by uid 60001); 17 Aug 2012 00:30:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345163428; bh=wcwgK3HMaK9AmwdOer1HNfYvcyNtw+YDsl9FDMckCrI=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Zgh+aqtNxv+EtBC4bLVRyHewUtoMVdtxIrxYSFmwwgBiryF7CyN2CNQJzFvoT0nUBT0U6rurLFoaUv9M2XmTqN3CYn/zus5DUmszbORRHfLJT/RMnfCB+GpxcHaRX0C9ALl8QR3ggIw5u6bsZmX/DCY0pp39BJC6O9jQ+7/918U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lWvpnj4XWj5oLSxqgxqENPYpRoOluHGavFpugX4Bhi01rmruF7kmd4Ixp3iTdF6axITsliqF56/4K3lnbjxtNtx5uuCVgKK2QGTRg8asCKi1nfSLi87ErbuKdCeFsSRpPWpyWpQgQPR5ujZ88tHWmfnGuTnzaF/9NqaLiV6Qvew=; X-YMail-OSG: qoSfOBQVM1nlWQs35F1gibweqUD.DzGMn3jYeJBNbwrjN8A i5mj5X2b.bjG0pEnKlHmTFe6BKqiB12aIpajQRo.Bkj_4DSitwP1Wpp3S3lU UQFkCK_ZnINoehWRHbkTJ9yki7Sh3hr5vC6MG9fAyN8UsVL2ZyMQlQxH7i5a 7Cfi8Bot40i3rSlZPqik5P9SjyHUQ2JEXI.Jv4P_jjnergVju.7WG19qq0fG 0Ydj8GkcCjA_XCH1Nmv8IO6lD._Yulkux9JyS3uKJZ.NJtQOxwAGajCyiLVA .zsWHldL8cOIt3vx6vxqFgxGHfj5PvKhJFdh3cOpVq4QhPQayGFKsvrr342i 6g96j1cyMKZmzLHzUzhIVNRnekqWz_6QfKtS0LsYdGq2dBzvrsMc43dbYZBR PBTbwdNj.wrkzitPyOlOK3R_5dSkU0hRsg1vkQAK2guBxJIW1E2o_lHlTqEY lUf95mQ-- Received: from [209.131.62.113] by web31803.mail.mud.yahoo.com via HTTP; Thu, 16 Aug 2012 17:30:28 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <20120817001915.3C9011A18C@ld9781.wdf.sap.corp> Message-ID: <1345163428.26178.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Thu, 16 Aug 2012 17:30:28 -0700 (PDT) From: William Mills To: "mrex@sap.com" , Nico Williams In-Reply-To: <20120817001915.3C9011A18C@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1502656925-732267155-1345163428=:26178" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Channel binding language changes Re: Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 00:30:32 -0000 --1502656925-732267155-1345163428=:26178 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Good to know, but won't affect the OAUTH SASL spec I think.=0A=0A=0A=0A=0A= =0A>________________________________=0A> From: Martin Rex =0A= >To: Nico Williams =0A>Cc: William Mills ; "kitten@ietf.org" ; Simon Josefsson =0A>Sent: Thursday, August 16, 2012 5:19 PM=0A>Subject: Re: [= kitten] Channel binding language changes Re: Status of draft-ietf-kitten-sa= sl-oauth?=0A> =0A>Nico Williams wrote:=0A>> =0A>> It's actually RFC5929 tha= t specifies tls-unique.=0A>> =0A>> > I also struck the concept entirely of = hashing the channel binding payload if=0A>> > it's large.=0A>> =0A>> Yeah, = don't do that: you end up having to provide hash agility.=A0 The=0A>> tls-s= erver-end-point and tls-unique CB types are already fixed-sized=0A>> and sm= all anyways.=0A>=0A>Uh-oh, that latter information is incorrect.=0A>=0A>tls= -unique is _not_ fixed-size (the way I understand this term).=0A>=0A>It's 3= 6 octets for SSLv3, 12 octets for TLSv1.0 & TLSv1.1, and officially=0A>ciph= ersuite-dependent for TLSv1.2 (with a default size of 12 octets).=0A>=0A>= =0A>-Martin=0A>=0A>=0A> --1502656925-732267155-1345163428=:26178 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Good to k= now, but won't affect the OAUTH SASL spec I think.

From: Martin Rex = <mrex@sap.com>
To: Nico Williams <nico@cryptonector.com>
Cc: William Mills <wmills@yahoo-inc.com>; "k= itten@ietf.org" <kitten@ietf.org>; Simon Josefsson <simon@josefsso= n.org>
Sent: Thursday, August 16= , 2012 5:19 PM
Subject: Re: [kitten] Channel binding language changes Re: Status of draft-ietf-ki= tten-sasl-oauth?

Nico Williams wrote:
>
&g= t; It's actually RFC5929 that specifies tls-unique.
>
> > I= also struck the concept entirely of hashing the channel binding payload if=
> > it's large.
>
> Yeah, don't do that: you end up = having to provide hash agility.  The
> tls-server-end-point and = tls-unique CB types are already fixed-sized
> and small anyways.
<= br>Uh-oh, that latter information is incorrect.

tls-unique is _not_ = fixed-size (the way I understand this term).

It's 36 octets for SSLv= 3, 12 octets for TLSv1.0 & TLSv1.1, and officially
ciphersuite-depen= dent for TLSv1.2 (with a default size of 12 octets).


-Martin


<= /html> --1502656925-732267155-1345163428=:26178-- From nico@cryptonector.com Thu Aug 16 19:00:48 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A3221F84F2 for ; Thu, 16 Aug 2012 19:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.093 X-Spam-Level: X-Spam-Status: No, score=-3.093 tagged_above=-999 required=5 tests=[AWL=-1.116, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Nfu2uQ401BgS for ; Thu, 16 Aug 2012 19:00:47 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id E16A411E80BA for ; Thu, 16 Aug 2012 19:00:47 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 92CCD1DE070 for ; Thu, 16 Aug 2012 19:00:47 -0700 (PDT) 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; s=cryptonector.com; bh=cHRJYyz1c1IIvx4FiIIP 7gfSQFk=; b=Es/kVphsYEyMLOyhFgO+Pvx9unLU/yqrWb6CoCpw7m1qLGLfgu74 CcSZb6LLgfRtw3WcS8M8KP65Zg43FFZKytQc+JxsLb5j+Uv3XN3qTOmPvaxHQUTV L+7yjriE6k6qn/Xh92naTj3nN3b6/9OCmYerFiI/fDuF9l3UsDYSpCA= Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 6A8941DE060 for ; Thu, 16 Aug 2012 19:00:47 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3938407ghb.31 for ; Thu, 16 Aug 2012 19:00:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.89.70 with SMTP id bm6mr6035139pab.41.1345168846411; Thu, 16 Aug 2012 19:00:46 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Thu, 16 Aug 2012 19:00:46 -0700 (PDT) In-Reply-To: <20120817001915.3C9011A18C@ld9781.wdf.sap.corp> References: <20120817001915.3C9011A18C@ld9781.wdf.sap.corp> Date: Thu, 16 Aug 2012 21:00:46 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Channel binding language changes Re: Status of draft-ietf-kitten-sasl-oauth? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:00:48 -0000 On Thu, Aug 16, 2012 at 7:19 PM, Martin Rex wrote: > Nico Williams wrote: >> Yeah, don't do that: you end up having to provide hash agility. The >> tls-server-end-point and tls-unique CB types are already fixed-sized >> and small anyways. > > Uh-oh, that latter information is incorrect. > > tls-unique is _not_ fixed-size (the way I understand this term). > > It's 36 octets for SSLv3, 12 octets for TLSv1.0 & TLSv1.1, and officially > ciphersuite-dependent for TLSv1.2 (with a default size of 12 octets). Yes, I know, and tls-server-end-point too can vary in size. But for any one case the size is fixed and small, and what matters here is that they're small. You're right that one should not count on them being fixed-sized. From latze@angry-red-pla.net Fri Aug 17 01:23:56 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D9C21F853C for ; Fri, 17 Aug 2012 01:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 93NY1fneOnjP for ; Fri, 17 Aug 2012 01:23:55 -0700 (PDT) Received: from thuvia.angry-red-pla.net (thuvia.angry-red-pla.net [83.169.33.217]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA9B21F8577 for ; Fri, 17 Aug 2012 01:23:55 -0700 (PDT) Received: from [195.176.215.139] by thuvia.angry-red-pla.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1T2HqR-0008V0-3w for kitten@ietf.org; Fri, 17 Aug 2012 10:23:52 +0200 Message-ID: <502DFF91.3020209@angry-red-pla.net> Date: Fri, 17 Aug 2012 10:23:45 +0200 From: Carolin Latze User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: kitten@ietf.org References: <5000104E.2000607@angry-red-pla.net> <87629j3jty.fsf@latte.josefsson.org> <7E7509CFA6720310B98847D3@96B2F16665FF96BAE59E9B90> <5024D487.9000208@isode.com> In-Reply-To: <5024D487.9000208@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [kitten] draft-josefsson-sasl-external-channel-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 08:23:57 -0000 So in order to provide a solution for the use case of having multiple certificates within the same authentication exchange, you would prefer to use EXTERNAL with TLS and then renegotiation as proposed in the current draft? On 08/10/2012 11:29 AM, Alexey Melnikov wrote: > On 20/07/2012 16:45, Chris Newman wrote: >> --On July 19, 2012 16:29:45 +0200 Simon Josefsson >> wrote: >>> I share your concern, although the reason for not saying anything like >>> what you suggest is that, today, EXTERNAL and EXTERNAL-TLS semantically >>> are different beasts. I believe the EXTERNAL-TLS semantics are more >>> useful. It seems the deployment you refer to support that notion as >>> well: they use EXTERNAL precisely what we want EXTERNAL-TLS for. >>> The problem is that EXTERNAL can be used for other things too, and >>> there >> is >>> no way of knowing which purpose was intended. >> >> Honestly, I see no real-world problem here. Yes, there's a minor >> semantic difference between "use available credentials" and "use >> available TLS credentials" but I don't see why it would matter to a >> client that has gone through the trouble of being configured to >> provide TLS client certificates. >> >>> To illustrate the problem, consider an application running over IPSEC >>> that does IMAP with STARTTLS. The client see EXTERNAL announced from >>> the server. The app wants to authenticate to the IMAP server using its >>> TLS credentials. The app does not want to use its IPSEC credential to >>> authenticate to the IMAP server. If it does 'AUTHENTICATE EXTERNAL' >>> the >>> client doesn't know which credential was used for authentication, >>> and it >>> isn't deterministic which account it was logged into. (This example >>> does not use any authorization identity for simplicity, although >>> this is >>> the most common usage.) >> >> I know of no such implementation, nor of anyone conceiving of such an >> implementation. First, no IMAP server will advertise EXTERNAL as a >> result of IPSEC. The problem is that IPSEC uses host credentials >> which can't be mapped to an end-user account (or if it uses end-user >> credentials, there's no standard API to get them from the OS), so it >> doesn't provide any useful credentials for end-user authentication >> purposes so any IMAP server that advertised EXTERNAL without a useful >> mapping to end-user credentials would be at least broken and probably >> incompliant. Even if IPSEC could provide end-user credentials, those >> credentials would almost always be the correct ones and the client >> need not worry. >> >> So your strawman presumes 4 unlikely events: 1. someone uses IPSEC. >> 2. IPSEC uses end-user credentials which imapd can access through a >> supported API. 3. The IPSEC end-user credentials differ from the mail >> account identity. 4. The client both cares which mail account is >> accessed and fails to provide the mail account authorization identity >> to the EXTERNAL mechanism. >> >> That scenario is at best an unlikely misconfiguration, if not a >> broken client. I still think this is all trying to solve a >> non-existent problem. > > Agreed. The only other non-TLS use case I've seen for SASL EXTERNAL > was over a Unix domain socket. > >> >>> I believe the text you provided would be good, and we'd be happy to add >>> it. There is another solution though: >>> >>> How do you feel about revising the EXTERNAL mechanism specification to >>> say that it refers to the credentials negotiated under TLS, similar to >>> what's in d-j-sasl-external-channel? Currently EXTERNAL refers to >>> anything outside of the application protocol, and to get security and >>> interoperability, client and server need to negotiate out of band what >>> is intended. >> >> I would have no objection to this change. >> >>> Compare how we "updated" the GSSAPI mechanism to be for Kerberos V5 >>> only. We could update EXTERNAL to be for TLS only, and permit future >>> specification of EXTERNAL-SSH or EXTERNAL-IPSEC for "external" SASL >>> authentication with other security protocols (if someone cares about >>> that). >>> >>> I find EXTERNAL to be rarely used because applications cannot >>> auto-detect when it is appropriate to use, and when it is used, in my >>> experience it always means to use the TLS-negotiated credentials. >> >> There are two useful models for clients: >> 1. explicit end-user selected security mechanism/policy >> 2. latched auto-select security policy: the client looks for the best >> option that works, and records that it worked with that server and >> requires security at least that good in the future to prevent >> downgrade attacks. >> >> Most clients do 1 because it's much less complex to implement/debug >> even if it does leave the choice up to the end-user. On top of that, >> it's even more difficult to auto-select the intended client >> certificate (which client certificate is associated with which mail >> account?). So if you have to make the end-user manually configure TLS >> client cert authentication anyway, may as well keep the code simpler. >> >> The other problem is the wide deployment of non-interoperable >> protocols when it comes to TLS client certificate authentication. >> There are ones where we botched the IETF specifications (SMTP), so >> there are servers that require EXTERNAL, servers that disallow >> EXTERNAL and servers that do or don't use client certificate >> credentials as a side-effect of the STARTTLS command and there's >> usually no way for the client to tell the difference. Most SMTP >> clients are lazy and just send the TLS client certificate and hope it >> works. Then there's the non-standard imaps and pops protocols that >> have unspecified behavior (and often do not interoperate when it >> comes to client certificate authentication). >> >> At least there's no excuse for non-interoperable STARTTLS client >> certificate authentication in IMAP and POP because that was >> standardized unambiguously in 1999. >> >> Of course, there's also the problem that deploying and managing a >> certificate infrastructure is a huge amount of work so for most >> deployments the incremental security (if any) isn't worth the cost. >> >> I don't think making EXTERNAL more complex will improve deployment of >> TLS client certificate authentication. Frankly, spending time on DANE >> specification and implementation would probably be a better >> investment if the latter is your goal. >> >>> The EXTERNAL-* idea is mostly to formalize one use-case for EXTERNAL. >>> We could modify d-j-sasl-external-channel and say that for historical >>> reasons EXTERNAL-TLS is actually called EXTERNAL, and then supersede >>> Appendix A of RFC 4422 with this document. The only problem this would >>> cause, that I can identify, is if someone is using EXTERNAL to mean >>> IPSEC or some other security protocol. Is anyone aware of any such >>> usage? >> >> No. > > +1 to all of this. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From hannes.tschofenig@gmx.net Fri Aug 17 04:02:51 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8877421F852D for ; Fri, 17 Aug 2012 04:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 BqJ6JEkG9Div for ; Fri, 17 Aug 2012 04:02:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9527921F850D for ; Fri, 17 Aug 2012 04:02:50 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2012 11:02:49 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp027) with SMTP; 17 Aug 2012 13:02:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+oFFE7TJGouFRkQ7jq3OaGk0zQZENz4BULA0Xwq6 q8koqbAjYbPMNj Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Fri, 17 Aug 2012 14:02:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5EDE311B-D9FF-4F35-BED7-A8F9CC799618@gmx.net> References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 11:02:51 -0000 Hi Bill,=20 I fully understand that issue. The problem is that I do not believe that = new standards with more sophisticated security mechanisms will help = those people who do not want to use security to begin with.=20 There are also many strange extensions for OAuth, and OAuth alike = systems out there that are privacy invasive and have dubious security = value.=20 Ciao Hannes On Aug 16, 2012, at 7:20 PM, William Mills wrote: > While I agree with you form a security stance, I must point out that = FB was using bearer tokens in the clear for about a year I think until = the rolled out HTTPS. People will in fact make that choice, just as = they use cookies for authorization in the clear. >=20 >=20 > From: Hannes Tschofenig > To: Nico Williams =20 > Cc: kitten@ietf.org=20 > Sent: Thursday, August 16, 2012 8:56 AM > Subject: Re: [kitten] SASL OAuth - My Conclusion So Far >=20 > Hi Nico,=20 >=20 > On Aug 16, 2012, at 5:43 PM, Nico Williams wrote: >=20 > > On Thu, Aug 16, 2012 at 4:54 AM, Hannes Tschofenig > > wrote: > >> In some sense the desire to have mechanisms with different = properties shouldn't be all that surprising given that motivated the = concept of authentication frameworks (like SASL, EAP, and GSS-API) = altogether. > >=20 > > I would say it's not about the framework but about the applications > > that might use these mechanisms. Not all are web/HTTP apps, nor are > > all apps that use or can use TLS either. No TLS almost implies no > > bearer tokens. >=20 > I agree with you. >=20 > For applications that cannot use TLS (or DTLS) bearer tokens are not = usable. >=20 > Ciao > Hannes >=20 > >=20 > > Nico > > -- >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 >=20 From hannes.tschofenig@gmx.net Fri Aug 17 04:08:08 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B1421F8550 for ; Fri, 17 Aug 2012 04:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 fNxI4eWt1iei for ; Fri, 17 Aug 2012 04:08:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5426D21F84E1 for ; Fri, 17 Aug 2012 04:08:07 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2012 11:08:06 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp041) with SMTP; 17 Aug 2012 13:08:06 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19beF5kbT1b1IKXcGpupBYpefGWAloONJDVqQjhIy Z3V0ztYdgcay8s Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 17 Aug 2012 14:08:04 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <329D2FF6-9B75-4056-9C30-60E79FC9ACC0@gmx.net> References: To: Nico Williams X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: kitten@ietf.org Subject: Re: [kitten] Bearer vs. non-bearer (Re: OAUTH SASL and Channel binding) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 11:08:08 -0000 The problem with not trusting the PKI is that you will run into lots of = other problems as well. While I acknowledge that the PKI world is far = from being perfect the alternatives also have their issues.=20 The DANE work (in combination with a TLS extension for raw public keys) = also provides an alternative to the Web-based PKI and it is even = compatible with the Bearer Token approach.=20 ABFAB, for example, standardizes an alternative model to the Web PKI = world. It yet has to seen the deployment in the application world (and = even better in the Web world) but theoretically it would work great.=20 In a nutshell, OAuth relies on a PKI (at least for the client to = authorization server interaction) and I doubt that we will ever get an = agreement whether security at the lower layers (as offered by TLS) or at = the higher layers (as an application layer security solution, such as = the MAC tokens or a JSON based approach) is better.=20 On Aug 16, 2012, at 7:20 PM, Nico Williams wrote: > FWIW, I seethe appeal of bearer tokens. If you trust the TLS server > PKI then bearer tokens can be implemented with no changes to the > HTTP/TLS stack and *no additional crypto* on the client side. Heck, > it's even possible to implement bearer token schemes with no > additional crypto anywhere. This sounds too wonderful too be true, > but it is true, no? >=20 > But once you're stuck with a bearer token you're also stuck with > either trusting the TLS server PKI fully, or making changes to the > HTTP/TLS stack. That seems like an awful bind to me. >=20 > So, in principle bearer and signature tokens can both offer reasonable > security (if one adheres to their respective security considerations). > In practice there are differences, which I hope I captured succinctly > enough above. >=20 > I believe the downside of bearer tokens overwhelm the upside -- a > proposition that no doubt requires more discussion. >=20 > Nico > -- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From hannes.tschofenig@gmx.net Fri Aug 17 04:11:37 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301D921F84FA for ; Fri, 17 Aug 2012 04:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 pLAaJUL2rR36 for ; Fri, 17 Aug 2012 04:11:36 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 469F921F84FD for ; Fri, 17 Aug 2012 04:11:35 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2012 11:11:34 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp032) with SMTP; 17 Aug 2012 13:11:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+E8k52fZCEOhcpihFeoEIC2Qw9LMSW9DlyysOEOF PF5ZeOG52q26fR Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 17 Aug 2012 14:11:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 11:11:37 -0000 Hi Nico,=20 On Aug 16, 2012, at 8:21 PM, Nico Williams wrote: > On Thu, Aug 16, 2012 at 11:20 AM, William Mills = wrote: >> While I agree with you form a security stance, I must point out that = FB was >> using bearer tokens in the clear for about a year I think until the = rolled >> out HTTPS. People will in fact make that choice, just as they use = cookies >> for authorization in the clear. >=20 > Cookies themselves are a form of bearer token, but at least one can > set different cookies for use with HTTP vs. HTTPS. I don't like this comparison with cookies to much since cookies are = quite different.=20 > Bearer tokens are > too valuable to send without using TLS. Correct. That's why the specification mandates TLS.=20 > A signature token is far more > secure in the absence of TLS, In absence of TLS the shared secret for the keyed message digest is = carried to the client in clear. Why is that more secure?=20 If an attacker is supposed to eavesdrop the access token then why = wouldn't he want to also get the key as well (which is in the same = message)? > but if you'll use HTTP and cookies w/o > TLS at all then your sessions can still be hijacked, in which case > bearer or signature makes little difference. >=20 > For me the main thing is that bearer tokens simply have no useful > existence w/o TLS or equivalent, which means they are not applicable > to a non-trivial class of application protocols. I.e., bearer tokens > are less general. Which application protocols are you particularly talking about that = cannot use TLS (or DTLS)? >=20 > There's also the problem that bearer tokens cannot improve server > authentication without rototilling the HTTP/TLS stacks. Not sure what you mean.=20 Just as a side-note: MAC tokens do not provide server authentication=20 Ciao Hannes =20 >=20 > Nico > -- From Hannes.Tschofenig@gmx.net Fri Aug 17 04:32:52 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E02C21F853A for ; Fri, 17 Aug 2012 04:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 qhdFUp2DSaOp for ; Fri, 17 Aug 2012 04:32:50 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3ADFE21F8530 for ; Fri, 17 Aug 2012 04:32:49 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2012 11:32:48 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp012) with SMTP; 17 Aug 2012 13:32:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19BwHNEP61BrJyONQdV1IP5ye5dxNqA64320ssmgE uhd4IghuZUiXfz Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 17 Aug 2012 14:32:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1344706384.36422.YahooMailNeo@web31805.mail.mud.yahoo.com> <1344828671.93823.YahooMailNeo@web31810.mail.mud.yahoo.com> <5CAFEC4F-3468-4EC8-82AF-31BBCBB085E6@gmx.net> <20536B9E-EB2A-4534-B570-1B753F8108A4@gmx.net> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 11:32:52 -0000 Hi Nico,=20 On Aug 16, 2012, at 6:03 PM, Nico Williams wrote: > On Thu, Aug 16, 2012 at 2:36 AM, Hannes Tschofenig > wrote: >> On Aug 16, 2012, at 10:08 AM, Nico Williams wrote: >>> On Thu, Aug 16, 2012 at 1:50 AM, Hannes Tschofenig >>> wrote: >>>> I do not believe that the term "equivalent" is appropriate here = since the mechanisms we are discussing provide different security = properties. The question we always had been struggling with was "what = are the desired security properties given certain deployment = constraints". >>>=20 >>> I said they weren't equivalent. But, at any rate, let's look at = properties: >>=20 >> The OAuth entities are: client (which may be a Web site, or a = downloadable application, a JavaScript application running in your = browser, etc.) and the resource server. I believe you call the resource = server the "service". Note that we are not at all talking about the = resource owner her (which is the user granting access to the protected = resource). >=20 > I was trying to address bearer vs. not-beader token mechanisms in > general, not OAuth specifically. OK.=20 >=20 >>> - both bearer tokens and "signature tokens" (let's call them that = for >>> argument's sakes) can authenticate a client to a service >>=20 >> Actually neither of them authenticates the client to the resource = server. Client authentication is a separate mechanism independent of the = discussed security mechanisms in the spec. >=20 > See above. They authenticate something. Whether that something be an > assertion of identity or an assertion of access to resources. >=20 I think that there is a big difference between authenticating an entity = vs. providing key confirmation. If you look at a number of three party = protocols (think about EAP/AAA over foo, ABFAB, SAML, etc.) then there = lots of differences and not surprisingly these details matter. >>> - bearer tokens cannot authenticate a service to a client, but by >>> using TLS and validating the cert at the token issuer a bearer token >>> system can still authenticate the service to the client; the same >>> applies to signature mechanisms if they use a half round trip >>=20 >> When I talk about "Bearer Tokens" then I refer to the entire = specification rather than about the token itself. >>=20 >> As such, I would say that bearer tokens provide authentication of the = resource server to the client via the help of the TLS using PK-based = authentication. >=20 > In particular it's very difficult for bearer token systems to do > better than the TLS PKI for server authentication. The Bearer Token uses TLS for server-side authentication.=20 > Scott talked about > how it can be done, but I'm skeptical. This, and the requirement for > transport security being up before the token is sent, are the biggest > problems with bearer tokens IMO. >=20 > ... >>> - bearer tokens *must* be used with TLS, whereas signature tokens = can >>> be used with and without TLS (the whole world is not web/HTTP, so = this >>> is of some importance) >>=20 >> Yes, bearer tokens must be used with TLS. >> TLS is not only used in the Web. >=20 > More importantly: TLS is not used in every application protocol. > Examples where it's not used: >=20 > - SSHv2 > - NFSv4 (and all ONC RPC apps) > - AFS (and all rx apps) > - SMB > - all MSRPC apps > - DNS updates That's a great list but the question with regard to OAuth SASL is: * Are these applications in a need a new SASL security mechanism? Bill = and myself focus on different applications.=20 * In case that these applications need a new SASL security mechanism, = do they need something in the style of OAuth SASL?=20 * If they do, why cannot they implement whatever the OAuth SASL spec = tells them to do. OAuth SASL does not require them to use TLS elsewhere = in their protocol (even though it would probably make a lot of sense).=20= >=20 >>> - both require cryptography somewhere; bearer tokens require it in >>> TLS and between the client and the token issuer. >>>=20 >> Bearer tokens require TLS between the client and the authorization = server (to obtain the token) and between the client and the resource = server (when presenting the token). >>=20 >> MAC tokens require (in my opinion - but not in the spec) TLS between = the client and the resource server (to obtain the token and the shared = secret) but not between the client and the resource server (unless = confidentiality protection, integrity protection of the entire message = exchange, or server-side authentication is a desire). Then, there is = also the step where the shared secret needs to travel from the = authorization server and the resource server. When you replace the terms = s/authorization server/identity provider and s/resource server/relying = party then you may see the need to have a solution for cross domain = communication. >=20 > That step can be Needham-Schroeder-like (i.e., like Kerberos). Yes. >=20 >>> Is that about right? I think you could make an argument that bearer >>> tokens are not so bad, but I would argue that they are not so = general. >> Yes, about right. >=20 > Maybe we should write this down somewhere. You are right.=20 I tried to do that in = http://www.potaroo.net/ietf/all-ids/draft-tschofenig-oauth-signature-thoug= hts-00.txt. It seems that I have not done a good job.=20 Ciao Hannes >=20 > Nico > -- From Hannes.Tschofenig@gmx.net Fri Aug 17 04:41:26 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB29A21F848F for ; Fri, 17 Aug 2012 04:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 qDRiotBj1iBl for ; Fri, 17 Aug 2012 04:41:26 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D592D21F845B for ; Fri, 17 Aug 2012 04:41:25 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2012 11:41:23 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp033) with SMTP; 17 Aug 2012 13:41:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX180NWhjXk00KSmHWgTtrk9qlUTXfPGZgnlwYkO3rb y+eouZK+Q7wMx1 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 17 Aug 2012 14:41:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9044B1E5-BD2B-4AC1-9979-A3CBE884577C@gmx.net> References: To: "Cantor, Scott" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 11:41:26 -0000 On Aug 16, 2012, at 6:08 PM, Cantor, Scott wrote: > In other words, it's more tractable to address that TLS leg in a more > advanced manner than it is to try and fix all the TLS usage between = the > client and the relying parties, of which there are more, and which = have no > general relationship to the user. I agree with you, Scott.=20 Still, it does not make TLS a useless mechanism for the = client-to-resource server interaction. It ultimately depends on what we think different IdP providers are = capable of providing. If we assume a model where "everyone" can run = their own identity provider then we have to lower our expectations about = their ability to configure security settings.=20 Remember the OpenID days - that was the expectation that some people had = raised. Everyone would run their own OpenID server.=20 Is this what we are aiming for?=20 From cantor.2@osu.edu Fri Aug 17 09:26:26 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1DA21F84B6 for ; Fri, 17 Aug 2012 09:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ZDLLWzwgsogC for ; Fri, 17 Aug 2012 09:26:26 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4A021F8491 for ; Fri, 17 Aug 2012 09:26:19 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7HGQAG9020181; Fri, 17 Aug 2012 12:26:11 -0400 Received: from CIO-TNC-HT07.osuad.osu.edu (2002:a46b:51ae::a46b:51ae) by CIO-KRC-HT02.osuad.osu.edu (2002:a46b:5115::a46b:5115) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 17 Aug 2012 12:26:00 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.02.0309.002; Fri, 17 Aug 2012 12:25:57 -0400 From: "Cantor, Scott" To: Hannes Tschofenig Thread-Topic: [kitten] OAUTH SASL and Channel binding Thread-Index: AQHNe8BSHGdoCl4WY0+O4QBdMhqIS5dcipsAgAGbZICAAAxwAA== Date: Fri, 17 Aug 2012 16:25:55 +0000 Message-ID: In-Reply-To: <9044B1E5-BD2B-4AC1-9979-A3CBE884577C@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.74.80.179] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:26:26 -0000 On 8/17/12 7:41 AM, "Hannes Tschofenig" wrote: > >Still, it does not make TLS a useless mechanism for the >client-to-resource server interaction. I consider it useless if the expectation is that the typical Web 2.0 developer's tools will get it right. >It ultimately depends on what we think different IdP providers are >capable of providing. If we assume a model where "everyone" can run their >own identity provider then we have to lower our expectations about their >ability to configure security settings. There's a spectrum between a billion IdPs and 6. OAuth in practice is way too far to the latter end for my taste. But all this is really beside the point. I'd like to return to the original question: is there a concern about having channel binding specified if the OAuth profile permits it? And more to the point, it sounds like the real problem is that there is no OAuth 2.0 material on the road to standardization that will in fact support it. -- Scott From cantor.2@osu.edu Fri Aug 17 09:43:12 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C70411E80DC for ; Fri, 17 Aug 2012 09:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 iZ8DiHT-VWiL for ; Fri, 17 Aug 2012 09:43:11 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 49DC011E809B for ; Fri, 17 Aug 2012 09:43:11 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7HGgu7U028578; Fri, 17 Aug 2012 12:43:07 -0400 Received: from CIO-TNC-HT07.osuad.osu.edu (2002:a46b:51ae::a46b:51ae) by CIO-TNC-HT05.osuad.osu.edu (2002:a46b:51a9::a46b:51a9) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 17 Aug 2012 12:42:54 -0400 Received: from CIO-TNC-HT07.osuad.osu.edu (([fe80::1c0f:4d2:f020:9937%12])) by CIO-TNC-HT07.osuad.osu.edu (([fe80::1c0f:4d2:f020:9937%12])) with ShadowRedundancy id 14.2.309.2; Fri, 17 Aug 2012 16:42:52 +0000 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.02.0309.002; Fri, 17 Aug 2012 12:25:57 -0400 From: "Cantor, Scott" To: Hannes Tschofenig Thread-Topic: [kitten] OAUTH SASL and Channel binding Thread-Index: AQHNe8BSHGdoCl4WY0+O4QBdMhqIS5dcipsAgAGbZICAAAxwAA== Date: Fri, 17 Aug 2012 16:25:55 +0000 Message-ID: In-Reply-To: <9044B1E5-BD2B-4AC1-9979-A3CBE884577C@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.74.80.179] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:43:13 -0000 On 8/17/12 7:41 AM, "Hannes Tschofenig" wrote: > >Still, it does not make TLS a useless mechanism for the >client-to-resource server interaction. I consider it useless if the expectation is that the typical Web 2.0 developer's tools will get it right. >It ultimately depends on what we think different IdP providers are >capable of providing. If we assume a model where "everyone" can run their >own identity provider then we have to lower our expectations about their >ability to configure security settings. There's a spectrum between a billion IdPs and 6. OAuth in practice is way too far to the latter end for my taste. But all this is really beside the point. I'd like to return to the original question: is there a concern about having channel binding specified if the OAuth profile permits it? And more to the point, it sounds like the real problem is that there is no OAuth 2.0 material on the road to standardization that will in fact support it. -- Scott From wmills@yahoo-inc.com Fri Aug 17 09:52:19 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D140321F8494 for ; Fri, 17 Aug 2012 09:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.548 X-Spam-Level: X-Spam-Status: No, score=-17.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 SG2C8E5KF4TJ for ; Fri, 17 Aug 2012 09:52:19 -0700 (PDT) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) by ietfa.amsl.com (Postfix) with SMTP id B5CF921F849D for ; Fri, 17 Aug 2012 09:52:18 -0700 (PDT) Received: from [98.139.212.144] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 17 Aug 2012 16:52:18 -0000 Received: from [98.139.212.233] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 17 Aug 2012 16:52:18 -0000 Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 17 Aug 2012 16:52:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 50046.51094.bm@omp1042.mail.bf1.yahoo.com Received: (qmail 37885 invoked by uid 60001); 17 Aug 2012 16:52:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345222337; bh=8YuZ74q9s8JasIzkXH/XKFxb9/kg0UW9h0eAm0IkpOg=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cYh5JYxVYFSzL4SMJXo/9LT/NoOguiS4xk1poPJ6BszKROFQnVxjL6LRLgzpn0z2hbbrfnRPpsq2Curq0uklHtDzWEMa4ein6CMf5DDw8ewB6UWFJxqMBwhB+st7/KSUYk1AsMR0DCOrBfCzGVrzqRY7TxQ3zcbEpymafrtT8eg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PW8uRbN8NWEWHKMJVS3383RHIFSPXuZREqA6YBi9NJmtzQ4LCmTcH5clJW3mfITodU3MsQmooeb2D9UckN/Mex9WoPDH1OQ7rkreK01OOBNMRTCrGJl5QTn1xjAjKqDtwwnXqlBzPEdxggPqA7uVUkJDhjbcU0mNR51aSBSa4i8=; X-YMail-OSG: WYjeCMMVM1nVHid1VrtOmlfAq3qC.xPg1yLVVZJpv4Umzg6 sH99NhOIQpTwrRWdsWtNsfmuM3Hbqk_sehL4_WZbMY5wV8ZidYc8kTr.C6wV omoTYpBrtlq7FgHMfG2uulNZxMsD0JMF_NKYxqNNN5j8fqQNLmjMwvxGP301 a.FUw4NLU__1yIZoonjI9P8.b68UBRrtzXG4pyPbIo5RobWm5JoQ720EfiZ6 _.jHAbZTd7Xtbfv75BSbqLBx2cnOEIFNdyfAaIII3sFx.3EDmryrjTLKxNKc 5e.PqCoktle9QQsfEx9hpcZ9owRU0CEOVPGT7Tlgk_OgDLsT0s5OxSWbrwBP GHufs7jcklY9fARkJ.phOZ2d4OoOQhgEVaxCOT9.XHg6oubH_89FROtvLzjR xyxzL_HT4C398tLOVivQM4HPbk3X2y3CNJd.RYCJqGic5k77Xqs3VmHG6Xxk A9SHqYQ-- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Fri, 17 Aug 2012 09:52:17 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <9044B1E5-BD2B-4AC1-9979-A3CBE884577C@gmx.net> Message-ID: <1345222337.34559.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Fri, 17 Aug 2012 09:52:17 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Hannes Tschofenig In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-358964279-1345222337=:34559" Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:52:19 -0000 --767760015-358964279-1345222337=:34559 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OAuth 1.0a can support it.=A0 I've taken the MAC examples out of the OAUTH = SASL draft and replaced them with OAuth 1.0a examples.=A0 A new version wil= l be coming soon with these changes, and I've moved the MAC draft to inform= ative instead of normative.=0A=0A=0A-bill=0A=0A=0A=0A=0A>__________________= ______________=0A> From: "Cantor, Scott" =0A>To: Hannes T= schofenig =0A>Cc: "kitten@ietf.org" =0A>Sent: Friday, August 17, 2012 9:25 AM=0A>Subject: Re: [kitten] O= AUTH SASL and Channel binding=0A> =0A>On 8/17/12 7:41 AM, "Hannes Tschofeni= g" wrote:=0A>>=0A>>Still, it does not make TLS = a useless mechanism for the=0A>>client-to-resource server interaction.=0A>= =0A>I consider it useless if the expectation is that the typical Web 2.0=0A= >developer's tools will get it right.=0A>=0A>>It ultimately depends on what= we think different IdP providers are=0A>>capable of providing. If we assum= e a model where "everyone" can run their=0A>>own identity provider then we = have to lower our expectations about their=0A>>ability to configure securit= y settings.=0A>=0A>There's a spectrum between a billion IdPs and 6. OAuth i= n practice is way=0A>too far to the latter end for my taste.=0A>=0A>But all= this is really beside the point. I'd like to return to the=0A>original que= stion: is there a concern about having channel binding=0A>specified if the = OAuth profile permits it? And more to the point, it=0A>sounds like the real= problem is that there is no OAuth 2.0 material on the=0A>road to standardi= zation that will in fact support it.=0A>=0A>-- Scott=0A>=0A>_______________= ________________________________=0A>Kitten mailing list=0A>Kitten@ietf.org= =0A>https://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> --767760015-358964279-1345222337=:34559 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OAuth 1.0= a can support it.  I've taken the MAC examples out of the OAUTH SASL d= raft and replaced them with OAuth 1.0a examples.  A new version will b= e coming soon with these changes, and I've moved the MAC draft to informati= ve instead of normative.

From: "Cantor, Scott" <cantor.2@osu.edu>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx= .net>
Cc: "kitten@i= etf.org" <kitten@ietf.org>
Sent: Friday, August 17, 2012 9:25 AM
Subject: Re: [kitten] OAUTH SASL and Channel bi= nding

On 8/17/12 7:41 AM, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> wrote:
>
>Still,= it does not make TLS a useless mechanism for the
>client-to-resource= server interaction.

I consider it useless if the expectation is tha= t the typical Web 2.0
developer's tools will get it right.

>It= ultimately depends on what we think different IdP providers are
>capable of pro= viding. If we assume a model where "everyone" can run their
>own iden= tity provider then we have to lower our expectations about their
>abi= lity to configure security settings.

There's a spectrum between a bi= llion IdPs and 6. OAuth in practice is way
too far to the latter end for= my taste.

But all this is really beside the point. I'd like to retu= rn to the
original question: is there a concern about having channel bin= ding
specified if the OAuth profile permits it? And more to the point, i= t
sounds like the real problem is that there is no OAuth 2.0 material on= the
road to standardization that will in fact support it.

-- Sco= tt

_______________________________________________
Kitten mailing= list
Kitten@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/kitten


--767760015-358964279-1345222337=:34559-- From nico@cryptonector.com Fri Aug 17 22:00:45 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F048011E80B8 for ; Fri, 17 Aug 2012 22:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.082 X-Spam-Level: X-Spam-Status: No, score=-3.082 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 rN+pHW59QOxA for ; Fri, 17 Aug 2012 22:00:45 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id EFCED11E80AE for ; Fri, 17 Aug 2012 22:00:44 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 89243594058 for ; Fri, 17 Aug 2012 22:00:44 -0700 (PDT) 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; s=cryptonector.com; bh=r3yXkQ4cNOxt8rqmJ19D 64OKdZU=; b=xDfXpyz9PULpsQWCHW/snyFxSKWjuTevz/5M1g/0BrBY1GTy6SOw 3+ACZ0jnQHuWbrhzjl0qPnuPHnRYKDLc4yiRL6jRNQd/sCMn2sItjzMFh368jMUq WWL232M/EFkc/Q6YrPN4UFIs33OPBfG/sNfDB1onod75nVBnrgFkl+Y= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 7934859401C for ; Fri, 17 Aug 2012 22:00:44 -0700 (PDT) Received: by dakr19 with SMTP id r19so1191336dak.31 for ; Fri, 17 Aug 2012 22:00:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.167 with SMTP id rt7mr16639406pbc.146.1345266044125; Fri, 17 Aug 2012 22:00:44 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Fri, 17 Aug 2012 22:00:44 -0700 (PDT) In-Reply-To: References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Sat, 18 Aug 2012 00:00:44 -0500 Message-ID: From: Nico Williams To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 05:00:46 -0000 On Fri, Aug 17, 2012 at 6:11 AM, Hannes Tschofenig wrote: > On Aug 16, 2012, at 8:21 PM, Nico Williams wrote: > >> On Thu, Aug 16, 2012 at 11:20 AM, William Mills wrote: >>> While I agree with you form a security stance, I must point out that FB was >>> using bearer tokens in the clear for about a year I think until the rolled >>> out HTTPS. People will in fact make that choice, just as they use cookies >>> for authorization in the clear. >> >> Cookies themselves are a form of bearer token, but at least one can >> set different cookies for use with HTTP vs. HTTPS. > > I don't like this comparison with cookies to much since cookies are quite different. Hannes, they are like bearer tokens in the way that matters in the context that I was discussing. I agree that there's other aspects of cookies that make them apples to OAuth's being oranges, but that's not relevant here. Interjecting irrelevancies into the discussion only makes it harder to make progress. >> Bearer tokens are >> too valuable to send without using TLS. > > Correct. That's why the specification mandates TLS. And that's the problem I have: I don't think any service authentication system that must scale to all services on the web can provide the level of security that we should want. I want security mechanisms that support federations (retail federations, banking federations, ...). You and I disagree fundamentally on this. At this point it will have to be the market that proves one or both of us wrong, because we've been at this enough that I don't think we'll change each other's minds. >> A signature token is far more >> secure in the absence of TLS, > > In absence of TLS the shared secret for the keyed message digest is carried to the client in clear. Why is that more secure? Kerberos doesn't use TLS and yet it works and securely exchanges keys. Ditto ABFAB. Other mechanisms could use similar techniques to get the same effect. This isn't rocket science. >> but if you'll use HTTP and cookies w/o >> TLS at all then your sessions can still be hijacked, in which case >> bearer or signature makes little difference. >> >> For me the main thing is that bearer tokens simply have no useful >> existence w/o TLS or equivalent, which means they are not applicable >> to a non-trivial class of application protocols. I.e., bearer tokens >> are less general. > > Which application protocols are you particularly talking about that cannot use TLS (or DTLS)? I gave you a list of some such protocols. >> There's also the problem that bearer tokens cannot improve server >> authentication without rototilling the HTTP/TLS stacks. > Not sure what you mean. See my exchange with Scott earlier this week. > Just as a side-note: MAC tokens do not provide server authentication As I've said before, I'm talking in general here. A proof-of-possession mechanism most certainly can provide server authentication. Nico -- From Hannes.Tschofenig@gmx.net Mon Aug 20 05:01:43 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62B721F862A for ; Mon, 20 Aug 2012 05:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 XWeipciqm-Yg for ; Mon, 20 Aug 2012 05:01:43 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D88E021F861C for ; Mon, 20 Aug 2012 05:01:42 -0700 (PDT) Received: (qmail invoked by alias); 20 Aug 2012 12:01:36 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp031) with SMTP; 20 Aug 2012 14:01:36 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/V3WgAf1HVSdfEQ/CuOKiDDNSTDwZMd0kq1mBWza EabEsvKQilyhv8 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Mon, 20 Aug 2012 15:01:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5160C7AD-55F5-4FBC-9E58-D26C60132206@gmx.net> References: To: "Cantor, Scott" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 12:01:44 -0000 Hi Scott,=20 On Aug 17, 2012, at 7:25 PM, Cantor, Scott wrote: > On 8/17/12 7:41 AM, "Hannes Tschofenig" = wrote: >>=20 >> Still, it does not make TLS a useless mechanism for the >> client-to-resource server interaction. >=20 > I consider it useless if the expectation is that the typical Web 2.0 > developer's tools will get it right. How are changes that a typical Web 2.0 developer is going to get = anything security related right. I believe I remember you saying that we have to focus on producing = libraries that do not require the Web developer to understand these = types of things. Do I remember that correctly? >=20 >> It ultimately depends on what we think different IdP providers are >> capable of providing. If we assume a model where "everyone" can run = their >> own identity provider then we have to lower our expectations about = their >> ability to configure security settings. >=20 > There's a spectrum between a billion IdPs and 6. OAuth in practice is = way > too far to the latter end for my taste. I am not sure where our discussion is heading but here are my = observations: * Sharing protected data is common these days * Providing security for this (other than sharing long-term credentials) = is also important.=20 How to get the long tail of Web developers who operate an IdP to run it = correctly is the question.=20 You are saying that they are not going to get TLS right. The problem is = only that OAuth 1.0 and OAuth 2.0 rely on TLS for the = client-to-authorization server interaction.=20 What alternatives are you suggesting?=20 >=20 > But all this is really beside the point. I'd like to return to the > original question: is there a concern about having channel binding > specified if the OAuth profile permits it? I am in favor of having channel binding in there.=20 I doubt that Web 2.0 developers will understand that value of it but = that's a different story.=20 > And more to the point, it > sounds like the real problem is that there is no OAuth 2.0 material on = the > road to standardization that will in fact support it. At the last meeting I have reinforced my desire to work on additional = OAuth 2.0 security mechanisms and I had kicked off the discussion with a = draft I had been working on.=20 Ciao Hannes >=20 > -- Scott >=20 From hannes.tschofenig@gmx.net Mon Aug 20 05:12:17 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7631621F8602 for ; Mon, 20 Aug 2012 05:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Dvd00leFSrVV for ; Mon, 20 Aug 2012 05:12:16 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 52DE921F85C6 for ; Mon, 20 Aug 2012 05:12:16 -0700 (PDT) Received: (qmail invoked by alias); 20 Aug 2012 12:12:14 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp070) with SMTP; 20 Aug 2012 14:12:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18x0+1DlZwxg2Fc7eM+WWGKu+bQK+a01sAt87MRMf unZv/JQlCneSV9 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Mon, 20 Aug 2012 15:12:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2F30A7A7-F364-44C3-893E-6590F9C63F6D@gmx.net> References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 12:12:17 -0000 Hi Nico,=20 On Aug 18, 2012, at 8:00 AM, Nico Williams wrote: > On Fri, Aug 17, 2012 at 6:11 AM, Hannes Tschofenig > wrote: >> On Aug 16, 2012, at 8:21 PM, Nico Williams wrote: >>=20 >>> On Thu, Aug 16, 2012 at 11:20 AM, William Mills = wrote: >>>> While I agree with you form a security stance, I must point out = that FB was >>>> using bearer tokens in the clear for about a year I think until the = rolled >>>> out HTTPS. People will in fact make that choice, just as they use = cookies >>>> for authorization in the clear. >>>=20 >>> Cookies themselves are a form of bearer token, but at least one can >>> set different cookies for use with HTTP vs. HTTPS. >>=20 >> I don't like this comparison with cookies to much since cookies are = quite different. >=20 > Hannes, they are like bearer tokens in the way that matters in the > context that I was discussing. I agree that there's other aspects of > cookies that make them apples to OAuth's being oranges, but that's not > relevant here. Interjecting irrelevancies into the discussion only > makes it harder to make progress. There is no mechanism for the client to request cookies. They are = exclusively used by the server to store state on the client.=20 Cookies may not need to be protected by TLS (neither set nor requested). Cookies sharing works with the same origin policy.=20 Cookies have no (technical mechanism) to obtain the consent of a = resource owner.=20 =20 >=20 >>> Bearer tokens are >>> too valuable to send without using TLS. >>=20 >> Correct. That's why the specification mandates TLS. >=20 > And that's the problem I have: I don't think any service > authentication system that must scale to all services on the web can > provide the level of security that we should want. I want security > mechanisms that support federations (retail federations, banking > federations, ...). You and I disagree fundamentally on this. At this > point it will have to be the market that proves one or both of us > wrong, because we've been at this enough that I don't think we'll > change each other's minds. I am not sure where our disagreement here is.=20 We both think that federations are desirable and OAuth allows to build a = WebSSO protocol as well (as the OpenID Connect folks are demonstrating). = I also care about scalability.=20 >=20 >>> A signature token is far more >>> secure in the absence of TLS, >>=20 >> In absence of TLS the shared secret for the keyed message digest is = carried to the client in clear. Why is that more secure? >=20 > Kerberos doesn't use TLS and yet it works and securely exchanges keys. > Ditto ABFAB. Other mechanisms could use similar techniques to get > the same effect. This isn't rocket science. When Kerberos was designed TLS didn't even exist. The comparison between = TLS and Kerberos is inappropriate anyway since TLS is a two-party and = Kerberos a three party protocol.=20 ABFAB will have to use TLS in many cases (although maybe without = server-side authentication). While I would love to see ABFAB deployed = everywhere I have my doubts that it will happen in the Web application = space.=20 >=20 >>> but if you'll use HTTP and cookies w/o >>> TLS at all then your sessions can still be hijacked, in which case >>> bearer or signature makes little difference. >>>=20 >>> For me the main thing is that bearer tokens simply have no useful >>> existence w/o TLS or equivalent, which means they are not applicable >>> to a non-trivial class of application protocols. I.e., bearer = tokens >>> are less general. >>=20 >> Which application protocols are you particularly talking about that = cannot use TLS (or DTLS)? >=20 > I gave you a list of some such protocols. Sorry; saw it a little later only.=20 >=20 >>> There's also the problem that bearer tokens cannot improve server >>> authentication without rototilling the HTTP/TLS stacks. >> Not sure what you mean. >=20 > See my exchange with Scott earlier this week. Will take a look.=20 >=20 >> Just as a side-note: MAC tokens do not provide server authentication >=20 > As I've said before, I'm talking in general here. A > proof-of-possession mechanism most certainly can provide server > authentication. I agree. However, this is not the OAuth 1.0 MAC token approach that Bill = had put into the draft but rather a version that we would be coming up = with for OAuth 2.0.=20 Ciao hannes >=20 > Nico > -- From prvs=157912e276=jaltman@secure-endpoints.com Mon Aug 20 05:39:11 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2791121F8634 for ; Mon, 20 Aug 2012 05:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.68 X-Spam-Level: X-Spam-Status: No, score=0.68 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 N3jaOO7RhXLm for ; Mon, 20 Aug 2012 05:39:10 -0700 (PDT) Received: from mail.secure-endpoints.com (rrcs-208-125-0-235.nyc.biz.rr.com [208.125.0.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0992121F8618 for ; Mon, 20 Aug 2012 05:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1345466349; x=1346071149; q=dns/txt; h=DomainKey-Signature:Received:Message-ID:Date:From: Organization:User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:OpenPGP:Content-Type:Reply-To; bh=/jOcVEkQA+v42CXTw0 j032C1pNr55MPaG50a7WP6HzI=; b=jllgQX45YscPCIGffSCjP1x57KNEssIw5/ x2yfmwChPenS8GwMeZBZAkPYETtVGru3zC9A25v3xNq/oXgXYyIUb42RrxZJDXwh ecIDqh3I8Ow+mTY9ByKrIk3JyT89a6IbZT996sX/xhwBJ+vufbY6w5Si9BSbww61 ZpEEoRGsE= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=secure-endpoints.com; c=simple; q=dns; h=message-id:from; b=bHUS35hyhsWtUefApbJnGYkkiQjLfCZdUgvhK6o43p5ET9YlPJMeOdLV7Lsy zK+YaGFPjSNKGhwWXwmWZNMCSSpiYyQg1qy0A5OvIvqmK+2jyKv6/36ZE fKFFJy+dWgNXrafoe1dFYXc6t2pm13KMB0GH5eA/WVO84g8J0v50eQ=; X-MDAV-Processed: mail.secure-endpoints.com, Mon, 20 Aug 2012 08:39:09 -0400 Received: from [172.16.16.54] by secure-endpoints.com (Cipher TLSv1:-SHA:128) (MDaemon PRO v12.5.6) with ESMTP id md50000313744.msg for ; Mon, 20 Aug 2012 08:39:09 -0400 X-Spam-Processed: mail.secure-endpoints.com, Mon, 20 Aug 2012 08:39:09 -0400 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: jaltman@secure-endpoints.com X-HashCash: 1:22:120820:md50000313744::Y/ZpnE1kwgNTjmcI:0000BFfP X-Return-Path: prvs=157912e276=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <50322FE7.6050803@secure-endpoints.com> Date: Mon, 20 Aug 2012 08:39:03 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: hannes.tschofenig@gmx.net References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> <2F30A7A7-F364-44C3-893E-6590F9C63F6D@gmx.net> In-Reply-To: <2F30A7A7-F364-44C3-893E-6590F9C63F6D@gmx.net> X-Enigmail-Version: 1.4.3 OpenPGP: url=http://pgp.mit.edu Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig226E721BAF3CEE3CD56EA955" Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 12:39:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig226E721BAF3CEE3CD56EA955 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/20/2012 8:12 AM, Hannes Tschofenig wrote: > When Kerberos was designed TLS didn't even exist. The comparison betwee= n TLS and Kerberos is inappropriate anyway since TLS is a two-party and K= erberos a three party protocol.=20 TLS is a point to point protocol. The authentication in TLS is in most cases X.509 certificates. When X.509 certificates are used, TLS involves three parties: the TLS initiator, the TLS acceptor and the Certificate Authority. When Kerberos is used to authenticate TLS or other point to point protocols, it has three parties: the initiator, the acceptor and the KDC. TLS can be authenticated with other mechanisms such as SRP which are not three party systems, pre-shared keys (PSK), etc. TLS itself is not an authentication mechanism. It is a point to point protocol that is used to add a security layer on top of a pre-existing connection. That security layer can add authentication an authentication identity or it can be bound to an authentication identity via channel bindings. Authentication methods that do not support channel bindings to a transport security protocol are of little interest to me because in my opinion they cannot securely be used to avoid man-in-the-middle attacks. Likewise, authentication methods that do not result in a shared key between the initiator and the acceptor are of little interest to me because such authentication methods cannot be used to key a transport layer. For example, providing the key to be used with TLS PSK or AFS RXG= K: https://datatracker.ietf.org/doc/draft-wilkinson-afs3-rxgk/ https://datatracker.ietf.org/doc/draft-wilkinson-afs3-rxgk-afs/ Jeffrey Altman --------------enig226E721BAF3CEE3CD56EA955 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJQMi/pAAoJENxm1CNJffh4v/UH/R78h1FjraYpSCN6cWTqLrMt T3AH8IFEn17cFeCkEciJv8/HHZ9blkoCNjQGczz5aDihnirn0+vgfxvoEVmlglFH Cs5hwQpkKj9fvdohTZ6Dw8SLXvtavD2NDAddPnt2VOP9BvSVm6MkydJQyjMaFlUB qcRDb2o8/qzrQIDBZfFfp1LAZU+iW8fbIBhok4WOzA/aDIxy1VQVmjCx06X2U9Vu CQXf40snIElnNcs3ONH5eR+tpWu3+Hqr471A+f17uc9YcjYmmDtFWd3yFJ4m8mdA rrgpuCJZaunTRNgIGuoPj29iXKUF91NK9u3jfQE1tEXOE+bVIwIpKmOCw4MPZU0= =xFXF -----END PGP SIGNATURE----- --------------enig226E721BAF3CEE3CD56EA955-- From cantor.2@osu.edu Mon Aug 20 06:39:27 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650F921F8608 for ; Mon, 20 Aug 2012 06:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 TO98Sy1ZtnHg for ; Mon, 20 Aug 2012 06:39:26 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id A87C221F84C2 for ; Mon, 20 Aug 2012 06:39:24 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7KDd9D5027774; Mon, 20 Aug 2012 09:39:20 -0400 Received: from CIO-KRC-HT03.osuad.osu.edu (164.107.81.43) by CIO-KRC-HT02.osuad.osu.edu (164.107.81.40) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 20 Aug 2012 09:39:01 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT03.osuad.osu.edu ([fe80::2572:c08d:8186:46a4%12]) with mapi id 14.02.0309.002; Mon, 20 Aug 2012 09:39:02 -0400 From: "Cantor, Scott" To: Hannes Tschofenig Thread-Topic: [kitten] OAUTH SASL and Channel binding Thread-Index: AQHNe8BSHGdoCl4WY0+O4QBdMhqIS5dcipsAgAGbZICAAAxwAIAEsDQA///YMAA= Date: Mon, 20 Aug 2012 13:39:00 +0000 Message-ID: In-Reply-To: <5160C7AD-55F5-4FBC-9E58-D26C60132206@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 13:39:27 -0000 On 8/20/12 8:01 AM, "Hannes Tschofenig" wrote: > >How are changes that a typical Web 2.0 developer is going to get anything >security related right. I believe I remember you saying that we have to >focus on producing libraries that do not require the Web developer to >understand these types of things. Do I remember that correctly? Yes. The Web 2.0 community has largely rejected that approach as far as I can tell. >How to get the long tail of Web developers who operate an IdP to run it >correctly is the question. I wouldn't let a typical web developer anywhere near an IdP (or much of anything else). If you mean the people that would operate an IdP for a typical enterprise or community, I agree, it's a problem, but I don't have anything against outsourcing such functions either. >You are saying that they are not going to get TLS right. The problem is >only that OAuth 1.0 and OAuth 2.0 rely on TLS for the >client-to-authorization server interaction. TLS isn't really the problem, it's the PKI it tends to rely on and the code that implements it. I think there are pieces of solutions around for that, but I don't think they will get traction in the environments that Web 2.0 cares about. >What alternatives are you suggesting? My alternatives have been rejected outside of my immediate community, so I'm just continuing to wait out the latest cycle of reinvention and then I'll see what comes out of the rubble. My only concern in this conversation is that if I have to be stuck eventually, as a deployer, with an OAuth solution for non-web, I'd like to see it not suck as much as possible. >At the last meeting I have reinforced my desire to work on additional >OAuth 2.0 security mechanisms and I had kicked off the discussion with a >draft I had been working on. That's good. -- Scott From hannes.tschofenig@gmx.net Mon Aug 20 06:58:51 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A407321F8510 for ; Mon, 20 Aug 2012 06:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 93d0ttdkwQKS for ; Mon, 20 Aug 2012 06:58:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B695321F84F5 for ; Mon, 20 Aug 2012 06:58:50 -0700 (PDT) Received: (qmail invoked by alias); 20 Aug 2012 13:58:49 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp028) with SMTP; 20 Aug 2012 15:58:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18qbH0QDJoqSK9idv+9vTetghGdasUWKGZwc7Ueob iO81yULFmq8NJP Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <50322FE7.6050803@secure-endpoints.com> Date: Mon, 20 Aug 2012 16:58:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3EC8A837-C13B-46AD-A349-DBF6774D494C@gmx.net> References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> <2F30A7A7-F364-44C3-893E-6590F9C63F6D@gmx.net> <50322FE7.6050803@secure-endpoints.com> To: jaltman@secure-endpoints.com X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 13:58:51 -0000 Interesting interpretation of TLS with respect to the parties.=20 But I agree nevertheless that we agree on the channel binding issue. I = have no problems with channel bindings for non-HTTP-based protocols.=20 And: Luckily we have no proposal on the table that does not lead to keys = between the the initiator and the acceptor.=20 On Aug 20, 2012, at 3:39 PM, Jeffrey Altman wrote: > On 8/20/2012 8:12 AM, Hannes Tschofenig wrote: >> When Kerberos was designed TLS didn't even exist. The comparison = between TLS and Kerberos is inappropriate anyway since TLS is a = two-party and Kerberos a three party protocol.=20 >=20 >=20 > TLS is a point to point protocol. The authentication in TLS is in = most > cases X.509 certificates. When X.509 certificates are used, TLS > involves three parties: the TLS initiator, the TLS acceptor and the > Certificate Authority. >=20 > When Kerberos is used to authenticate TLS or other point to point > protocols, it has three parties: the initiator, the acceptor and the > KDC. TLS can be authenticated with other mechanisms such as SRP which > are not three party systems, pre-shared keys (PSK), etc. >=20 > TLS itself is not an authentication mechanism. It is a point to point > protocol that is used to add a security layer on top of a pre-existing > connection. That security layer can add authentication an > authentication identity or it can be bound to an authentication = identity > via channel bindings. >=20 > Authentication methods that do not support channel bindings to a > transport security protocol are of little interest to me because in my > opinion they cannot securely be used to avoid man-in-the-middle = attacks. >=20 > Likewise, authentication methods that do not result in a shared key > between the initiator and the acceptor are of little interest to me > because such authentication methods cannot be used to key a transport > layer. For example, providing the key to be used with TLS PSK or AFS = RXGK: >=20 > https://datatracker.ietf.org/doc/draft-wilkinson-afs3-rxgk/ > https://datatracker.ietf.org/doc/draft-wilkinson-afs3-rxgk-afs/ >=20 > Jeffrey Altman >=20 >=20 From wmills@yahoo-inc.com Mon Aug 20 10:00:47 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D7321F852B for ; Mon, 20 Aug 2012 10:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.549 X-Spam-Level: X-Spam-Status: No, score=-17.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 ZEbGtTFm7O4y for ; Mon, 20 Aug 2012 10:00:46 -0700 (PDT) Received: from nm28.bullet.mail.sp2.yahoo.com (nm28.bullet.mail.sp2.yahoo.com [98.139.91.98]) by ietfa.amsl.com (Postfix) with SMTP id 2544821F852E for ; Mon, 20 Aug 2012 10:00:46 -0700 (PDT) Received: from [72.30.22.92] by nm28.bullet.mail.sp2.yahoo.com with NNFMP; 20 Aug 2012 17:00:43 -0000 Received: from [72.30.22.76] by tm14.bullet.mail.sp2.yahoo.com with NNFMP; 20 Aug 2012 16:59:43 -0000 Received: from [127.0.0.1] by omp1070.mail.sp2.yahoo.com with NNFMP; 20 Aug 2012 16:59:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 314220.43635.bm@omp1070.mail.sp2.yahoo.com Received: (qmail 50819 invoked by uid 60001); 20 Aug 2012 16:59:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345481982; bh=847z3trlQCY8RILkyJkVK/1p1OvRpr7MK5e10BgmKnE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=G6Y3ulqH1VAV9aU1zQ9BhLcwU3hHQDluJZoGgkweEwn/b1XInFd3MXKFdoNRcSlwgnRaq51F7XPFQ8JWHufAJ6qBEEWJfNY2TP5/jlhysPOBETRJyZQrkJOMQFvcfpULpRwLp7DDpiNmrfuWZT+6SGHPIkiLwPapqwxgGEeA6Gw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Gth2wLawFYDB2/vvIscWJ0crBTkl5W0qacHVYvU6QhxyNuFWOOCPBrZ2I3oWJhzMXBvvp0n95tx/1aBcniP09+ewsb6QmgZe3x1kGowEcKNKl9T8xAv76j3FTRQNOnFfZw7ZGiZqalYNluVdNbrzRC0H/kozx/U4i4jQQ/nGAKg=; X-YMail-OSG: o1fxG0UVM1ltlss5Xx41Mpk74fy.Qb0nV.q.JA876B_SZ8V AMQpA0Vb9w1O89LrzJg2B2kC6GLcRXBTI275_1A7FiSgJUUtTBEnzQv1o7d. RD9dkjkwIVR780JdBCk48kft_gLTAwm_1CqhUQ1dXKhuXes2GKJpTQAnwi20 o0j4i87PYm5SlfqSIoTTIiymFn1C8xFpYd95_FOVnZRz_jOtGmdN3QM5kXY6 4CYDfr6ebrT5p1_LwoZ8BezEAgRVij4zUNmjpaaXTKBx3uroNfdAWgccBY1p b6fSWyPD2A.WmKZhmHy1t248AzhmClOeAM8.hDSQ2.NBTOT9sqgmszUSID_i h7mYQrn9._BNm77cl7uBa1G5UITQ11EeTlyKXSPP6EdHan9lrg6VZKgrocfb YW4nqalIH1uSNbugOcsVCqOCnrzEIjiwwe2TdRZe._yE5QHPVtbkaX69qZR4 _dee7OYc- Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Mon, 20 Aug 2012 09:59:42 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> <2F30A7A7-F364-44C3-893E-6590F9C63F6D@gmx.net> Message-ID: <1345481982.39773.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Mon, 20 Aug 2012 09:59:42 -0700 (PDT) From: William Mills To: Hannes Tschofenig , Nico Williams In-Reply-To: <2F30A7A7-F364-44C3-893E-6590F9C63F6D@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: [kitten] HoK & MAC Re: SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 17:00:47 -0000 >> As I've said before, I'm talking in general here.=A0 A=0A>> proof-of-pos= session mechanism most certainly can provide server=0A>> authentication.=0A= >=0A>I=0A agree. However, this is not the OAuth 1.0 MAC token approach that= Bill =0Ahad put into the draft but rather a version that we would be comin= g up =0Awith for OAuth 2.0. =0A=0A=0AHow would an HoK scheme provide server= authentication?=A0 PKI?=A0 =0A=0A=0A=0A>________________________________= =0A> From: Hannes Tschofenig =0A>To: Nico Willia= ms =0A>Cc: Hannes Tschofenig ; William Mills ; "kitten@ietf.org" =0A>Sent: Monday, August 20, 2012 5:12 AM=0A>Subject: Re: [kitten] SA= SL OAuth - My Conclusion So Far=0A> =0A>Hi Nico, =0A>=0A>=0A>On Aug 18, 201= 2, at 8:00 AM, Nico Williams wrote:=0A>=0A>> On Fri, Aug 17, 2012 at 6:11 A= M, Hannes Tschofenig=0A>> wrote:=0A>>> On Aug 1= 6, 2012, at 8:21 PM, Nico Williams wrote:=0A>>> =0A>>>> On Thu, Aug 16, 201= 2 at 11:20 AM, William Mills wrote:=0A>>>>> While I = agree with you form a security stance, I must point out that FB was=0A>>>>>= using bearer tokens in the clear for about a year I think until the rolled= =0A>>>>> out HTTPS.=A0 People will in fact make that choice, just as they u= se cookies=0A>>>>> for authorization in the clear.=0A>>>> =0A>>>> Cookies t= hemselves are a form of bearer token, but at least one can=0A>>>> set diffe= rent cookies for use with HTTP vs. HTTPS.=0A>>> =0A>>> I don't like this co= mparison with cookies to much since cookies are quite different.=0A>> =0A>>= Hannes, they are like bearer tokens in the way that matters in the=0A>> co= ntext that I was discussing.=A0 I agree that there's other aspects of=0A>> = cookies that make them apples to OAuth's being oranges, but that's not=0A>>= relevant here.=A0 Interjecting irrelevancies into the discussion only=0A>>= makes it harder to make progress.=0A>=0A>There is no mechanism for the cli= ent to request cookies. They are exclusively used by the server to store st= ate on the client. =0A>=0A>Cookies may not need to be protected by TLS (nei= ther set nor requested).=0A>Cookies sharing works with the same origin poli= cy. =0A>Cookies have no (technical mechanism) to obtain the consent of a re= source owner. =0A>=0A>> =0A>>>> Bearer tokens are=0A>>>> too valuable to se= nd without using TLS.=0A>>> =0A>>> Correct. That's why the specification ma= ndates TLS.=0A>> =0A>> And that's the problem I have: I don't think any ser= vice=0A>> authentication system that must scale to all services on the web = can=0A>> provide the level of security that we should want.=A0 I want secur= ity=0A>> mechanisms that support federations (retail federations, banking= =0A>> federations, ...).=A0 You and I disagree fundamentally on this.=A0 At= this=0A>> point it will have to be the market that proves one or both of u= s=0A>> wrong, because we've been at this enough that I don't think we'll=0A= >> change each other's minds.=0A>=0A>I am not sure where our disagreement h= ere is. =0A>=0A>We both think that federations are desirable and OAuth allo= ws to build a WebSSO protocol as well (as the OpenID Connect folks are demo= nstrating). I also care about scalability. =0A>=0A>> =0A>>>> A signature to= ken is far more=0A>>>> secure in the absence of TLS,=0A>>> =0A>>> In absenc= e of TLS the shared secret for the keyed message digest is carried to the c= lient in clear. Why is that more secure?=0A>> =0A>> Kerberos doesn't use TL= S and yet it works and securely exchanges keys.=0A>> Ditto ABFAB.=A0 Other = mechanisms could use similar techniques to get=0A>> the same effect.=A0 Thi= s isn't rocket science.=0A>=0A>When Kerberos was designed TLS didn't even e= xist. The comparison between TLS and Kerberos is inappropriate anyway since= TLS is a two-party and Kerberos a three party protocol. =0A>=0A>ABFAB will= have to use TLS in many cases (although maybe without server-side authenti= cation). While I would love to see ABFAB deployed everywhere I have my doub= ts that it will happen in the Web application space. =0A>=0A>> =0A>>>> but = if you'll use HTTP and cookies w/o=0A>>>> TLS at all then your sessions can= still be hijacked, in which case=0A>>>> bearer or signature makes little d= ifference.=0A>>>> =0A>>>> For me the main thing is that bearer tokens simpl= y have no useful=0A>>>> existence w/o TLS or equivalent, which means they a= re not applicable=0A>>>> to a non-trivial class of application protocols.= =A0 I.e., bearer tokens=0A>>>> are less general.=0A>>> =0A>>> Which applica= tion protocols are you particularly talking about that cannot use TLS (or D= TLS)?=0A>> =0A>> I gave you a list of some such protocols.=0A>=0A>Sorry; sa= w it a little later only. =0A>=0A>> =0A>>>> There's also the problem that b= earer tokens cannot improve server=0A>>>> authentication without rototillin= g the HTTP/TLS stacks.=0A>>> Not sure what you mean.=0A>> =0A>> See my exch= ange with Scott earlier this week.=0A>=0A>Will take a look. =0A>=0A>> =0A>>= > Just as a side-note: MAC tokens do not provide server authentication=0A>>= =0A>> As I've said before, I'm talking in general here.=A0 A=0A>> proof-of= -possession mechanism most certainly can provide server=0A>> authentication= .=0A>=0A>I agree. However, this is not the OAuth 1.0 MAC token approach tha= t Bill had put into the draft but rather a version that we would be coming = up with for OAuth 2.0. =0A>=0A>Ciao=0A>hannes=0A>=0A>> =0A>> Nico=0A>> --= =0A>=0A>=0A>=0A> From internet-drafts@ietf.org Mon Aug 20 11:05:46 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1084321F8673; Mon, 20 Aug 2012 11:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5nnNOjDe+LmB; Mon, 20 Aug 2012 11:05:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE6B21F86C8; Mon, 20 Aug 2012 11:05:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120820180545.30254.90003.idtracker@ietfa.amsl.com> Date: Mon, 20 Aug 2012 11:05:45 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 18:05:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. Title : A SASL and GSS-API Mechanism for OAuth Author(s) : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-04.txt Pages : 28 Date : 2012-08-20 Abstract: OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses OAuth over the Simple Authentication and Security Layer (SASL) or the Generic Security Service Application Program Interface (GSS-API) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. Clients typically store the user's long term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a token. Tokens typically provided limited access rights and can be managed and revoked separately from the user's long-term credential (password). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wmills@yahoo-inc.com Mon Aug 20 11:13:22 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F83D21F84FC for ; Mon, 20 Aug 2012 11:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.549 X-Spam-Level: X-Spam-Status: No, score=-17.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 UYD44LIye6Yn for ; Mon, 20 Aug 2012 11:13:21 -0700 (PDT) Received: from nm9.bullet.mail.ac4.yahoo.com (nm9.bullet.mail.ac4.yahoo.com [98.139.52.206]) by ietfa.amsl.com (Postfix) with SMTP id DB51721F84C4 for ; Mon, 20 Aug 2012 11:13:20 -0700 (PDT) Received: from [98.139.52.197] by nm9.bullet.mail.ac4.yahoo.com with NNFMP; 20 Aug 2012 18:13:17 -0000 Received: from [98.139.52.167] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 20 Aug 2012 18:13:17 -0000 Received: from [127.0.0.1] by omp1050.mail.ac4.yahoo.com with NNFMP; 20 Aug 2012 18:13:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 218429.53433.bm@omp1050.mail.ac4.yahoo.com Received: (qmail 34031 invoked by uid 60001); 20 Aug 2012 18:13:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345486396; bh=FR43Gsjy336mAvbXbdlSSUeJOfoL31idYHjmdam6Rpg=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OElaS9IH+LaSzwrxomSVBCoTDrlf5d2Iv4pjuChxlI+3kea4O20WeWp8ReaBGvmPc2pnuw/y7VB0vx8cZraH6gLmaSstOGfz+Y9rH5AvhmhidNNq1pgefcHRqLz0HaVLdTNQq9bVQVzeCITKGDpQzT97PcUbtXknNMuyIZQWxzg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=eZJyWELDFngYbVdt1Ho7m6fsHiKvGhcKlDT5xSdZ0u0rOILFFZMTssqjcBae7AituQKasM+clbWRUkf4XsyNWYhYuAxkNOCTW3Ldo7daQLBtyDqom2ODnBq8s6hPbNBB99Jzg4AaSpFvQAoA1g+GZ6phJVTj5y79tYKnLWjo4CQ=; X-YMail-OSG: h7c.utUVM1lRcvAm4SxQOv2w.kyD3S1uAO9AbhIPi1p1AUn I07fbMn2RPDBZkF77TZR.ezbbmPgEqJ2dS4LTMnLWXXDA3VgoVLiRI3H4SW. kHA.p35ObmoI4HdQ4xkUxNEJHwzRWiQ64XLDVOLulH4PfdBKM1D3EZ1Q5yOC hSedu3QS.hWbIPfKjWbpkrbVVjc9D.PaU5psQNJQQ4tluUZbIMwI.1RhltzO Mi0ATc14Wswa3lNicMRlvZMHVtgtORXEee.w9rC1RS5TexCtrjvz22khn_zp ENhOnCPd4sQvh5voDhpexjHcdZfyRzIOXt5YNPVrJpBgs2mwkQSlOOgDB1PE gKcarFF7xxnCQDRu2UK1Vn5NI.VnCOhngDVCnYtigRZeokptLvAP1mzzijQv zg4.80X8513yCkmbDSKzWQJVI8C6qp2IVARqRv8w3.C_zbewzyGcTyhO6kES 9A37WvKw- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Mon, 20 Aug 2012 11:13:16 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <20120820180545.30254.90003.idtracker@ietfa.amsl.com> Message-ID: <1345486396.21231.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Mon, 20 Aug 2012 11:13:16 -0700 (PDT) From: William Mills To: "kitten@ietf.org" In-Reply-To: <20120820180545.30254.90003.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-1762804145-1345486396=:21231" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 18:13:22 -0000 --258328648-1762804145-1345486396=:21231 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Most significant changes:=0A=0A-=A0=A0=A0 MAC examples converted to OAuth 1= .0a which should take the MAC spec out of the equation for adoptability.=A0= =A0=0A-=A0=A0=A0 Defining the format for an empty message, which slightly u= pdates the ABNF.=0A=0A-bill=0A=0A=0A=0A=0A>________________________________= =0A> From: "internet-drafts@ietf.org" =0A>To: i-d= -announce@ietf.org =0A>Cc: kitten@ietf.org =0A>Sent: Monday, August 20, 201= 2 11:05 AM=0A>Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04= .txt=0A> =0A>=0A>A New Internet-Draft is available from the on-line Interne= t-Drafts directories.=0A>This draft is a work item of the Common Authentica= tion Technology Next Generation Working Group of the IETF.=0A>=0A>=A0=A0=A0= Title=A0 =A0 =A0 =A0 =A0 : A SASL and GSS-API Mechanism for OAuth=0A>=A0= =A0=A0 Author(s)=A0 =A0 =A0 : William Mills=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 Tim Showalter=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 Hannes Tschofenig=0A>=A0=A0=A0 Filename=A0 =A0 =A0 =A0 = : draft-ietf-kitten-sasl-oauth-04.txt=0A>=A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0= : 28=0A>=A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2012-08-20=0A>=0A>Abstrac= t:=0A>=A0 OAuth enables a third-party application to obtain limited access= to a=0A>=A0 protected resource, either on behalf of a resource owner by= =0A>=A0 orchestrating an approval interaction, or by allowing the third-pa= rty=0A>=A0 application to obtain access on its own behalf.=0A>=0A>=A0 Thi= s document defines how an application client uses OAuth over the=0A>=A0 Si= mple Authentication and Security Layer (SASL) or the Generic=0A>=A0 Securi= ty Service Application Program Interface (GSS-API) to access a=0A>=A0 prot= ected resource at a resource serve.=A0 Thereby, it enables schemes=0A>=A0 = defined within the OAuth framework for non-HTTP-based application=0A>=A0 p= rotocols.=0A>=0A>=A0 Clients typically store the user's long term credenti= al.=A0 This does,=0A>=A0 however, lead to significant security vulnerabili= ties, for example,=0A>=A0 when such a credential leaks.=A0 A significant b= enefit of OAuth for=0A>=A0 usage in those clients is that the password is = replaced by a token.=0A>=A0 Tokens typically provided limited access right= s and can be managed=0A>=A0 and revoked separately from the user's long-te= rm credential=0A>=A0 (password).=0A>=0A>=0A>The IETF datatracker status pa= ge for this draft is:=0A>https://datatracker.ietf.org/doc/draft-ietf-kitten= -sasl-oauth=0A>=0A>There's also a htmlized version available at:=0A>http://= tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-04=0A>=0A>A diff from the = previous version is available at:=0A>http://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-kitten-sasl-oauth-04=0A>=0A>=0A>Internet-Drafts are also available = by anonymous FTP at:=0A>ftp://ftp.ietf.org/internet-drafts/=0A>=0A>________= _______________________________________=0A>Kitten mailing list=0A>Kitten@ie= tf.org=0A>https://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> --258328648-1762804145-1345486396=:21231 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Most significant changes:

-  = ;  MAC examples converted to OAuth 1.0a which should take= the MAC spec out of the equation for adoptability.  
-    Defining the format for an empty message, which slightly updates the ABNF.=

-bill

From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
To: i-d-announce@ietf.org
Cc: kitten@ietf.org
Sent: Monday, August 20, 2012 11:05 AM
Subject: [kitten] I-D Action: draft-ietf-ki= tten-sasl-oauth-04.txt


A New Internet-Draft is a= vailable from the on-line Internet-Drafts directories.
This draft is a = work item of the Common Authentication Technology Next Generation Working G= roup of the IETF.

    Title       = ;   : A SASL and GSS-API Mechanism for OAuth
    Au= thor(s)      : William Mills
       =                   Tim Showalt= er
                          Hannes Tschofenig
    Filename = ;       : draft-ietf-kitten-sasl-oauth-04.txt
  = ;  Pages          : 28
   = Date            : 2012-08-20

Abstract= :
  OAuth enables a third-party application to obtain limited acce= ss to a
  protected resource, either on behalf of a resource owner= by
  orchestrating an approval interaction, or by allowing the th= ird-party
  application to obtain access on its own behalf.
  This document defines how an application client uses OAuth over th= e
  Simple Authentication and Security Layer (SASL) or the Generic=
  Security Service Application Program Interface (GSS-API) to acc= ess a
  protected resource at a resource serve.  Thereby, it = enables schemes
  defined within the OAuth framework for non-HTTP-based application
  protocols.

  Clients ty= pically store the user's long term credential.  This does,
  = however, lead to significant security vulnerabilities, for example,
&nbs= p; when such a credential leaks.  A significant benefit of OAuth for<= br>  usage in those clients is that the password is replaced by a tok= en.
  Tokens typically provided limited access rights and can be m= anaged
  and revoked separately from the user's long-term credenti= al
  (password).


The IETF datatracker status page for t= his draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-kitten-sasl-oauth

There's also a htmlized version available a= t:
http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-= 04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oa= uth-04


Internet-Drafts are also available by anonymous FTP a= t:
ftp= ://ftp.ietf.org/internet-drafts/

_______________________________= ________________
Kitten mailing list
Kitten@ietf.org
https://www.ie= tf.org/mailman/listinfo/kitten


<= /div>
--258328648-1762804145-1345486396=:21231-- From wmills@yahoo-inc.com Tue Aug 21 08:41:12 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740CB21F87A9 for ; Tue, 21 Aug 2012 08:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.55 X-Spam-Level: X-Spam-Status: No, score=-17.55 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 lc6WOel8oRAn for ; Tue, 21 Aug 2012 08:41:11 -0700 (PDT) Received: from nm3.bullet.mail.sp2.yahoo.com (nm3.bullet.mail.sp2.yahoo.com [98.139.91.73]) by ietfa.amsl.com (Postfix) with SMTP id 6DA9321F879D for ; Tue, 21 Aug 2012 08:41:11 -0700 (PDT) Received: from [98.139.91.68] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 21 Aug 2012 15:41:08 -0000 Received: from [98.139.91.50] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 21 Aug 2012 15:41:08 -0000 Received: from [127.0.0.1] by omp1050.mail.sp2.yahoo.com with NNFMP; 21 Aug 2012 15:41:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 680293.64158.bm@omp1050.mail.sp2.yahoo.com Received: (qmail 24042 invoked by uid 60001); 21 Aug 2012 15:41:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345563667; bh=vkAglxaj3/7yVWnREBAbWW/OZ+S4K6MZgBa28HEuF9k=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iNsug2boBjsB9b1NwpFCKJIFrWQz2S2UEL4XKox9XkdL/LcuNIPCSrxq8N3Pwlzgzat1OVnvdEHRiwC40I3cgfrWnompuz5EDKuM119dn0R7PwWdLgvQ4ri6dhDXQaMnj7JM6H4TNeqaymzE8h2nXuteTfAQnYU6dXf+3uuuKqQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=JUEFUJ84/xXyNDi8xs5v1NLYfK+nFhC3+Y9irq19YWQ6nSFkXxRq5eHIE8zC1U2shUXCk63WsxXowt6OnkNX795Oo80uCd5DfZWHbsNbZcyPpW3Uwe0fEubc2mgnThYR9rWaQ256Uw1ajupJ1Infm8mzvzbtnCigCI7q9aSKXNQ=; X-YMail-OSG: _dNaH3oVM1nW0XrturLSgck0lL8Ffdm.32xeEy.gyqOa7G6 81KQ2eJetcMhQiiFa5geKiy7FpkV53.t7CapqpbpQS0kNC.OFxTYuIwjZ0a_ tCkA7EseP5aK1HpXsdMs_PLO3rBgMRskIZFE1GSX3L6_zz1oZF_0RctJti3W bYok_er0ht0ZZta5DvAxBBA05YHrSqU.mHln94n.FoMceF5FRTFE2jURjVxm 5PP92DHBj_PvE_IyHadWB7UnN6XT_Qu7HKn9l_yKpH7zPfRggEEoWkIOqpB9 COKKxULgFi_HGTaG3hYFov9rixdvfdIfWi_QxjpQ.FFt3ABTRMVdQs5ej3wa FE.1vlnrxHUQGEhYiXNH22A7uz8y.jk_WSVoSP5zLD7UKeRvDjVkQ.a7RpVY _IJ1y7ipsJ6W5Qv_DvAI2szs.zaxZLcubbYePsAgyL8vzE75XsfHUtzeN2wf kCwRFOw-- Received: from [209.131.62.115] by web31811.mail.mud.yahoo.com via HTTP; Tue, 21 Aug 2012 08:41:07 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1345163301.61508.YahooMailNeo@web31805.mail.mud.yahoo.com> <588B67DC-7788-49DF-B303-753D4B420D3C@gmx.net> <1345482606.17400.YahooMailNeo@web31801.mail.mud.yahoo.com> <02D60FA0-45E3-4331-837A-E049029D919B@gmx.net> <1345531034.66639.YahooMailNeo@web31805.mail.mud.yahoo.com> <1345531945.23279.YahooMailNeo@web31804.mail.mud.yahoo.com> <24E6B416-8953-49A9-BDB1-73E8B482906D@gmx.net> Message-ID: <1345563667.23360.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Tue, 21 Aug 2012 08:41:07 -0700 (PDT) From: William Mills To: Hannes Tschofenig , "kitten@ietf.org" In-Reply-To: <24E6B416-8953-49A9-BDB1-73E8B482906D@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-1317262046-1345563667=:23360" Cc: Tim Showalter , Jiangang Zhang , Gil Yehuda Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:41:12 -0000 --764183289-1317262046-1345563667=:23360 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable We have a question in play.=A0 Does a SASL mechanism have to have guarantee= d compatibility or is it OK for a mechanism to discover that there are no s= hared capabilities like SSL might discover no shared cipher suites?=0A=0A-b= ill=0A=0A=0AOn Aug 21, 2012, at 9:52 AM, William Mills wrote:=0A=0A=0A>> We= ll, what the client advertises isn't interesting right?=A0 It's what the se= rver advertises.=0A>> =0A>> Is what you are saying that the only way the cl= ient can determine compatibility is via mechanism names and no other means?= =0A>> =0A>> -bill=0A>> =0A>> From: Hannes Tschofenig =0A>> To: William Mills =0A>> Cc: Hannes Tschof= enig ; Tim Showalter ; Gil Yehuda= ; Jiangang Zhang ; Ryan Troll =0A>> Sent: Monday, August 20, 2012 11:46 PM=0A>> Subjec= t: Re: OAuth SASL draft -04=0A>> =0A>> I don't think that such an approach = would work. =0A>> =0A>> If the SASL client indicates "OAUTH" in the SASL ne= gotiation then that currently means that parts of the specification is impl= emented. =0A>> =0A>> For example: If the SASL client and the SASL server in= dicate "OAUTH" and the client only implements bearer and the server side on= ly supports OAuth 1.0 MAC token then of course it will fail but the client = wouldn't figure out why. I don't think that this is=A0 particularly nice de= veloper/user experience. =0A>> =0A>> On Aug 21, 2012, at 9:37 AM, William M= ills wrote:=0A>> =0A>> > Nothing is mandatory to implement.=A0 The client m= ay discover that it can't complete.=A0 The error message will indicated sup= ported schemes, as will discovery information out of band.=0A>> > =0A>> > = =0A>> > From: Hannes Tschofenig =0A>> > To: Will= iam Mills =0A>> > Cc: Hannes Tschofenig ; Tim Showalter ; Gil Yehuda ; Jiangang Zhang ; Ryan Troll =0A>> > Sent: Monday, August 20, 2012 11:18 PM=0A>> > Subject: Re: OAuth = SASL draft -04=0A>> > =0A>> > But how are you then going to discover what f= unctionality the two SASL endpoints provide without having to implement OAu= th 1.0 and OAuth 2.0 in both the SASL client and SASL server? =0A>> > =0A>>= > You may remember our recent discussion about this design aspect.=0A>> > = =0A>> > On Aug 20, 2012, at 8:10 PM, William Mills wrote:=0A>> > =0A>> > > = I thought about that.=A0 It's simpler, but the way it is now requires no ne= w SASL definitions to support a new token scheme and I really like that fle= xibility.=0A>> > > =0A>> > > A thing I kind of don't like is that it's two = layers of capability discovery, the SASL advertisement and then the scheme = list, but in fact we need out of band discovery anyway which will for the m= ost part replace the scheme list in the error message in mechanism.=0A>> > = > =0A>> > > =0A>> > > From: Hannes Tschofenig = =0A>> > > To: William Mills =0A>> > > Cc: Hannes Tsc= hofenig ; Tim Showalter ; Gil Yeh= uda ; Jiangang Zhang ; Ryan Troll = =0A>> > > Sent: Monday, August 20, 2012 9:55 AM=0A>> = > > Subject: Re: OAuth SASL draft -04=0A>> > > =0A>> > > Hi Bill, =0A>> > >= =0A>> > > thanks for the update. =0A>> > > =0A>> > > When reading through = the draft I noticed one aspect. Currently, you are specifying two SASL mech= anisms, namely two SASL mechanisms "OAUTH" and "OAUTH-PLUS". "OAUTH-PLUS" a= dds channel binding. =0A>> > > =0A>> > > In our discussions we were, howeve= r, separating the OAuth 1.0 MAC token from the OAuth 2.0 Bearer Token appro= ach and I was wondering one should register more SASL mechanisms to take ad= vantage of the negotiation capabilities (since currently a client software = has to implement OAuth 1.0 MAC tokens and OAuth 2.0 Bearer Tokens since the= re is only a single "OAUTH" SASL mechanism. =0A>> > > =0A>> > > I would reg= ister: =0A>> > > =0A>> > > * "OAUTH-1.0-MAC" (and=A0 "OAUTH-1.0-MAC-CB") = =0A>> > > * "OAUTH-2.0-BEARER" (and=A0 "OAUTH-2.0-BEARER-CB")=0A>> > > =0A>= > > > Does this make sense to you? =0A>> > > =0A>> > > Ciao=0A>> > > Hannes= =0A>> > > =0A>> > > =0A>> > > =0A>> > > On Aug 17, 2012, at 3:28 AM, Willia= m Mills wrote:=0A>> > > =0A>> > > > All:=0A>> > > > =0A>> > > > I'm getting= close to the and of some significant changes (see the changelog near the e= nd fo the doc).=A0 I'd appreciate any time you can put on this to do a quic= k review before I submit another draft to the WG.=A0 Anything from spelling= errors to fatal flaws you find...=0A>> > > > =0A>> > > > Thanks,=0A>> > > = > =0A>> > > > -bill=0A>> > > > =0A>> > > > =0A>> > > =0A>> > > =0A>> > > = =0A>> > =0A>> > =0A>> > =0A>> =0A>> =0A>> =0A>=0A>=0A>=0A> --764183289-1317262046-1345563667=:23360 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
We have a question in play.  Does a SASL mechanism have to have guar= anteed compatibility or is it OK for a mechanism to discover that there are= no shared capabilities like SSL might discover no shared cipher suites?

= -bill


On Aug 21, 2012, at 9:52 AM, Willia= m Mills wrote:

> Well, what the client advertises isn't int= eresting right?  It's what the server advertises.
>
> Is = what you are saying that the only way the client can determine compatibilit= y is via mechanism names and no other means?
>
> -bill
>=
> From: Hannes Tschofenig <hannes.tschofenig@gmx.net>= ;
> To: William Mills <wmills@yahoo-inc.com>
> = Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>;= Tim Showalter <tjs@psaux.com>; Gil Yehuda <gyehuda@yahoo-inc.co= m>; Jiangang Zhang <jz@yahoo-inc.com>; Ryan Troll <rt= roll@googlers.com>
> Sent: Monday, August 20, 2012 11:46 PM> Subject: Re: OAuth SASL draft -04
>
> I don't think tha= t such an approach would work.
>
> If the SASL client indicates "OAUTH" in the = SASL negotiation then that currently means that parts of the specification = is implemented.
>
> For example: If the SASL client and the S= ASL server indicate "OAUTH" and the client only implements bearer and the s= erver side only supports OAuth 1.0 MAC token then of course it will fail bu= t the client wouldn't figure out why. I don't think that this is  part= icularly nice developer/user experience.
>
> On Aug 21, 2012,= at 9:37 AM, William Mills wrote:
>
> > Nothing is mandator= y to implement.  The client may discover that it can't complete. = The error message will indicated supported schemes, as will discovery info= rmation out of band.
> >
> >
> > From: Hannes = Tschofenig <hannes.tschofenig@gmx.net>
> > To: William Mills <wmills@yahoo-inc.com>
> >= Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>= ; Tim Showalter <tjs@psaux.com>; Gil Yehuda <gyehuda@yahoo-inc.c= om>; Jiangang Zhang <jz@yahoo-inc.com>; Ryan Troll <rt= roll@googlers.com>
> > Sent: Monday, August 20, 2012 11:18= PM
> > Subject: Re: OAuth SASL draft -04
> >
> &g= t; But how are you then going to discover what functionality the two SASL e= ndpoints provide without having to implement OAuth 1.0 and OAuth 2.0 in both the SASL clien= t and SASL server?
> >
> > You may remember our recent = discussion about this design aspect.
> >
> > On Aug 20, = 2012, at 8:10 PM, William Mills wrote:
> >
> > > I th= ought about that.  It's simpler, but the way it is now requires no new= SASL definitions to support a new token scheme and I really like that flex= ibility.
> > >
> > > A thing I kind of don't like = is that it's two layers of capability discovery, the SASL advertisement and= then the scheme list, but in fact we need out of band discovery anyway whi= ch will for the most part replace the scheme list in the error message in m= echanism.
> > >
> > >
> > > From: Han= nes Tschofenig <hannes.tschofenig@gmx.net>= ;
> > > To: William Mills <wmills@yahoo-inc.com>=
> > > Cc: Hannes Tschofenig <hannes.tschofe= nig@gmx.net>; Tim Showalter <tjs@psaux.com>; Gil Yehuda <= gyehuda@yahoo-inc.com>; Jiangang Zhang <jz@yahoo-inc.com>; Ry= an Troll <rtroll@googlers.com>
> > > Sent: Monday= , August 20, 2012 9:55 AM
> > > Subject: Re: OAuth SASL draft -= 04
> > >
> > > Hi Bill,
> > >
> > > tha= nks for the update.
> > >
> > > When reading thro= ugh the draft I noticed one aspect. Currently, you are specifying two SASL = mechanisms, namely two SASL mechanisms "OAUTH" and "OAUTH-PLUS". "OAUTH-PLU= S" adds channel binding.
> > >
> > > In our discu= ssions we were, however, separating the OAuth 1.0 MAC token from the OAuth = 2.0 Bearer Token approach and I was wondering one should register more SASL= mechanisms to take advantage of the negotiation capabilities (since curren= tly a client software has to implement OAuth 1.0 MAC tokens and OAuth 2.0 B= earer Tokens since there is only a single "OAUTH" SASL mechanism.
> = > >
> > > I would register:
> > >
> = > > * "OAUTH-1.0-MAC" (and  "OAUTH-1.0-MAC-CB")
> > &g= t; * "OAUTH-2.0-BEARER" (and  "OAUTH-2.0-BEARER-CB")
> > >
> > > Does this make sense to you?
> > &g= t;
> > > Ciao
> > > Hannes
> > >
&= gt; > >
> > >
> > > On Aug 17, 2012, at 3:2= 8 AM, William Mills wrote:
> > >
> > > > All:> > > >
> > > > I'm getting close to the and = of some significant changes (see the changelog near the end fo the doc).&nb= sp; I'd appreciate any time you can put on this to do a quick review before= I submit another draft to the WG.  Anything from spelling errors to f= atal flaws you find...
> > > >
> > > > Thank= s,
> > > >
> > > > -bill
> > > &= gt;
> > > > <draft-ietf-kitten-sasl-oauth-04.html><= ;draft-ietf-kitten-sasl-oauth-04.xml>
> > >
> > &g= t;
> > >
> >
> >
> >
>
>
>



--764183289-1317262046-1345563667=:23360-- From simon@josefsson.org Tue Aug 21 12:16:18 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B54321F86FE for ; Tue, 21 Aug 2012 12:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 umcMa2efSYcf for ; Tue, 21 Aug 2012 12:16:18 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id C844E21F86E4 for ; Tue, 21 Aug 2012 12:16:15 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7LJG4uP022367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Aug 2012 21:16:06 +0200 From: Simon Josefsson To: William Mills References: <1345163301.61508.YahooMailNeo@web31805.mail.mud.yahoo.com> <588B67DC-7788-49DF-B303-753D4B420D3C@gmx.net> <1345482606.17400.YahooMailNeo@web31801.mail.mud.yahoo.com> <02D60FA0-45E3-4331-837A-E049029D919B@gmx.net> <1345531034.66639.YahooMailNeo@web31805.mail.mud.yahoo.com> <1345531945.23279.YahooMailNeo@web31804.mail.mud.yahoo.com> <24E6B416-8953-49A9-BDB1-73E8B482906D@gmx.net> <1345563667.23360.YahooMailNeo__20929.0090752349$1345563689$gmane$org@web31811.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120821:tjs@psaux.com::LNPy2w6zsj1+xvLx:0DVC X-Hashcash: 1:22:120821:kitten@ietf.org::NmXmor9qSmRj9XzE:14Lz X-Hashcash: 1:22:120821:hannes.tschofenig@gmx.net::LvtyPPfRHaTDcDwM:+1D X-Hashcash: 1:22:120821:wmills@yahoo-inc.com::j33UQiEm5LfLYxP3:2/sY X-Hashcash: 1:22:120821:gyehuda@yahoo-inc.com::avNVvf3ZcfZZZCXu:1H/r X-Hashcash: 1:22:120821:jz@yahoo-inc.com::CDqdS1rfzLofv2Si:UL0g Date: Tue, 21 Aug 2012 21:16:01 +0200 In-Reply-To: <1345563667.23360.YahooMailNeo__20929.0090752349$1345563689$gmane$org@web31811.mail.mud.yahoo.com> (William Mills's message of "Tue, 21 Aug 2012 08:41:07 -0700 (PDT)") Message-ID: <87boi4gioe.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" , Tim Showalter , Jiangang Zhang , Gil Yehuda Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 19:16:18 -0000 William Mills writes: > We have a question in play.  Does a SASL mechanism have to have > guaranteed compatibility or is it OK for a mechanism to discover that > there are no shared capabilities like SSL might discover no shared > cipher suites? SASL mechanisms can fail for any reason. RFC 4422: The outcome is not successful if - the authentication exchange failed for any reason, The application can retry in this situation. However, this is not always well supported by applications, but if mechanisms starts to fail when attempted, those bugs will be noticed and fixed. /Simon From wmills@yahoo-inc.com Tue Aug 21 12:30:19 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B3921F869D for ; Tue, 21 Aug 2012 12:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.551 X-Spam-Level: X-Spam-Status: No, score=-17.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 6h6DJjfhr61z for ; Tue, 21 Aug 2012 12:30:18 -0700 (PDT) Received: from nm10-vm0.bullet.mail.ac4.yahoo.com (nm10-vm0.bullet.mail.ac4.yahoo.com [98.139.53.194]) by ietfa.amsl.com (Postfix) with SMTP id 2FFD921F86A4 for ; Tue, 21 Aug 2012 12:30:17 -0700 (PDT) Received: from [98.139.52.188] by nm10.bullet.mail.ac4.yahoo.com with NNFMP; 21 Aug 2012 19:30:14 -0000 Received: from [98.139.52.130] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 21 Aug 2012 19:30:14 -0000 Received: from [127.0.0.1] by omp1013.mail.ac4.yahoo.com with NNFMP; 21 Aug 2012 19:30:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 869559.56100.bm@omp1013.mail.ac4.yahoo.com Received: (qmail 24079 invoked by uid 60001); 21 Aug 2012 19:30:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345577414; bh=qbD9vSEgpCA6c8bBJ+qjMQ9BTlXDhnW+/TJkPEj37lk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Ikd4a0Ii4Oy4COh77p06lfXRGOJkXhE1B9K6Y9QS2TXumlkB9BNXfNkyuVYOVxjgJGGJNbRdqQAsn0VuLfaBZXsNWRZPDG+ROrVq9n5+hGAA9409+MHr7XfbK818/DPuWIAr+6t66gV2BS/hN+fHIdIiBHIpcgxPLF1sYKSmJXg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Sir/50UdRErTzk8b6eVhtwEZFi/Fx352DmcpX/cRhV9+5jgFXZaykFGn63hlH1Sq3wK3wtx6l7/XwpVCS+d/fQTxVKAdEqJN6tic31IKZ78DbDWwWgPfcglrWiDx3FGVxkZFQILGKL544BrGBPmXnS0ulgK2rhBsAvt5ujZyXuw=; X-YMail-OSG: rMYFz78VM1kpxYHPGXUV64JhbnXZwIEbUtXmp5oWwat459C 0cp_IMns0kHlKxaM1E9T1molAeGV1sYf8nCK_rkYu8UnZRtzYIEbCBuWQ0TX n5P0wLHLH47Q9aIplcid41HQi.nZr0.KIt2uF6leZhWPGNDGWGr5sci25p9G TlMx6hS0O0yNIG1JArw1bMZgJk_Rsc1iLX3I5ERFExgabToLMqJ3jgBjp5KA cBIrguy4f0t0GeKDpIELOoocjEkEJ4w6VlFVoSw4V2r9TwIc1QPak2.0sVnC YLcCqPxGYyMYQlAxuvkCrKsTN4mOLtyW6Th2EHammy8owYIeADYfBfgasO_n mzihUToUOEjVDc9nsZPiAK0fwzGrN5zXigOWeZr9iNIquCjzmQs3fxJ5U1Jp MPSdUiiQn.9yIehEpeMIe75UmVbKPjo35n0ZWP.IV6iejamUfwFE1qXRPf8k Q6SwXZxs- Received: from [209.131.62.113] by web31807.mail.mud.yahoo.com via HTTP; Tue, 21 Aug 2012 12:30:14 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1345163301.61508.YahooMailNeo@web31805.mail.mud.yahoo.com> <588B67DC-7788-49DF-B303-753D4B420D3C@gmx.net> <1345482606.17400.YahooMailNeo@web31801.mail.mud.yahoo.com> <02D60FA0-45E3-4331-837A-E049029D919B@gmx.net> <1345531034.66639.YahooMailNeo@web31805.mail.mud.yahoo.com> <1345531945.23279.YahooMailNeo@web31804.mail.mud.yahoo.com> <24E6B416-8953-49A9-BDB1-73E8B482906D@gmx.net> <1345563667.23360.YahooMailNeo__20929.0090752349$1345563689$gmane$org@web31811.mail.mud.yahoo.com> <87boi4gioe.fsf@latte.josefsson.org> Message-ID: <1345577414.18810.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Tue, 21 Aug 2012 12:30:14 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87boi4gioe.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-1182202612-1345577414=:18810" Cc: "kitten@ietf.org" , Tim Showalter , Jiangang Zhang , Gil Yehuda Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 19:30:19 -0000 ---125733401-1182202612-1345577414=:18810 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Interesting.=A0 In the Cyrus SASL implementation I've been working on I was= thinking that the appropriate result would be one of:=0A=0A#define SASL_BA= DSERV=A0=A0=A0 -10=A0 /* server failed mutual authentication step */=0A#def= ine SASL_WRONGMECH=A0 -11=A0 /* mechanism doesn't support requested feature= */=0A=0A=0AMy preference is probably a "wrong mechanism" indication. =0A= =0A=0A=0A=0A>________________________________=0A> From: Simon Josefsson =0A>To: William Mills =0A>Cc: Hann= es Tschofenig ; "kitten@ietf.org" ; Tim Showalter ; Jiangang Zhang ; Gil = Yehuda =0A>Sent: Tuesday, August 21, 2012 12:16 PM= =0A>Subject: Re: OAuth SASL draft -04=0A> =0A>William Mills writes:=0A>=0A>> We have a question in play.=A0 Does a SASL mechani= sm have to have=0A>> guaranteed compatibility or is it OK for a mechanism t= o discover that=0A>> there are no shared capabilities like SSL might discov= er no shared=0A>> cipher suites?=0A>=0A>SASL mechanisms can fail for any re= ason.=A0 RFC 4422:=0A>=0A>=A0 The outcome is not successful if=0A>=0A>=A0 = =A0 =A0 -=A0 the authentication exchange failed for any reason,=0A>=0A>The = application can retry in this situation.=A0 However, this is not=0A>always = well supported by applications, but if mechanisms starts to fail=0A>when at= tempted, those bugs will be noticed and fixed.=0A>=0A>/Simon=0A>=0A>=0A> ---125733401-1182202612-1345577414=:18810 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Interesting.  In the Cyrus SASL implementation I've been working on = I was thinking that the appropriate result would be one of:

#define= SASL_BADSERV    -10  /* server failed mutual authentic= ation step */
#define SASL_WRONGMECH  -11  /* mechanism doesn'= t support requested feature */

My pre= ference is probably a "wrong mechanism" indication.
<= br>
= From: Simon Josefsson <= simon@josefsson.org>
To: William Mills <wmills@yahoo-inc.com>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>;= "kitten@ietf.org" <kitten@ietf.org>; Tim Showalter <tjs@psaux.com= >; Jiangang Zhang <jz@yahoo-inc.com>; Gil Yehuda <gyehuda@yahoo= -inc.com>
Sent: Tu= esday, August 21, 2012 12:16 PM
S= ubject: Re: OAuth SASL draft -04

William = Mills <wmills@yahoo-inc.com> writes:

> We have a q= uestion in play.  Does a SASL mechanism have to have
> guarantee= d compatibility or is it OK for a mechanism to discover that
> there = are no shared capabilities like SSL might discover no shared
> cipher= suites?

SASL mechanisms can fail for any reason.  RFC 4422:
  The outcome is not successful if

      -  the authentication exchange failed for any reason,

The appl= ication can retry in this situation.  However, this is not
always w= ell supported by applications, but if mechanisms starts to fail
when att= empted, those bugs will be noticed and fixed.

/Simon


---125733401-1182202612-1345577414=:18810-- From nico@cryptonector.com Tue Aug 21 15:03:13 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10C521F8682 for ; Tue, 21 Aug 2012 15:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.08 X-Spam-Level: X-Spam-Status: No, score=-3.08 tagged_above=-999 required=5 tests=[AWL=-1.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 xgTYY2ZqRI-w for ; Tue, 21 Aug 2012 15:03:13 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id EDEDB21F8681 for ; Tue, 21 Aug 2012 15:03:12 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 818B8318071 for ; Tue, 21 Aug 2012 15:03:12 -0700 (PDT) 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; s=cryptonector.com; bh=tu7PlZ5CZ78aE7s6N6PA 51cNV1Y=; b=Hew2GGD835Z68WGuhPSLSPezoFqafV5SUlBkHLJjalx2oagKD7oI SD0Z7+C7EIxORHtiYUiZeq/ztSKnIT5P6oEmNDRS6L1X1lfECtJl59n2oiYtHmq6 aifJC4UIicGaGGezhRWeEupwFrUHxAuzNP+2lBuHYlbm5zxi1AIjz/A= Received: from mail-vc0-f172.google.com (mail-vc0-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-a89.g.dreamhost.com (Postfix) with ESMTPSA id 4E9BC318065 for ; Tue, 21 Aug 2012 15:03:12 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so359141vcb.31 for ; Tue, 21 Aug 2012 15:03:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.182.35 with SMTP id eb3mr4465779vec.42.1345586591617; Tue, 21 Aug 2012 15:03:11 -0700 (PDT) Received: by 10.220.103.70 with HTTP; Tue, 21 Aug 2012 15:03:11 -0700 (PDT) In-Reply-To: References: <5160C7AD-55F5-4FBC-9E58-D26C60132206@gmx.net> Date: Tue, 21 Aug 2012 17:03:11 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 22:03:13 -0000 On Mon, Aug 20, 2012 at 8:39 AM, Cantor, Scott wrote: > My alternatives have been rejected outside of my immediate community, so > I'm just continuing to wait out the latest cycle of reinvention and then > I'll see what comes out of the rubble. My only concern in this > conversation is that if I have to be stuck eventually, as a deployer, with > an OAuth solution for non-web, I'd like to see it not suck as much as > possible. We can only have so many cycles of suck before we decide to do something different, no? I'm not optimistic about this cycle. And yet HTTP/2.0 *is* the best opportunity we'll have in a while *if* HTTP/2.0 really does gain momentum, and the bigger the changes in HTTP/2.0 the more we can justify on the security side (OTOH, the bigger the changes, the bigger the chance of failure or exhaustion that leaves security unchanged). But there is a way to make this happen: make implementations available as a first step. It may well be that nothing else helps. Nico -- From simon@josefsson.org Tue Aug 21 15:37:30 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62F221F84E4 for ; Tue, 21 Aug 2012 15:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 4VD-rfEjbd1k for ; Tue, 21 Aug 2012 15:37:30 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id AE2F921F84DC for ; Tue, 21 Aug 2012 15:37:29 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7LMbOOR032043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 22 Aug 2012 00:37:25 +0200 From: Simon Josefsson To: kitten@ietf.org References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120821:kitten@ietf.org::mx81OOpXYdjkZR4U:1lZH X-Hashcash: 1:22:120821:internet-drafts@ietf.org::HzFyfsObzMykz1aw:Geo4 X-Hashcash: 1:22:120821:i-d-announce@ietf.org::C5QNHFY8a3h9OijG:tKT5 Date: Wed, 22 Aug 2012 00:37:20 +0200 In-Reply-To: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Mon, 20 Aug 2012 11:05:45 -0700") Message-ID: <87fw7fg9cv.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 22:37:31 -0000 Thanks for the update! Client responses are a key/value pair sequence. The initial client response includes a gs2-header as defined in GSS-API [RFC5801], which ^^^^^^^ <- should be GS2 carries the authorization ID as a hint. These key/value pairs carry the equivalent values from an HTTP context in order to be able to complete an OAuth style HTTP authorization. The client MUST send an ^^^^ authorization ID in the gs2-header. The server MAY use this as a routing or database lookup hint. The server MUST NOT use this as authoritative, the user name MUST be asserted by the OAuth credential. This MUST seems unusual -- the authorization identity in SASL is typically not related to the authentication process, it is a server application specific username like "admin" or "joe". Most SASL clients do not specify an authorization identity, but instead let the server map the authentication identity to an authorization identity. Wouldn't be possible to support this here too? Let the client leave the authorization identity field empty, and let the server compare the OAuth credential to see if it permits access as the authorization identity. If you need to transfer an OAuth identity hint, I'm thinking that would belong in a separate field rather than overloading the authorization identity. I don't think the OAuth 1.x "token" value is comparable to an authorization identity. Further, in section 4 you need to describe how the gs2-header is removed from the initial context token when the protocol is used as a GSS-API mechanism. Compare text like this in RFC 6595: a) the GS2 header on the client's first message and channel-binding data are excluded when SAML is used as a GSS-API mechanism, and /Simon From wmills@yahoo-inc.com Tue Aug 21 15:55:22 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806B021F8620 for ; Tue, 21 Aug 2012 15:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.552 X-Spam-Level: X-Spam-Status: No, score=-17.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 weH39+xZP2xk for ; Tue, 21 Aug 2012 15:55:21 -0700 (PDT) Received: from nm17-vm0.bullet.mail.ac4.yahoo.com (nm17-vm0.bullet.mail.ac4.yahoo.com [98.139.53.208]) by ietfa.amsl.com (Postfix) with SMTP id 8068421F861F for ; Tue, 21 Aug 2012 15:55:20 -0700 (PDT) Received: from [98.139.52.191] by nm17.bullet.mail.ac4.yahoo.com with NNFMP; 21 Aug 2012 22:55:13 -0000 Received: from [98.139.52.161] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 21 Aug 2012 22:55:13 -0000 Received: from [127.0.0.1] by omp1044.mail.ac4.yahoo.com with NNFMP; 21 Aug 2012 22:55:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 564369.52847.bm@omp1044.mail.ac4.yahoo.com Received: (qmail 83239 invoked by uid 60001); 21 Aug 2012 22:55:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345589713; bh=aY+j97p9ezHGhhPU0UOI38uVd8QtppBHHKUOzmPc0Uo=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=q+WTw+SIjSZdj10Yi51Bz7/qXm/tQeBnt9XMSVFDoYOhYE9gsY5d722dcIXZKthZb26Q4gCGH49Q3pKsUzMlkQ610sFJ/HImshh0VFpgfkx0DllS/7jga3ZLVCuS0qZwxUm0N84sqmQgkVQpZ4GTmFHUBesZsveOoONeWzDi+lU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bh9SHTPs3kW8KM91HGA5qWz/ran6QPrCeDDBIAwZ4ga6qJkKOFr+1Q1aqWs/mSAzJw2t+Lfu1kfkZ8R0xl3Qzu5woNDUrrTwTt189NzeIp0asy83alL1lUbr8ikg0rlmPR6KGZEBwpOuqBjGKhIWrraej10bK5NwgIiEVswXJW8=; X-YMail-OSG: MtEmZXEVM1k7RJ.Pm1e9DHS6hXqYtTYrWlpuuQOZsxW8hfk kX_kD6o64GYcl0VW1XXPoUYuh8p6fsjBV23E4xzwGHd8dgz.DKw1Ng6Pk6Jx 7Ymd7egMRUUHRRW_UkG5e0W5cE7YftI.eEkqeRJ7SvPaUD0Bdo92ccXxzO9m gsCrMB1AhzmAAZ34PdA42VfmRlBT5dcIQb0Bb5rcEzuMSFN8cyjKYDha_PG2 .zslJbHnL0PQCrAGRXN62dKB6grtjOXtOdeatiHGJUGlYCm0gZS11yt1rx3p yVygdmCi1.oNNRNiOkYmin3DylgRyKSZKnHcPBY00JbB6gUpWVfnHE4bk0DJ 5AdmgjbFh4IMCHMngKRob0VN942LWyX8kgnPLN8Pxf0037duXzH8ZfIix3GD n1JhqJ34xS5EX1a1xInXDGjtT2Tbxy5T7g4rtDr7l39TlvYupgkgiGIztF6z CTFFoxw-- Received: from [209.131.62.113] by web31811.mail.mud.yahoo.com via HTTP; Tue, 21 Aug 2012 15:55:13 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> Message-ID: <1345589713.70741.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Tue, 21 Aug 2012 15:55:13 -0700 (PDT) From: William Mills To: Simon Josefsson , "kitten@ietf.org" In-Reply-To: <87fw7fg9cv.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 22:55:22 -0000 =0A=0AFixed the GSS-API ref to GS2.=A0 The MUST is because we want the clie= nt to =0A=0Aalways send a user ID as a routing hint to the server.=A0 We do= specifically=0Asay that the authZ ID must be derived form the credential i= tself.=0A=0A=0AWe had put a "user" field back in, but dropped it in favor o= f the gs2-header=0Asince it's duplicate info.=A0 The gs2 header becomes par= t of the protocol at=0Aall times.=0A=0A-bill=0A=0A=0A>_____________________= ___________=0A> From: Simon Josefsson =0A>To: kitten@i= etf.org =0A>Sent: Tuesday, August 21, 2012 3:37 PM=0A>Subject: Re: [kitten]= I-D Action: draft-ietf-kitten-sasl-oauth-04.txt=0A> =0A>Thanks for the upd= ate!=0A>=0A>=A0=A0=A0Client responses are a key/value pair sequence.=A0 The= initial client=0A>=A0=A0=A0response includes a gs2-header as defined in GS= S-API [RFC5801], which=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^ <- should be GS2=0A= >=A0=A0=A0carries the authorization ID as a hint.=A0 These key/value pairs = carry=0A>=A0=A0=A0the equivalent values from an HTTP context in order to be= able to=0A>=A0=A0=A0complete an OAuth style HTTP authorization.=A0 The cli= ent MUST send an=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0^^^^=0A>= =A0=A0=A0authorization ID in the gs2-header.=A0 The server MAY use this as = a=0A>=A0=A0=A0routing or database lookup hint.=A0 The server MUST NOT use t= his as=0A>=A0=A0=A0authoritative, the user name MUST be asserted by the OAu= th=0A>=A0=A0=A0credential.=0A>=0A>This MUST seems unusual -- the authorizat= ion identity in SASL is=0A>typically not related to the authentication proc= ess, it is a server=0A>application specific username like "admin" or "joe".= =A0 Most SASL clients=0A>do not specify an authorization identity, but inst= ead let the server map=0A>the authentication identity to an authorization i= dentity.=A0 Wouldn't be=0A>possible to support this here too?=A0 Let the cl= ient leave the=0A>authorization identity field empty, and let the server co= mpare the OAuth=0A>credential to see if it permits access as the authorizat= ion identity.=0A>If you need to transfer an OAuth identity hint, I'm thinki= ng that would=0A>belong in a separate field rather than overloading the aut= horization=0A>identity.=A0 I don't think the OAuth 1.x "token" value is com= parable to an=0A>authorization identity.=0A>=0A>Further, in section 4 you n= eed to describe how the gs2-header is removed=0A>from the initial context t= oken when the protocol is used as a GSS-API=0A>mechanism.=A0 Compare text l= ike this in RFC 6595:=0A>=0A>=A0=A0=A0a)=A0 the GS2 header on the client's = first message and channel-binding=0A>=A0 =A0 =A0=A0=A0data are excluded whe= n SAML is used as a GSS-API mechanism, and=0A>=0A>/Simon=0A>_______________= ________________________________=0A>Kitten mailing list=0A>Kitten@ietf.org= =0A>https://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> From simon@josefsson.org Tue Aug 21 16:03:57 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E2221F86BD for ; Tue, 21 Aug 2012 16:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 sPGq8mamLemB for ; Tue, 21 Aug 2012 16:03:57 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id E81DE21F8646 for ; Tue, 21 Aug 2012 16:03:56 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7LN3iKh001199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Aug 2012 01:03:46 +0200 From: Simon Josefsson To: William Mills References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345589713.70741.YahooMailNeo@web31811.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120821:kitten@ietf.org::LArFYt14Lrrwt5EK:B5bE X-Hashcash: 1:22:120821:wmills@yahoo-inc.com::qyJSe4LZdohIFchD:049PB Date: Wed, 22 Aug 2012 01:03:41 +0200 In-Reply-To: <1345589713.70741.YahooMailNeo@web31811.mail.mud.yahoo.com> (William Mills's message of "Tue, 21 Aug 2012 15:55:13 -0700 (PDT)") Message-ID: <877gsrg84y.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 23:03:57 -0000 William Mills writes: > Fixed the GSS-API ref to GS2.  The MUST is because we want the client to > > always send a user ID as a routing hint to the server.  We do specifically > say that the authZ ID must be derived form the credential itself. I'm confused -- how does a SASL OAuth client specify that it wants to logon as the "joe" user on an IMAP server? Normally in SASL the client would put "joe" in the authorization identity, and the server would verify whether the authenticated user is permitted to access the "joe" account. > We had put a "user" field back in, but dropped it in favor of the gs2-header > since it's duplicate info.  The gs2 header becomes part of the protocol at > all times. Then the SASL OAuth mechanism is not wire-compatible with the GSS-API OAuth mechanism. I believe we want wire-compatibility. /Simon From wmills@yahoo-inc.com Tue Aug 21 16:17:07 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5276411E8091 for ; Tue, 21 Aug 2012 16:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.553 X-Spam-Level: X-Spam-Status: No, score=-17.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 Sgql6TSTHoLI for ; Tue, 21 Aug 2012 16:17:06 -0700 (PDT) Received: from nm14-vm4.bullet.mail.ne1.yahoo.com (nm14-vm4.bullet.mail.ne1.yahoo.com [98.138.91.174]) by ietfa.amsl.com (Postfix) with SMTP id 8870711E808D for ; Tue, 21 Aug 2012 16:17:06 -0700 (PDT) Received: from [98.138.90.49] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 21 Aug 2012 23:17:01 -0000 Received: from [98.138.89.198] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 21 Aug 2012 23:17:01 -0000 Received: from [127.0.0.1] by omp1056.mail.ne1.yahoo.com with NNFMP; 21 Aug 2012 23:17:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 910116.10161.bm@omp1056.mail.ne1.yahoo.com Received: (qmail 2304 invoked by uid 60001); 21 Aug 2012 23:17:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345591021; bh=VkMqWOj5rlnp6oncge9qLDZUFexCpQhrM6nUnx7FQ6E=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Oi1XG3jOcYVaCGtrHmg5NthxDEHY5ckyHsWRj3R2La+/8t0jIfnxrRAKcur5SBsG0uU29a0PyBxvBTXWj1uV1kIvBrbgDKkh1FLa46++xFRST/Drpi1cBtGiiN4fUZ+pacxakfuKprkzbIPl3ZfJe5ZlZSgGRr5in0vv0gHmHtA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=m1DEU8Jl0MUQf+9UTfm5t79/clECJE5wwcEWYGtyy3BjnKRmSj9hgmI8Jta1tlIf64eZUuZhlUJUGH3Bj0HJrf4NyIvoSjtCseGodnNPWnPD1UMy+lvN2aWdkoCqs7uKtb4ePZ6QIWxtLAtF8BJXp5VRcjXjx5Oqo3WjxN46EM0=; X-YMail-OSG: Oe.s41gVM1l7auTYp4bkrI_PrC4r0JjMknv5yV0USezSEPW lQAjEEkIgAxYXdRT02UkZoZIrSG0ZSfJGD7.MZbURQ.SV_lINEC1x4qrwaCT OmxHHy08HKrVWkLuqYb8BjHBIMqdy1c2kufXqBuVDJafEZxZ1_4EUM8OO704 s38AtBtnz4WsJztPtsFru1QKpUhSO7RnVt16V7mi_G7DmpFxAYwL29YFIvc_ daULYOHEgmqDuo49UZXtuoALsQbwUFMBCrXMVmuqCVOsuECT3f2wQ8i5ZghU jq_rrAhqyFNX0UCNq7xGuvI5El8W2hJ1ZaA4kmBEaK1Uj016X19jBFcchWnY UQ.Q0Mwv..cojKVOYwe9F87rVM3uhpVlXjFKDxKeLKUxr4t9K3j.q8CU_5O_ _FhxVerzYWAy5mITkXXwPWvfHFGWI6OAIbT7KlmFJ1ee9rhrxN8lAunnHhMS UWMUdt89jVpFB Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Tue, 21 Aug 2012 16:17:01 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345589713.70741.YahooMailNeo@web31811.mail.mud.yahoo.com> <877gsrg84y.fsf@latte.josefsson.org> Message-ID: <1345591021.93130.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Tue, 21 Aug 2012 16:17:01 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <877gsrg84y.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 23:17:07 -0000 =0A>> always send a user ID as a routing hint to the server.=A0 We do speci= fically=0A>> say that the authZ ID must be derived form the credential itse= lf.=0A>=0A>I'm confused -- how does a SASL OAuth client specify that it wan= ts to=0A>logon as the "joe" user on an IMAP server?=A0 Normally in SASL the= client=0A>would put "joe" in the authorization identity, and the server wo= uld=0A>verify whether the authenticated user is permitted to access the "jo= e"=0A>account.=0A=0A=0AThe identity is carried in the token or derived by t= he server from the token.=0AThe client will know what identity it got the t= oken for.=0A=0A=0A>=0A>> We had put a "user" field back in, but dropped it = in favor of the gs2-header=0A>> since it's duplicate info.=A0 The gs2 heade= r becomes part of the protocol at=0A>> all times.=0A>=0A>Then the SASL OAut= h mechanism is not wire-compatible with the GSS-API=0A>OAuth mechanism.=A0 = I believe we want wire-compatibility.=0A=0A=0AWhy?=0A From wmills@yahoo-inc.com Tue Aug 21 16:48:01 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2EE21F8494 for ; Tue, 21 Aug 2012 16:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.553 X-Spam-Level: X-Spam-Status: No, score=-17.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 z+70Jl2VXYo6 for ; Tue, 21 Aug 2012 16:48:00 -0700 (PDT) Received: from nm7-vm0.bullet.mail.ac4.yahoo.com (nm7-vm0.bullet.mail.ac4.yahoo.com [98.139.52.228]) by ietfa.amsl.com (Postfix) with SMTP id 25CC611E808D for ; Tue, 21 Aug 2012 16:48:00 -0700 (PDT) Received: from [98.139.52.195] by nm7.bullet.mail.ac4.yahoo.com with NNFMP; 21 Aug 2012 23:47:56 -0000 Received: from [98.139.52.140] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 21 Aug 2012 23:47:56 -0000 Received: from [127.0.0.1] by omp1023.mail.ac4.yahoo.com with NNFMP; 21 Aug 2012 23:47:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 260377.6840.bm@omp1023.mail.ac4.yahoo.com Received: (qmail 70223 invoked by uid 60001); 21 Aug 2012 23:47:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345592875; bh=j9bLHgGilAqKoTPIwKYNncjj5k2lGh0s4Ha5oGjEXHc=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hmJ0RhBKvMHGfBQ0HsqaoIR2BAv6/4Mbt37mUJuNq1pKJ1tDZtxDMqK316OsbpO2Gs4OYMUCS0csF5qcMUtzBdRhhme0h4DgaTPy3lYOXaolLjoqCmvEJAu546RzW0lv6HiempG0B/ENF2oXPITL1dCVwMEb0fVt0zzJgXl5chY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=sRGSqx7404xXZWNBvuN2mENUHVqNQEKCx9Qv65okOZZTrM3+HyNvj5yZG75wPZhMs1lvd3n7oMjbftdpC+s9VG7D9e9hRexAPeRF/YwyjqM4ExEAn1a2x3thiv+ZtHcvd42qH91M0VSs0Avaggs1V7FsMHAE6X+ftY9rAmqPLLs=; X-YMail-OSG: d9PF3IwVM1k_cQ8Ek_4RBdwRfwkvyTupgPUGhwpH4iueBrD MBWA46q_pB.uaTE24jbtSnLrfK1Zatz0RKuiB39XmG4Cf5s2t4dnbxz.q2B1 txYDV_Fnzn7FqFFlRHrTx64YVnZEwtDjwpGP02EZhXC__SW57BQKNIlfAUOz 5xQODdjEH.0AIudYAdc1wub8Cdpsct3A4klpIC5ddaLFN7oiWP4KMeFnedMx iGZIlbBsXs5F8QMZZhxqAmemehliJicXUO..6UgctUsTJ64WT1vdCmAXj3xC De5gpKNCWixAiQ78yWs4LygxuweA_bz_VUO3wRz3Xu_rn9IdjBhAH0kVJC4Z 2W09xvt5EMzwaeWKzRFFnKYCHWr8MX5nSwm8SbSLM6Xen4jGQ73xGQIUt8P8 bldrVcNyEneV1XIvdlWk09zD7f59M9hxPIw6jyctzihA_coCKh4u.4rAy4eQ aSnIXiluB Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Tue, 21 Aug 2012 16:47:55 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345589713.70741.YahooMailNeo@web31811.mail.mud.yahoo.com> <877gsrg84y.fsf@latte.josefsson.org> <1345591021.93130.YahooMailNeo@web31812.mail.mud.yahoo.com> Message-ID: <1345592875.59168.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Tue, 21 Aug 2012 16:47:55 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-165214376-1345592875=:59168" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 23:48:01 -0000 --767760015-165214376-1345592875=:59168 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable That still doesn't explain it to me.=A0 In this case the Gs2 message and th= e SASL message are the same, no?=0A=0A=0A=0A=0A=0A>________________________= ________=0A> From: Nico Williams =0A>To: William Mills <= wmills@yahoo-inc.com> =0A>Cc: kitten@ietf.org; Simon Josefsson =0A>Sent: Tuesday, August 21, 2012 4:42 PM=0A>Subject: Re: [kitte= n] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt=0A> =0A>=0A>=0A>On Aug 2= 1, 2012 6:17 PM, "William Mills" wrote:=0A>> >> We h= ad put a "user" field back in, but dropped it in favor of the gs2-header=0A= >> >> since it's duplicate info.=A0 The gs2 header becomes part of the prot= ocol at=0A>> >> all times.=0A>> >=0A>> >Then the SASL OAuth mechanism is no= t wire-compatible with the GSS-API=0A>> >OAuth mechanism.=A0 I believe we w= ant wire-compatibility.=0A>>=0A>>=0A>> Why?=0A>Because gs2 is a SASL encaps= ulation of GSS: it has to be possible to decapsulate a gs2 mechanism for it= to be a gs2 mechanism :)=0A>Nico=0A>=0A> --767760015-165214376-1345592875=:59168 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
That stil= l doesn't explain it to me.  In this case the Gs2 message and the SASL= message are the same, no?


From: Nico Williams <nico103@gmail= .com>
To: William M= ills <wmills@yahoo-inc.com>
Cc: kitten@ietf.org; Simon Josefsson <simon@josefsson.org>= ;
Sent: Tuesday, August 21, 2012 4:4= 2 PM
Subject: Re: [kit= ten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt

=0AOn Aug 21, 2012 6:17 PM, "William Mi= lls" <wmills@yahoo-inc.com&g= t; wrote:
=0A> >> We had put a "user" field back in, but droppe= d it in favor of the gs2-header
=0A> >> since it's duplicate in= fo.  The gs2 header becomes part of the protocol at
=0A> >>= ; all times.
=0A> >
=0A> >Then the SASL OAuth mechanism i= s not wire-compatible with the GSS-API
=0A> >OAuth mechanism. = ; I believe we want wire-compatibility.
=0A>
=0A>
=0A> Wh= y?
=0A
Because gs2 is a SASL encapsulation of GSS: it has to be po= ssible to decapsulate a gs2 mechanism for it to be a gs2 mechanism :)
= =0A
Nico
=0A


--767760015-165214376-1345592875=:59168-- From nico@cryptonector.com Tue Aug 21 16:50:09 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF62211E8091 for ; Tue, 21 Aug 2012 16:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.078 X-Spam-Level: X-Spam-Status: No, score=-3.078 tagged_above=-999 required=5 tests=[AWL=-1.102, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 4yqmOXa5BwtF for ; Tue, 21 Aug 2012 16:50:09 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5870C11E808D for ; Tue, 21 Aug 2012 16:50:09 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id EDC441DE059 for ; Tue, 21 Aug 2012 16:50:08 -0700 (PDT) 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; s=cryptonector.com; bh=qnB9Ihmd9+1XBDr3X71+ uKcg/E4=; b=yAjDNMy24sMuA2LG+Rb30yaldK2vow7OT1inE7/Xwi4BN0PNGWbi nEKimI+2Si+y8/byGNIcsdmOUmniuLoP59aNuDUCsegdT0vtbdyPw5qQa0+8J3w3 TJ3qXUIrw4PxwRu5LydoyvBs6mLLxUw1iDl8kLGCFjfVk8hMXQrcgj8= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id D3AAC1DE00C for ; Tue, 21 Aug 2012 16:50:08 -0700 (PDT) Received: by dadf8 with SMTP id f8so246214dad.31 for ; Tue, 21 Aug 2012 16:50:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.75.74 with SMTP id a10mr41873699paw.46.1345593008305; Tue, 21 Aug 2012 16:50:08 -0700 (PDT) Received: by 10.68.230.38 with HTTP; Tue, 21 Aug 2012 16:50:07 -0700 (PDT) Received: by 10.68.230.38 with HTTP; Tue, 21 Aug 2012 16:50:07 -0700 (PDT) In-Reply-To: <1345591021.93130.YahooMailNeo@web31812.mail.mud.yahoo.com> References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345589713.70741.YahooMailNeo@web31811.mail.mud.yahoo.com> <877gsrg84y.fsf@latte.josefsson.org> <1345591021.93130.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Tue, 21 Aug 2012 18:50:07 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: multipart/alternative; boundary=f46d042f9c3245b44704c7cf49c2 Cc: kitten@ietf.org, Simon Josefsson Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 23:50:10 -0000 --f46d042f9c3245b44704c7cf49c2 Content-Type: text/plain; charset=UTF-8 On Aug 21, 2012 6:17 PM, "William Mills" wrote: > >> We had put a "user" field back in, but dropped it in favor of the gs2-header > >> since it's duplicate info. The gs2 header becomes part of the protocol at > >> all times. > > > >Then the SASL OAuth mechanism is not wire-compatible with the GSS-API > >OAuth mechanism. I believe we want wire-compatibility. > > > Why? Because gs2 is a SASL encapsulation of GSS: it has to be possible to decapsulate a gs2 mechanism for it to be a gs2 mechanism :) Nico -- --f46d042f9c3245b44704c7cf49c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Aug 21, 2012 6:17 PM, "William Mills" <wmills@yahoo-inc.com> wrote: > >> We= had put a "user" field back in, but dropped it in favor of the g= s2-header > >> since it's duplicate info. The gs2 header becom= es part of the protocol at > >> all times. > > > >Then= the SASL OAuth mechanism is not wire-compatible with the GSS-API > >= OAuth mechanism. I believe we want wire-compatibility. > > > Why?<= /p>

Because gs2 is a SASL encapsulation of GSS: it has to be possible to dec= apsulate a gs2 mechanism for it to be a gs2 mechanism :)

Nico
--

--f46d042f9c3245b44704c7cf49c2-- From nico@cryptonector.com Tue Aug 21 16:50:55 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C132E21F861A for ; Tue, 21 Aug 2012 16:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.067 X-Spam-Level: X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 YXCC8yQaVDcL for ; Tue, 21 Aug 2012 16:50:55 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6B92921F8497 for ; Tue, 21 Aug 2012 16:50:55 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 3E85077805B for ; Tue, 21 Aug 2012 16:50:55 -0700 (PDT) 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; s=cryptonector.com; bh=Sx44kbdTsUHtxcXw2avT ln1nklU=; b=FQk06HZbnpMVynwdy//2rdx5PYcqmb668t+wRjtK/SpcVqDx4zBU /Q5mdFaI2P69F9s9VPMNjbcU+Bx+x3B3tyLaw/EVyVYPgIe1lfZcD1pREfOBLkZJ YOuM5PwA2qRv+rY7Vkvp8gLEJ3PiyGxFBkeAoZiWwZdPBQhevbYURNQ= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 2553F778057 for ; Tue, 21 Aug 2012 16:50:55 -0700 (PDT) Received: by dadf8 with SMTP id f8so246609dad.31 for ; Tue, 21 Aug 2012 16:50:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.76.130 with SMTP id k2mr41813667paw.19.1345593054822; Tue, 21 Aug 2012 16:50:54 -0700 (PDT) Received: by 10.68.230.38 with HTTP; Tue, 21 Aug 2012 16:50:54 -0700 (PDT) Received: by 10.68.230.38 with HTTP; Tue, 21 Aug 2012 16:50:54 -0700 (PDT) In-Reply-To: References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345589713.70741.YahooMailNeo@web31811.mail.mud.yahoo.com> <877gsrg84y.fsf@latte.josefsson.org> <1345591021.93130.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Tue, 21 Aug 2012 18:50:54 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: multipart/alternative; boundary=f46d042dfec10b7fdf04c7cf4c4a Cc: kitten@ietf.org, Simon Josefsson Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 23:50:55 -0000 --f46d042dfec10b7fdf04c7cf4c4a Content-Type: text/plain; charset=UTF-8 BTW, I'd be ok with (if a bit sad) a SASL mech that looks like gs2 but isn't. It'd be better to try for a proper gs2 mech first. --f46d042dfec10b7fdf04c7cf4c4a Content-Type: text/html; charset=UTF-8

BTW, I'd be ok with (if a bit sad) a SASL mech that looks like gs2 but isn't. It'd be better to try for a proper gs2 mech first.

--f46d042dfec10b7fdf04c7cf4c4a-- From cantor.2@osu.edu Tue Aug 21 18:32:53 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137A821F8496 for ; Tue, 21 Aug 2012 18:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 qvr0NMDNYjWF for ; Tue, 21 Aug 2012 18:32:52 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8E721F8495 for ; Tue, 21 Aug 2012 18:32:49 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7M1Wldx008330; Tue, 21 Aug 2012 21:32:47 -0400 Received: from CIO-TNC-HT07.osuad.osu.edu (164.107.81.174) by CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 21 Aug 2012 21:32:46 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.02.0309.002; Tue, 21 Aug 2012 21:32:47 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] OAUTH SASL and Channel binding Thread-Index: AQHNe8BSHGdoCl4WY0+O4QBdMhqIS5dcipsAgAGbZICAAAxwAIAEsDQA///YMACAAmI8gP//93+A Date: Wed, 22 Aug 2012 01:32:45 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.74.80.179] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] OAUTH SASL and Channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 01:32:53 -0000 On 8/21/12 6:03 PM, "Nico Williams" wrote: > >We can only have so many cycles of suck before we decide to do >something different, no? I probably haven't seen as many, so I don't know if that makes me more pessimistic or optimistic. >I'm not optimistic about this cycle. And yet HTTP/2.0 *is* the best >opportunity we'll have in a while *if* HTTP/2.0 really does gain >momentum, and the bigger the changes in HTTP/2.0 the more we can >justify on the security side (OTOH, the bigger the changes, the bigger >the chance of failure or exhaustion that leaves security unchanged). I'm certainly interested in that, but I don't really think the drivers of the web right now have a philosophy on much of anything that I would agree with. Sucks for me. >But there is a way to make this happen: make implementations available >as a first step. It may well be that nothing else helps. When the ethos is that everything should be implemented from scratch all the time, that model doesn't work as well. -- Scott From cantor.2@osu.edu Tue Aug 21 18:36:33 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A669A11E80F4 for ; Tue, 21 Aug 2012 18:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 yxUOM2l+kXyC for ; Tue, 21 Aug 2012 18:36:33 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id F387D11E8091 for ; Tue, 21 Aug 2012 18:36:32 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7M1aVp6009994; Tue, 21 Aug 2012 21:36:31 -0400 Received: from CIO-KRC-HT03.osuad.osu.edu (164.107.81.43) by CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 21 Aug 2012 21:36:30 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT03.osuad.osu.edu ([fe80::2572:c08d:8186:46a4%12]) with mapi id 14.02.0309.002; Tue, 21 Aug 2012 21:36:31 -0400 From: "Cantor, Scott" To: William Mills , Nico Williams Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt Thread-Index: AQHNf/dioCZcgt3B5E2mVempObPLzJdlDSwA Date: Wed, 22 Aug 2012 01:36:29 +0000 Message-ID: In-Reply-To: <1345592875.59168.YahooMailNeo@web31813.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.74.80.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <9BD2F4B1ADB0A944A9C23920A9B62700@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 01:36:33 -0000 On 8/21/12 7:47 PM, "William Mills" wrote: >That still doesn't explain it to me. In this case the Gs2 message and >the SASL message are the same, no? No, because in the SASL case, the SASL layer strips the GS2 header and passes the rest into the GSS mech layer. I believe that's the idea anyway. -- Scott From cantor.2@osu.edu Tue Aug 21 19:53:35 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E831411E80F4 for ; Tue, 21 Aug 2012 19:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Oydel-4D6ZVk for ; Tue, 21 Aug 2012 19:53:35 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1748611E80A3 for ; Tue, 21 Aug 2012 19:53:34 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7M2rDL9017878; Tue, 21 Aug 2012 22:53:33 -0400 Received: from CIO-TNC-HT07.osuad.osu.edu (2002:a46b:51ae::a46b:51ae) by CIO-TNC-HT05.osuad.osu.edu (2002:a46b:51a8::a46b:51a8) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 21 Aug 2012 22:53:32 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.02.0309.002; Tue, 21 Aug 2012 22:53:32 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt Thread-Index: AQHNf/dioCZcgt3B5E2mVempObPLzJdlDSwAgABXBAD//759AA== Date: Wed, 22 Aug 2012 02:53:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.35] Content-Type: text/plain; charset="us-ascii" Content-ID: <91DD3613E2976145AFC37105477B5FE7@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 02:53:36 -0000 On 8/21/12 10:47 PM, "Nico Williams" wrote: > >If that's not possible then the mechanism as specified might be a SASL >mechanism, but not a GSS nor GS2 mechanism. There's no reason why that should be an issue here. >It's possible to have a SASL mech that looks like a gs2 mech but >isn't. The question is: do you care to have OAuth as a GSS mechanism? Well, I do. Again for the "if I get stuck with this, have it not suck" reasoning. -- Scott From wmills@yahoo-inc.com Tue Aug 21 22:12:08 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D91C11E80D2 for ; Tue, 21 Aug 2012 22:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.54 X-Spam-Level: X-Spam-Status: No, score=-17.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 V-Fpz1aJi4zE for ; Tue, 21 Aug 2012 22:12:04 -0700 (PDT) Received: from nm27.bullet.mail.ac4.yahoo.com (nm27.bullet.mail.ac4.yahoo.com [98.139.52.224]) by ietfa.amsl.com (Postfix) with SMTP id 174FD21F85AD for ; Tue, 21 Aug 2012 22:12:03 -0700 (PDT) Received: from [98.139.52.195] by nm27.bullet.mail.ac4.yahoo.com with NNFMP; 22 Aug 2012 05:11:59 -0000 Received: from [98.139.52.137] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 22 Aug 2012 05:11:59 -0000 Received: from [127.0.0.1] by omp1020.mail.ac4.yahoo.com with NNFMP; 22 Aug 2012 05:11:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 874014.37547.bm@omp1020.mail.ac4.yahoo.com Received: (qmail 74008 invoked by uid 60001); 22 Aug 2012 05:11:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345612319; bh=k5zXd2JG0geRsB6QlKlKea6OnrCpyc10e0mxw2ODD8g=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=q9lhzMDb6+bV4vJ+I7ujIHVR8/AdpAwvvy89uKu/OdaO3Cvll1pO0/eorb2tX9HP2rR9fn7rwGfGNjaK5yZF1mEjbeppvOaLiIBLrV8/Izaq43e1z8qfqIPPWB7cbFH0XqTn+UT6dmMuO+ESyNeFV1dOlE3P7JHPxlS1ZzUl8y0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DYAFcOKjyxDi94tN2XBA3v2XzgNBkniHoXLRfen+zT9rl0Rgcm/POQElu646t/RubceZcAXI+0x4z8Ia2pGYmB+8OuFXhyX1LwqH8vYLXJAMPdg0PoPSH2tjimrp2T2whN/guXerEJtk/lWtRhKIkPqr03+MbEQF8ilX+zbKE9Q=; X-YMail-OSG: g9HIXTEVM1n8r.oU3LHSL_2wjgxsHk45AbgvGeJAchXmW9H kSEUJWadWiFjqKv0EfDGX4dSaRZ1SZOY1jS3.nUJCXM9bymKwMAC7pxiC15E H3GmT8qPY0BD_h7MYhU0RAZrEvn3jr8uiBAxjfRVKeQ.idBtGqImXEQNzziC ZEzzxV7v6jrHn3Qhr3a0eCf42GspwwsI55MscE6rdwS1vESFxmDCkkJEPpYL xzhSWknHZ3Axncxb5Bq.cPGEaH20M0MaI14yORrJwicAvWUsbxSM7rWrKx8X wMYxs6Evz1.yd9yoeS89AbS_w6SQggstmGyrUw67P40j0PTuLhTD5gbNcwrf R0ofHNrsoM74evHDWCurWJjsXNN.S7yo6UIzfJ8yF4WR5s6Te3R7uWjRzUnb QAcOKHyGs.3wHxH7XUVfxChcwRv2EVUVOVkQqXlO1N4Gnow-- Received: from [99.31.212.42] by web31807.mail.mud.yahoo.com via HTTP; Tue, 21 Aug 2012 22:11:59 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: Message-ID: <1345612319.55458.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Tue, 21 Aug 2012 22:11:59 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-1708728007-1345612319=:55458" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 05:12:08 -0000 ---125733401-1708728007-1345612319=:55458 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OK, so to do what I want the user field needs to go back in the SASL messag= e, and the gs2-header becomes optional and only present in a GS2 message?= =0A=0A=0A=0A=0A=0A>________________________________=0A> From: "Cantor, Scot= t" =0A>To: Nico Williams =0A>Cc: Will= iam Mills ; "kitten@ietf.org" ; Simo= n Josefsson =0A>Sent: Tuesday, August 21, 2012 7:53 P= M=0A>Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt= =0A> =0A>On 8/21/12 10:47 PM, "Nico Williams" wrote:=0A= >>=0A>>If that's not possible then the mechanism as specified might be a SA= SL=0A>>mechanism, but not a GSS nor GS2 mechanism.=0A>=0A>There's no reason= why that should be an issue here.=0A>=0A>>It's possible to have a SASL mec= h that looks like a gs2 mech but=0A>>isn't.=A0 The question is: do you care= to have OAuth as a GSS mechanism?=0A>=0A>Well, I do. Again for the "if I g= et stuck with this, have it not suck"=0A>reasoning.=0A>=0A>-- Scott=0A>=0A>= =0A>=0A> ---125733401-1708728007-1345612319=:55458 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OK, so to= do what I want the user field needs to go back in the SASL message, and th= e gs2-header becomes optional and only present in a GS2 message?


<= div style=3D"font-family: Courier New, courier, monaco, monospace, sans-ser= if; font-size: 14pt;">
From: "Cantor, Scott" <cantor.2@osu.edu>
To: Nico Williams <nico103@gmail.com>
<= b>Cc: William Mills <wmills@yahoo-inc.com>; "kitten@ietf.org" <kitten@ietf.org>; S= imon Josefsson <simon@josefsson.org>
Sent: Tuesday, August 21, 2012 7:53 PM
Subject: Re: [kitten] I-D Action: dr= aft-ietf-kitten-sasl-oauth-04.txt

On 8/21/12 10:47 P= M, "Nico Williams" <nico103@gmail.com> wrote:
>
>If th= at's not possible then the mechanism as specified might be a SASL
>me= chanism, but not a GSS nor GS2 mechanism.

There's no reason why that= should be an issue here.

>It's possible to have a SASL mech that= looks like a gs2 mech but
>isn't.  The question is: do you care= to have OAuth as a GSS mechanism?

Well, I do. Again for the "if I g= et stuck with this, have it not suck"
reasoning.

-- Scott



---125733401-1708728007-1345612319=:55458-- From cantor.2@osu.edu Tue Aug 21 22:18:44 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3089F21F8620 for ; Tue, 21 Aug 2012 22:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 z1r7xiat9uhK for ; Tue, 21 Aug 2012 22:18:42 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8508A21F861F for ; Tue, 21 Aug 2012 22:18:40 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7M5IaWa032532; Wed, 22 Aug 2012 01:18:38 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.02.0309.002; Wed, 22 Aug 2012 01:18:36 -0400 From: "Cantor, Scott" To: William Mills , Nico Williams Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt Thread-Index: AQHNf/dioCZcgt3B5E2mVempObPLzJdlDSwAgABXBAD//759AIAAacKA//++xgA= Date: Wed, 22 Aug 2012 05:18:36 +0000 Message-ID: In-Reply-To: <1345612319.55458.YahooMailNeo@web31807.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.35] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 05:18:44 -0000 On 8/22/12 1:11 AM, "William Mills" wrote: >OK, so to do what I want the user field needs to go back in the SASL >message, and the gs2-header becomes optional and only present in a GS2 >message? The latter yes, you can find boilerplate text on this in my SAML-EC mech. I don't understand the reasoning behind specially handling the user field and would defer to Simon on that. -- Scott From wmills@yahoo-inc.com Tue Aug 21 22:24:45 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA2321F8621 for ; Tue, 21 Aug 2012 22:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.546 X-Spam-Level: X-Spam-Status: No, score=-17.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 HalybqeoPV-V for ; Tue, 21 Aug 2012 22:24:41 -0700 (PDT) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) by ietfa.amsl.com (Postfix) with SMTP id 0395011E80A2 for ; Tue, 21 Aug 2012 22:24:40 -0700 (PDT) Received: from [98.139.212.153] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 22 Aug 2012 05:24:40 -0000 Received: from [98.139.212.207] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 22 Aug 2012 05:24:40 -0000 Received: from [127.0.0.1] by omp1016.mail.bf1.yahoo.com with NNFMP; 22 Aug 2012 05:24:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 372287.79791.bm@omp1016.mail.bf1.yahoo.com Received: (qmail 48404 invoked by uid 60001); 22 Aug 2012 05:24:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345613079; bh=57eiiknyRQiWcvg1shllp7eXP7U/tVGOCvIcKUbMLbw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kYonO8JEPLFvI5u6CHCt3RuvV0PGm+OLdqcNDbCTOrOFcSMSURaHRMk0OkF0pRDAza4WsAzoHAkD3OWQudzKNd4ihQn8aGEE59Hu+OoMPtG+WMLil5FJuWhvbODvUWUiJqp9yYcHI97yNkOp12JI4YUdqulDjTL0zK0DerFMtYY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LrCFCPynCE9VxsCZaARUS8bkncvMMkPQnJl0wkGiOFlgPbu2LqmExN9TsVm+zJ8rfdzMiWTrnRpcN0W3UJJ115tjVVAIZmuATuRDr5jMgqpdSEfnC1lWz7fwtLbhnycZ8m58hoBXpAPN+AvyXFj8FjtCl/rv5jB+6OZN8UL//Uk=; X-YMail-OSG: Zlm_uB8VM1nAaC5JOYRTyn97zuUxaQVNR4lr67epoXPTcCH oS0gAth7xg39C7IPmd1hPPq86sBuGabUXbLR6mAtp_j6SwS9itm8Pi50b1Tb LiGJzz8QL1mZUS7lpdp8QmfbwQDOGZ40DfAJJo3RNitToYqgFV_ZgMPkQDg4 .DJ83HLPAUkXZTH8XO1oEs0vlqxoKseQ5bV_zJt4AuX4RCbMxuiaDdF7q4Ok anvaxifMCHizlLQEMAUA2r_nrQZQKbb9MENIoShKXtqLr8kjjYTyNiwNav.b .nvV.5xmNBQ5ItTu.s2ZPkegSZwCjNS38Eg8VxiX9ro4j1E8TMh7Sz6MvBvn Ee4voRezN8QvHJ6yN8bHt3A1qZOYCV.8XbCBhBsy9EWrV.TRLihm5CQcs4AE mAkMdmaeakCuR8IVb55i0keIxctTzVl1tLsDkHAeLhXmCrw-- Received: from [99.31.212.42] by web31810.mail.mud.yahoo.com via HTTP; Tue, 21 Aug 2012 22:24:39 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1345612319.55458.YahooMailNeo@web31807.mail.mud.yahoo.com> Message-ID: <1345613079.48024.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Tue, 21 Aug 2012 22:24:39 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1935884094-1618648777-1345613079=:48024" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 05:24:45 -0000 --1935884094-1618648777-1345613079=:48024 Content-Type: text/plain; charset=us-ascii We want the username passed in the SASL message somewhere. >________________________________ > From: "Cantor, Scott" >To: William Mills ; Nico Williams >Cc: "kitten@ietf.org" ; Simon Josefsson >Sent: Tuesday, August 21, 2012 10:18 PM >Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt > >On 8/22/12 1:11 AM, "William Mills" wrote: > >>OK, so to do what I want the user field needs to go back in the SASL >>message, and the gs2-header becomes optional and only present in a GS2 >>message? > >The latter yes, you can find boilerplate text on this in my SAML-EC mech. > >I don't understand the reasoning behind specially handling the user field >and would defer to Simon on that. > >-- Scott > > > > --1935884094-1618648777-1345613079=:48024 Content-Type: text/html; charset=us-ascii
We want the username passed in the SASL message somewhere.

From: "Cantor, Scott" <cantor.2@osu.edu>
To: William Mills <wmills@yahoo-inc.com>; Nico Williams <nico103@gmail.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>; Simon Josefsson <simon@josefsson.org>
Sent: Tuesday, August 21, 2012 10:18 PM
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt

On 8/22/12 1:11 AM, "William Mills" <wmills@yahoo-inc.com> wrote:

>OK, so to do what I want the user field needs to go back in the SASL
>message, and the gs2-header becomes optional and only present in a GS2
>message?

The latter yes, you can find boilerplate text on this in my SAML-EC mech.

I don't understand the reasoning behind specially handling the user field
and would defer to Simon on that.

-- Scott



--1935884094-1618648777-1345613079=:48024-- From hannes.tschofenig@gmx.net Tue Aug 21 22:36:39 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5434B11E8103 for ; Tue, 21 Aug 2012 22:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 D9XPx5a98XZZ for ; Tue, 21 Aug 2012 22:36:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 62FE411E8102 for ; Tue, 21 Aug 2012 22:36:37 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2012 05:36:35 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp024) with SMTP; 22 Aug 2012 07:36:35 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18YSMFPXvcYAN6LTMJ6WtMF5lndI75PNzPkBKrs1w 2Z1XYcLgvhbomd Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <87boi4gioe.fsf@latte.josefsson.org> Date: Wed, 22 Aug 2012 08:36:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6C4F4A39-D2E1-485F-9418-5B7D68C80AF6@gmx.net> References: <1345163301.61508.YahooMailNeo@web31805.mail.mud.yahoo.com> <588B67DC-7788-49DF-B303-753D4B420D3C@gmx.net> <1345482606.17400.YahooMailNeo@web31801.mail.mud.yahoo.com> <02D60FA0-45E3-4331-837A-E049029D919B@gmx.net> <1345531034.66639.YahooMailNeo@web31805.mail.mud.yahoo.com> <1345531945.23279.YahooMailNeo@web31804.mail.mud.yahoo.com> <24E6B416-8953-49A9-BDB1-73E8B482906D@gmx.net> <1345563667.23360.YahooMailNeo__20929.0090752349$1345563689$gmane$org@web31811.mail.mud.yahoo.com> <87boi4gioe.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Jiangang Zhang , Gil Yehuda , "kitten@ietf.org" , Tim Showalter Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 05:36:39 -0000 There is no doubt that the protocol execution can fail for a number of = reasons.=20 The question I had was whether it is enough to register one SASL method, = namely "OAUTH", for two different security mechanisms, namely for OAuth = 1.0 MAC tokens, and for the OAuth 2.0 Bearer Token, or whether these = should rather be exposed as two separate mechanisms. Using two separate = SASL mechanisms allows us to use the SASL negotiation mechanism.=20 In an earlier discussion we had spoken about the difference between the = two mechanisms and Bill's argument was that he wanted both since neither = one of them covers the deployment nor the required properties. = Ultimately it boiled down to the question of how many different OAuth = variants one wants to implement in the SASL client and the SASL server.=20= So, Bill has this idea that we could figure out what functionality is = supported by trial-and-error. To put that to the extreme one could argue = that we only one SASL mechanism (without any negotiation) and then after = some failed exchanges the client and the server will find a mechanism = that works.=20 I am, however, advocating for registering more SASL methods to = distinguish the different variants. I would, for example, if we finish = the work on the new OAuth security mechanism standardize that as a SASL = mechanism with a new id.=20 On Aug 21, 2012, at 10:16 PM, Simon Josefsson wrote: > William Mills writes: >=20 >> We have a question in play. Does a SASL mechanism have to have >> guaranteed compatibility or is it OK for a mechanism to discover that >> there are no shared capabilities like SSL might discover no shared >> cipher suites? >=20 > SASL mechanisms can fail for any reason. RFC 4422: >=20 > The outcome is not successful if >=20 > - the authentication exchange failed for any reason, >=20 > The application can retry in this situation. However, this is not > always well supported by applications, but if mechanisms starts to = fail > when attempted, those bugs will be noticed and fixed. >=20 > /Simon From hannes.tschofenig@gmx.net Tue Aug 21 23:03:38 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FDF21F8576 for ; Tue, 21 Aug 2012 23:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 ThQN-CaikKik for ; Tue, 21 Aug 2012 23:03:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5759B21F856D for ; Tue, 21 Aug 2012 23:03:35 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2012 06:03:34 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp034) with SMTP; 22 Aug 2012 08:03:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Jp+phDWRJmw3uJS4i5HYgHWUoqHeOZ9fLkhwmgX RQNTJVkz5aTQmV From: Hannes Tschofenig Content-Type: multipart/mixed; boundary=Apple-Mail-114-88509320 Date: Wed, 22 Aug 2012 09:03:32 +0300 Message-Id: To: kitten@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [kitten] Debunking an API Design Meme X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 06:03:38 -0000 --Apple-Mail-114-88509320 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all,=20 I thought that this is a relevant writeup by Martin Thomson that he = shared on the RTCWEB mailing list. It deals with the design decisions we = make with regard to the (perceived) capabilities of the application = developer. While his writeup is not at all specific to this working = group I believe it touches on some of the issues we have been talking = recently. Ciao Hannes --Apple-Mail-114-88509320 Content-Disposition: inline; filename="Debunking an API Design Meme.pdf" Content-Type: application/pdf; x-unix-mode=0644; name="Debunking an API Design Meme.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDE1IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDMvS2lkc1sgMyAwIFIgMTAg MCBSIDEzIDAgUl0gPj4NCmVuZG9iag0KMyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAg Ui9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIgNyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4 dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vQW5ub3RzWyA5IDAgUl0gL01lZGlhQm94WyAwIDAg NjEyIDc5Ml0gL0NvbnRlbnRzIDQgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5j eS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAwPj4NCmVuZG9iag0KNCAwIG9i ag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzNTA1Pj4NCnN0cmVhbQ0KeJyVWttu40YS fR9g/qF3XiItbIZ3SrtBFskkWXiBJIONgX2Y5IGmmhbXtKSwKWvm77fqVHeTlE15FsE4ujS763rq VLXU1x/UN998/fP7mx9U+O236vsf3qvvb9+++fqnSEVpEKbqtn77JlIh/RepIg7COFX5Kg6Klbp9 fPsmDOIoVmGQFAn9zfK16u5f+vTf/3z75uPih2W60HfH3UOzLBa7++V1slDLfFEur+PFjl6o7z7c 0Df8GZaahpfc82K1vE4XP+tHvfxD3f7r7ZsfSUgW1IkWF3lQFGPRPtI+w1r148/vlRppG020jVUU zWmb58EqFm0VK6egy+1Wd1qxfI1ZRvFClYrkfGQx9XI9vFA9r9kuk0XZK1b0ZhmR2tvyablayAb7 5XW2uKMVtFG00N0T6a83qtmRDXhbWrKjb4/LKJV9ea3uFG2AR2tF53S60m5lL3LtllG+6PFpV1Ys ZN/gAV5j+PFT02+Voaf7chmF+HzDknabZUYr7rs9S3ykjw54pNzxF6rp1YwbnM2yKIhj64Z7UgPH agMvljBX2/R9y4eKDdqGDnjQ7H1vsMb8beaYKE94/8kxF70dj7ztNwlXJKzK4yxY2z3e3bK+fLZI xZob3bGY6vcFf1IeSBs2BgSuyr7hL71V1Ubz+yfn/XbPDx3gr9+Xk3DZqWZDe5FHCuuwkh3O9lcV i4G3X9G/niPrzgvVd0fT6w12OfFB5ER+iI7DI5+xaMvysUhsfmdTCiAbhY1RZlt2Vhl+Fjp0c451 xoooq62xWKJOlw/lXcvJGrybezRbB/n00Yu+Sl7wlY2rbJUGa5fev1AoQujTFSMG6VjIe3WnoWNd sg06NtTVOKpUg0SzqVWV/KZryJdH0oOT2ufVkLvIniHDjSnvOY/1FX92oiewdbVlY9OSQlzR1BpH 9Tby5Vy8fof05hj5dNCd3f5a8k8/8VcthDiw03T3TjntOgWBX8lAAl02uljKNI+IvBa5rYAyxwOZ D5FO3+U2KqFcgAXql73AcgIhe/qH1S3pDntLhAFGzlDvDBWvJb4e6RkowFs1T2U/KFT7HGLhQtlm iGWFWKdqcG9DmrKsalhI0+wd5plAsSgf+NG2rM6in4+y0fKa4bI0iFJrOAjCIFBtVdXBbhu9q5Dj hM+q3yJayOPJRP9iUe3ZqvxoC8gUqCs3qnepRghwoZZlyVSSOanjYh2E2XRtw5HpC0XZlhxCbIxK I/Qo8jK2IRtUvnge6PS2xmtAGQRmZTrxqlNVfAbvDMELb+qdaZ5ombb+v2zzZBVkTnqbAGQ93bLF bRYkCCC960fpeehYMx9UeFH5WGolUVxRI3LBotyoWqPY9cdOcySPItP0sA9BO237gMLZsi0/c1mi gKV8GCyF4l45YfjRfFSOVd3qT8iDOzI2Mq/pWZzPLh9G8S4rD8BTYxDZUkF2iDRjghn7ZWEaJGf2 u4it6QVsjZIgcoXwdkswqcY8ZpTaJYdNyfSCzNJp1KqOC1LK1IAsYtSWQ93GWWOqI9MJVixeTAnI UDjbBoRoRwaQKsfBY3pLZDJJ5HqwGz/d9RV9cIKjONQJAm4cj5kAflUaTeuvzrx3nrYXgzRdF0ER jYHhJYgXnam4l939MhtxNopcoEbbPEgWGh/ccywnjtbMaScHX/RuNs9yUtIi8TTnP9pF4XOqwUGv oZH4YTuk9/9Dfqa5y2yVznnYcTpJ0WbcLO/2jmaxvylh6c9hD/MYyhzKRQCsVPKWw6iT2m7tzFBL qcbgflKCeFwuq/JoAMMA6IuMJs3yYO2s63GuL++1D//m3pZKsYgcYalYiVBGZPd7rvtAQyR5AKIP qW5qLhUoq6QK6ZF7PYya2LD9zCbAQ8gAFOeDh7mOKFsi219hu92eS3FTN+KNZOSNGfGF7wizlXNe t1EaBWnyGj5LR0JWSJiBbUv6PzoZqQASG6YHmUZJ7SnjuStoPSzOwVycZ8EqG4tBbWUYZ+q2+sjG miuNYbBaT5/CEz95O3WKYeFT6UkHgltfjfiy/syBhizx0SElHWu6httTBifbJlDq37z/UToy0ws2 8nn9S70gLztnCq+4gruVzLqCwty6MX+5HrM63PlFtpr1RqQYE+WVbTupsja73nuUFTlyU256JvgW MXea8f2058bhYZbxJ9Qyh8VU1ovAlc+XpTQMgyyaofxN/5VRA6aAoJMiTaclj+C2VosH2Nj9liw/ 2wqYg2bbVZROHKBw0ZB7pumnFWzsTvj+NCL5dxoEH2VLyD93e0+OJEgWIsU36mMzZCf4QNdTeW1J Wct/qVPMcaTF6IuFKlllQeRDBNEF8tcebXtpkVHo+8m35Djrj4BjUEALwTBRai421xFPXSYHS9FD TrAzWI3SQ5vROxlHPNJpHHk9f3rGP7lClEYhcD8dOrjGGL35OyrHYC3vj0p3u4Dtzef8SqvuAEHX aLJdN4/AuFJNPQ4DkFqGYnL4uOC9ZmlusooxLlYNWpLUIzACrhm6JIqCKEPbiNqqEbzK7B814nlX L5NRFssjfeOzEttaQQ9LUak7YMBCAarrY4saohwj4iC0TRAbZTQukGYOxLjuxIyZnAf2crAzH1vp EazD8IiI1m8iU/Zl5Cmh/iQcYAu4xOXdEmOJD6tX6/PZ9FO4mrK35+x0tn6EeZAkUyEu4lExj0dJ vAoKVwtvdj5bxGmboRD0MtrLHEXegN4Lnx/i3cUeJ4Lr1hIbzVfY+OTnhPWceimFYTaVrOnIeLzz eNA49J6GP6N3cERX9tqPNkryeLqoBqRD1lgI8wOqZqcPHMhwEHEtbr7pgFuq+pGfP3J3ReqeENo7 7a3wWqxQI5K4rBJSxU0E2wUoZARAG4EKz2SZxmwF6SWMXfZROLO8/CiPWtyYhWv7ZM4iYTWaQDwj TkcngvbTGDq1syXE+A9d8kgQE8Cj39xPSoZ4BJD3gsyXLRRTR7ByZJ4k8D2lZfMM9GY6fPZJYnQ7 kHRqLP1A6naEe6etdz8RcAHx0rjoAQidPLWDDk9ceaWIwkBMbI7MElxy+yQF2TL4To97Jrc7IA3t nTgacABOPh5eN7B2P2OntOCZ7sRMyESqIk9CEaQYvWLmVRyk047v5eQoKyG+TP9lmNXtHSXDiEA8 gsc8HlOsPnqebydT6yGoEOmUVljynUGZmBQ9awn9J+/NQykZRfp8KFvDo2XSGYM8UA3I6UoP9+c8 wjz0vgJcZxiGqM3e+0Vqx2U75cWAq+I07sRrhfZwKOa4MMl9gycDPB6PUIyNOvveTlO1u8XIIGPv qBNIczlqYM6S6EqyCNFsR3SXsU2mLDZNR52YEvPp3l+sbCSFPX0eMsaJGWCT1wyWUUuS+VEL5fvJ KTf0AXaILbcllM0kv80oQOxnBFeNbEIVRd7Ml8AoC/L19OSLJXA1XwLjOA8iV2hu51QtgvR8rXef U07axhqIUaEm2nnbtbsEwXsi8FfP6RpwRCHrhs5ZmjKkBADiGegWdtqGfJBpIhCXF3LecTKvx728 q30IMO1v4zgB7bUNIvlBqHy/V5xB5YMeWCpf2NiyeDksopDruNjqv0cbb5yAboLEM2fPBS3ZGJru +85xBzRCRIehOE/qcgZ5jE9tE2OhV5pvaedH9RRxfuD3XfPUtJoH71QsMOv+rpf2gWx2cDDB94xX wx0Wu9jnbVk5+LH5XZVCem0MvGKUaJ0FsQNx3b4sKhrXeGhcZQLN5VvE8JUZs1kwdTNESnU+x6r5 kmQ0F+5mb51XxCjXUxlnxxGrPMij6Vpp1csNw9Io8oe+0l0BXwYwdovNA2Y1gUTsr24UKkF7j8ut sh9SoPQthow9phfK/n7nsnsK4p75BPu78Yiex10OnAa0rDA2G+NnPVHJY+1zhPrtQP51ILV+aeC5 zoMwGgsmn+OHCXglP0YAHkw8+/w3AuEL+8dRzlk62X/4WcA8/q7Z7RNzjbUbZPTyF0FBmECQkKow KKL1uqBO4u2b+q8vSRrNw3WU4ZLAS/qR6IRSrQ93VHiwuxGpKyuZRBwGhLQ3gERbkLbNdIAv8Ct1 qp3tVPIE+TJI9HFxPbs251I1WYtsriUJmCbojW0x7FhHuIAMF8YCCqecm1atkiAtpgfNryVieabA wXbTCHSh/JO5KMaIkthDkr5mqZQ4VZx/maXSIuS73snaM070D6kAl1M5WXHEyfO/3j01A8K0fj4E cjWQzFNpS6id+gLRpQPwpGkybwQ7Mp7LuU5poJp2PjQfQpQeRGQmws4ZJglDJqaTtWeGCWatkiQR 35hMHr78i6KXfmTibEs9bRpPpgbLa9yk8l/mqI9g6TLxwIeE0VRmO+3v1y1yGm1wlWWftCDNb1p3 6a39JoLCS39Sx23cuNaNOD620DKgsjuKW/GyVBhmdyWT07l6mOQpTwAn2s46hyI8i6ZrmVTVtcLM suZzI3u6hNR8tkRxkCdfdm4aSQqP15634XK90RnhbdYfroM9WPYnWTDM6exMk5a5m5+L6bZeBWGe jpoAnu0ae6HzwnTTEI2shLxJ8x6ASb9jr9xabIY3H4YfldXjiww1sGoPVxtfl3d/eYc7y2R6Z2nk UmPOhymuJieq2IstoSKNa2XVVrc8p6yZcLWC2js/61Td+ZCzbNXoiu/RD6n51v41y3Lbnk9+TnBX 9rOdURTm/COyyUPP8vx/uwBbhA0KZW5kc3RyZWFtDQplbmRvYmoNCjUgMCBvYmoNCjw8L1R5cGUv Rm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjEvQmFzZUZvbnQvQUJDREVFK0NhbWJyaWEsQm9s ZC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgNiAwIFIvRmlyc3RDaGFy IDMyL0xhc3RDaGFyIDExNy9XaWR0aHMgNTEgMCBSPj4NCmVuZG9iag0KNiAwIG9iag0KPDwvVHlw ZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUrQ2FtYnJpYSxCb2xkL0ZsYWdzIDMyL0l0 YWxpY0FuZ2xlIDAvQXNjZW50IDk1MC9EZXNjZW50IC0yMjIvQ2FwSGVpZ2h0IDc3OC9BdmdXaWR0 aCA2MDAvTWF4V2lkdGggMjQ4Mi9Gb250V2VpZ2h0IDcwMC9YSGVpZ2h0IDI1MC9TdGVtViA2MC9G b250QkJveFsgLTExMTAgLTIyMiAxMzczIDc3OF0gL0ZvbnRGaWxlMiA1MiAwIFI+Pg0KZW5kb2Jq DQo3IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0YyL0Jhc2VGb250 L0FCQ0RFRStDYWxpYnJpL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciA4 IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIyL1dpZHRocyA1MyAwIFI+Pg0KZW5kb2JqDQo4 IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDYWxpYnJpL0Zs YWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDc1MC9EZXNjZW50IC0yNTAvQ2FwSGVpZ2h0IDc1 MC9BdmdXaWR0aCA1MjEvTWF4V2lkdGggMTc0My9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9T dGVtViA1Mi9Gb250QkJveFsgLTUwMyAtMjUwIDEyNDAgNzUwXSAvRm9udEZpbGUyIDU0IDAgUj4+ DQplbmRvYmoNCjkgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyAxOTMuNjYgMTY0Ljc1IDIx OC43MiAxOTAuMTldIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0 dHA6Ly93d3cudHJveWh1bnQuY29tLzIwMTIvMDcvbGVzc29ucy1pbi13ZWJzaXRlLXNlY3VyaXR5 LWFudGkuaHRtbCkgPj4vU3RydWN0UGFyZW50IDE+Pg0KZW5kb2JqDQoxMCAwIG9iag0KPDwvVHlw ZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjIgNyAwIFI+Pi9FeHRHU3Rh dGU8PC9HUzEyIDEyIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJ XSA+Pi9NZWRpYUJveFsgMCAwIDYxMiA3OTJdIC9Db250ZW50cyAxMSAwIFIvR3JvdXA8PC9UeXBl L0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRz IDI+Pg0KZW5kb2JqDQoxMSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzNzU5 Pj4NCnN0cmVhbQ0KeJyVWttu40YSfR9g/qExL5EADyOSkigBQQBnkk0c7OwOsl4kQLIPbYqyGNO0 wqbs8X79Vp3qGyVTnkXgiS01yeq6nDqnmurrT+qbb77++OHqezX79lv13fcf1HfXb998/bdMpWky m6vr7ds3qZrRf6kqsmSWzVUxWyfLlbq+p3U//ivN1K15+2ambvmfH9+++X3y4WH6fj7puqqcprNJ X9Ofi0k7zSdqup6orpq+zyZ/0Z8H+qm7ykzTdKK2dWd6NV1N9DTNJhv6in/oW1O30/nkln5UP32f T3b0caX4N9ze37ysupYvDas03a+Y6D1duqc/m5pX6dieTcW3eGRzq4bNwFe8uOoMf6V0R89aTlS9 qek2+Lo3Cdup/sn76NT0P+r657dvfiC3seucs+arNElXsbN+n7wfXTtPFvPh2vH7LpP10dr+gTdz w17JJlvN+xy1a5HPkmz5ZXYt8jxZfJlZNjeW6znvWtZyzOrHir0Lb4fwcR6U5EMfCdN3muLMzlW8 vp6m+eSef9tPU/b7YmKqjTrs6ZcQPntDWlDR2uXkApmEG5xGXZLFB/6R73Iu6GwFW4Qsw+30Df3T VMoZvrV7WDhLOV93FafrZsyjszSZL4duwlNO8vu8m4tVUtjL8dgHvvKGt0ueWEyU2esSXsY+nrD5 fqfMYbvloivh36rtVXvgjbHJJRJdUon2U0gh3lV8Zy7cfleprr5lb7OJPUqQa7Qqa1N7PyKayYj5 +XKV5IuB+fFO1Q8fPygVYVIaYdKxCxZ5kjsXXu8k99W+I0tsPHT3zB7Ys3My6xw2E1+qHe+ukuqu jWqxCIDBG9V7DrjNHb7oS1HjAna0krT0acdBzWySwmWqblt6JoPfPf2/6nQwjRKKFsdVgeSr+YIX KiOXpQBQqo5XciYvkrX1Fz/cX35am7h9otQ1/19MNz4PuDhgVqUb/vul/DMX6oYTC/48hm3jXdYc uOLj3KFHqdpYH1r7eo7ivfuraXjRM/D/gYvetQoEiy/iUiLjr7ZjCJplSZYP/DEKttk8WQ6XPlXc DhxCsG0wy7ukeQaEmAcuoYaDJYnCm/COoC2+Fi0yMj9T4RfqiZMHDm1t2CgFeodN8iwNA+6wCuV8 49x48CVcOmBE1PHPwXqyLnFRlPtjhZ2tVsk8HVh9trCz8cJerKnBucK+5MwfQ/SoIlHMj1MuyKgY EQkUujZUdiAJreSbBAXljkipg8C2u8z0ut2wn1GW8ruqe4FT52T2U4NvbO8F6+jwicS7sNHQHd+H M/Pg66DfEUGJWtgzVjaAm/IOYLx7rREsiGUsM+usUvO2dVn3z77sOLCqqXTXJvwb3/Wjs6qLWlmP 9G1lixknKLxQ3/NN4HXOJJSdhIOs5096uxVAonwtXzgHv0fAUptZdW+xat8haUfaRLFIivVwc2Mc JS/WSboYruVi+FyPXbBOk1UxvMD0dXvLmXYn9WQpx1NTbThmsg30adcJt3XVEOLSZrRLnNdCtVwm 6dw+EDlsPcLIzYmKeAV4d8mZczevbAK2iu1BVcKcl7mDw4QS3At4a2w3vHNf2v1RAmwsZlaJRPZv D0JsDbDN4kKFfccQq5r6TkAQ5iC1fmbjHoE2puzqPecwzLlkl37ixVcX8NqT7SfnXbaYMS8Wl4m3 bsmgQD8Q6H1VcqEpHRgJffxye+aED5h9gwIQU6ivjEBbTphWDG0ZS8YsXyTLdLhWDBFmSaGGmhFH /+xCiSXsMcSVOW5/oRzeB6R2YRvUHHE6pqV/VqAO6JUAtK3VQoWXQvT15aerMQSfEzU7svwsgudn EDxbJKnrl1dbJaCCrteCdx7lpZAuMlGz9UzNXzYxXWdcsoPbn+J9BOQG3CsUqInputWQAOa6p1bX TEHOtq5FIhrCJPshv71Qg25OsNnvgGv8MemvhrWirxOEoywPnAL0hCchVbjslfQn4VWkTuOxgzYP 3PSFCAaOKd5FmF2PrAjuHVJfBZy2sK5hpM2tqAu004Duklx73fXKy+ytRT98dfmJ73g1toc8nyfr 9XAPoxieQxYM1o7edz4DfMdrIwheW8gUMGgqlJ3hwi8m1WfUDTOlFv3ugjJTnLnxziwP9+QOWnAc 9FFBnS2T5fLLNsrie5Z92UZtEsxJKmZ5EPrMVRhqhfwiCTzBlP4LIOjQc5HWAjnAA8nre08HT/K6 ffCQ7ZMk9BgHnC4PWAmtw+ObB0cWqm5UAc7zJCuGuzqLM/NxnGHIWqfHEvCOIz2GIDPo7sGF4Eoy lNIo3P9OTyte7SoARRWXUUzg8lD8B3JhJ8YMKAOjDyJk+oqeKTK0qSVFB55vnhAdWYxZ05NQhd00 aHH6uAOSWtJg+4wIUN84hkD1Wq6Rpp77XOs0NOg9+0B4W4+ndYkb5f2oO36QPuJIF0RSmHPTl4v4 yyA8Elx+7e0S8STyWDtHWxfBFWyJZPeT/8y6pye/STtnB/fdoewP3dQqLt0STl2Bw4siE+9R3GqW SlIrgA+ly51MRR7DbnqJzSteI3W48l6Di8od6xbXU4Awtx5hdMPyOA5QxFyMTFiGmtx27+G885Fb wbPX/2rPgrvbuymlGauBbL1KVouh1aNgO0uZ+wzWBrCtW1Pb0WygZFQbW92hPhA+7re2Gni/MqvY HhoW6WNUJM9ZdY9aeIIRizMYkWbJwpX6v1sM8IwMGJRDTJ+Xbrxhp0ioKEBgdVsJ2eek8oOJg+3w Ox8sqK2dfsSM4NnNKtFl1SUnl1BgRJ9vRSA+j9kI+Zaeq5BDRhgj6VXdxODbKT8ewS2YwhuhURZ9 qWcjIyIeeD6D83XBGirMhlo7UzmhUKN6o9Gc8U7gStELh5V5NEY9Ng+k9fwfw4eYmVB+YRTfQa6s Jr99pD/+zvf6iXOwd074Bd77ix9bGeiDPyY+2JKfv9HleGTzE626vqZFiM8vfJkAiAERn4/THOdB VpOF1+EwtyUkWUBzcD+upCKWdlR9A8kv3z3t6pL4oxt0+AofreB0mazWw2eO2Zelax7MDNZKDx+e lVSs9hzqIXtq88c0EEvjgBPfbdg/nMQ1Wj4KG1UzHxQNpjInSqawEGtL6QTmTM86oD/wjAyw6IAT NmJSK4O312LCgnsdq0d9F/oMaZLahWSQd3Y440Wim4fWhnNJ8CsJBw3XA2agu8qWHgRa58aCxrI1 8pNMlOiuQ3Enja3TrP7is4gtroQWUb9hekOLQ76zp/a/hDxHB6UPu9d6fU5Kb+WAMeDQveumbCvm PnyQAK5sh2BPbkWYfqHx1g2anZ2EBWLYqnprBwRBWDy7abKIb2yvar8ScVsMphdGd77bq21AQd8M exsBR+JMxNwodUwYZIfhiEupsXMaeyI3cFKV/GnUT2xLgIrXnJwvksxdT0SEiuqChzgwN54GSwoZ O8q4sIxgy1sXP5nDHocFtZyt4gyC1DPmIWcHs1QEWTo05GwvXY730pxky8rr+lbmiWyNpaGt4zPc +Srd0V7JQDChLUOD4KJULjXajUMLe/zk0JhanqQ+NVKWYh4/MONuA7XAHeLZ3MgMNzQt5fIA0y+r /CzrEvvd6UPgKvFQ/Xy0MxI185dK6oWuBodJB/uVd+4Omk0VGL2fIBz1WviirbYC1CY6j4ygFB4M p5jhuNWfHQF7av8QN0N/z8QVvxvvIDu0dvPIDjNqvkeN+rdHbLdoy2BXg2mpHlPD1JvS2GuK1XG6 VNfl74wD551drJPZwl6GK/BEZ63pu2e2PhxEYWSGfakgk+Er934BGj5eQaBYRHpsML+201pxxHHr kgjvmMS5aaqTHxskmWX2kew4mGCTH+mxDX7sql7M0/1uavtsOAP0o7Ad5FLxasIu82ThWAG1eK3c DFGEisGsxEpKmfIGr9Ussi7UEJBtrjPs1qXas3n6GThOqjGdh56JfQ58gm8cjUxjHil5eDT/ZcfY XgNiioNtKyTbngUWOSS0V1bMETw0vqVE043zvpoXybqI2QRGsfWj16PxgVQdifoQP2dk1UJNj2F2 uibVNXzgWcguxiE7y7Jk6Zj9P1iOS1oRC3GJZVgyw/5DNzo3WaTJKhvezRMCzpEBoQOCfdY+H0Aj KIo6kvm6caKm7KLpKy8IFfKC1g3h4kmtP2UfHdWqcELxwtmnlOAlfyvKLPFdAs7yt+UcXAIXXsmS WZFk6+MsMf3Y0T0MpzbVE1pcAidailARkdAIXaySMlFDGrxEY73k2rKbXpwMBoIxVquvA+3rQkkF XOw81xKmbw9RPHjymKXqurAjcJyzjuIc98xq49wxOnwl93AAvndmuoXiPmhUkSKtTyOjTBXNSUXQ CqF6ts33qv/KHkmEYxWt/nSQdlfJMao7xDXaz1jf4YljUxMij+t0uMWtQj3IM7bATkC2fPCMZ9gh hIcLv/uvfAczh1J6c+UmRhcx9d28jmNpsQyvHmGGyxg16vh3yp8Wq3c1Br+2dOXUjLKJOTlPiuf8 2kfHPhM7YtZCftyAuZaHcMBJTzt6tebd+ItDC54XD4w/i4mrcUxMmdQv/diY38WgH33mXSE/MzSq gXvuGPMaSYWQHy5v+KwHvN2/tCLqPwLMey/0u9D+gy7vPZ8Winh0ZI/XkxYnL0Jw13U8Uk4KOJ94 rBmdRmkOxlO9qUbfEHRuIsngX7Bij3SV3kDWKpSUiDpkjyAv3lIybpNnX60UQgEnWTZ2648n4hET 73rshZM1TzEHRo7OQNY4wR2sBXb5s1fQLB4MYi4YH8QvT+YBm2ojYiZMxMOxEw7UdTc4mmdot2dl RyROkJQz67VYZDg3+nJlEflTNxyT6IAM15+8dLl8OScroizctEmXuqYRxfR5MG+wEuDFKOK43d62 ePlRbh7j++OwPf7q26LoyMH553nvzUhhRN6z/UC0z5G0uWn01Me9iOe3eGOFjXIvYXEvHR6duhzh iYQM5aPDXpTLU0Tql5KEeF3C8f/gjXKnbWDLwJpCFm7rz8OjHQcq3ghYbSROErLR1zLnq4zfCR74 6QRd/weDZJBGDQplbmRzdHJlYW0NCmVuZG9iag0KMTIgMCBvYmoNCjw8L1R5cGUvRXh0R1N0YXRl L0JNL05vcm1hbC9jYSAxPj4NCmVuZG9iag0KMTMgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQg MiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YyIDcgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1h Z2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRzIDE0 IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFi cy9TL1N0cnVjdFBhcmVudHMgMz4+DQplbmRvYmoNCjE0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoIDc3MD4+DQpzdHJlYW0NCnichVXBbtpAEL0j8Q9zXEvJxms7GKQoh5C0TaVK PSDlEPWw2Ausagzyrpvy952ZtQ1BRQhh2Z6dmffevF3D3U94eLj7MX99hvjxEZ6e5/C0GI/uviSg lIwzWKzGIwUx/hTkiYyTDPJ4JidTWGzHoxjWdPk6Hr2LVw8Q3aZiE6VCO1iaSMXC1NEvWHwfj16w KlXua6kkldPJaa13ARfXTmRytnYb3WbiQP0gmolddHsvltjYmYba/qGo9jZSCmP3osYQ+AGdR6CJ aBhhYWp8zMVbSjlzyoByR/dFG6k0NDLYg2p47SnT7qgUF8WA178NLXKcq2to62giSoy2+DcsCqx6 lAU1pYADfM5DlX1jOLto7BLh2hov6yi7qEg3icksk6pXhOg3DOzDRVNhGiZJb81GExMWJUCn/o2k zoBQFzu60wy04qXNGgEE5OYviuNNT9jfkFh+Y5mBddwEcxIq1YvAc2Hh9pHKhKf6/DjMakV3/Eo7 Zwd0oSUzoZK89APJuI4NC+MxNYyZ43ti2GhKshVd/AABVtpWLTJkeWMBtr6maD6V06RT1G8M8GR1 U0XqvqtZ6gMCcKxcx6VzluoJEGSzlJ0/YNEbL0SLtsHRMkHyXhlMStZot5RY+3PnmhM9+w1mHakG BcmCavyfVZrP5DQ/Y6VRxUxUBwajCyrHEyCThyk44oZieZJZXZVZwjVVJ6lMs67/N0wOgzXYJTTk ad6A9ewhnBquqQiTgxZnH4a3PHB0STqzgQ+2XjPQbQCI77lw4zVblZyKLFZ9Q5Z8++louO0UbkmS kimy0Yitph2IxsEJ8k5dsctZcJrMMI+K0PK21rRPEq6D50CJi8A2jal41Mh0IjT1IQNfUyzLZd4r th92dmHKlrxjnDxuubeNITKNYeTkp6T30/EAQ1PRIm+PnOlIwv2B9dwNlMZZ4suRcHYXwxbbosrB FMiCisEWuR01Db62Q7f9oDhNQgXG8gLjLE1lnH5mfKoOvPyYA5x8qNTJh+pctiSR6aUa/wBG5Zjw DQplbmRzdHJlYW0NCmVuZG9iag0KMjEgMCBvYmoNCjw8L1R5cGUvT2JqU3RtL04gMzQvRmlyc3Qg MjQ5L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjI5Pj4NCnN0cmVhbQ0KeJyllm1v2kAMgL9X 6n/wP7g35+WkqtK2turGShFB2gfUDwFukAEJSoPU/vv54qSlhWlNKnHxvfixnZx9h7IgQWsINGgD ShrQCCpA0AFoSS2kHrUIjIxAx2ACahJQWjAaMJRgDKANwCgIMASDECoyZiEMkbQhohkTQhTTWgSx IdxCbL0JsEgmFFiLQD0liUcfhY0BKQwVkFYASkvviSTFhREoI0nPkqRYFP1QSYoZVEghKtILiVfU teRa05KNKYSYujHZI6nocXEhRh6WMBaJuFVi8rxzIqnK/by63ritGExBPoAYLcF4pcvL87O3zOgU orojujtiuiPYHQm6I2F3JDqFaNsgyS7Nj6hWXQwgbpBa5f7rj7G4n/0Bpo+sUop+zKo9DuRnlq9P boX2Cr4ISHzqVZT86O5LdqlY4L88/ydTe6Sq6pGrTREp2b2KOjG6B2N6MNiDCXowYQ8m6sHEPZh2 T3ucjO+ZoGXSsjqJ1eXjr6haGBbIImARsohYxCyYM6xiWMWwiuE15DpCriNkD8gekD0g48g4Mo6W K+7w6OGgJ6Vz46KoxLjYuLt052+j+iRKS5fXq/5eqst92nwu/1VeVofuqRq4Z8DG9A3ZyovKiaF/ XOeL18GEVGfFk0jcvBK3Ll24kvueafvf802Wu2SV+gj9xJecLKRVVuTNuKyy3yl16tGvolzPimIt ror5fksx1TOPK+cq3p+7dF4WB+NvK3oejK+ydFMsDyaSTbZwB7rsh9SWZboVN9lyX7rmXYf77ePU /xnhXVHt+ab91V3vmr+7Xz58/8xoj09zcHy+zZMH8PY/lyxs413GnJ/9BUOMZrYNCmVuZHN0cmVh bQ0KZW5kb2JqDQo1MCAwIG9iag0KPDwvUHJvZHVjZXIo/v8ATQBpAGMAcgBvAHMAbwBmAHQArgAg AFcAbwByAGQAIAAyADAAMQAwKSAvQ3JlYXRvcij+/wBNAGkAYwByAG8AcwBvAGYAdACuACAAVwBv AHIAZAAgADIAMAAxADApIC9DcmVhdGlvbkRhdGUoRDoyMDEyMDgyMDEzNTMwOS0wNycwMCcpIC9N b2REYXRlKEQ6MjAxMjA4MjAxMzUzMDktMDcnMDAnKSA+Pg0KZW5kb2JqDQo1MSAwIG9iag0KWyAy MjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDY1MiAwIDAgNzA1IDAgMCAwIDAgMzUwIDAgMCAwIDg0NiAwIDAgNjE0IDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTM1IDU5MSAwIDAgNTMxIDAgNTIwIDAgMzE0IDAg NTkyIDAgODkwIDYwNCAwIDAgMCAwIDQ1OSAwIDU5N10gDQplbmRvYmoNCjUyIDAgb2JqDQo8PC9G aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDk3MzU3L0xlbmd0aDEgMjA2NjgwPj4NCnN0cmVhbQ0K eJzsfQl4W9W54H/v1S7ZkixLli0vV5YlO5ZtOZZ3HFux5S3OYjt2sOKEWLGUWIk3LCchgSwQJyEO DBQIpMAAnTclLd2uW9qGNwVCmwLtIx1aaB+daSHweG3pK/PSPqA8Quz5z7lX8pKUpZ2vbxmd4/Pf /2z/+c+/nXMVWwEGAMwIZNDpX9/e6vXONACnvwCQdkNzo79nSvGgFuBIH4Dy282Nq5v+e8nDjwPc /AoAd6jV39xieMs2DJzmVgD5htbOdet3f4XVANxuAFZ7Xev63sbCN+4PAHtqHGDCsm69p6z76TPt AAzOh4HBkeC44ZzhDQBHHgD71cHdk/zG+t4XAar9WF+7bXz7yKvZvbsBnC8D6Hq2B6PjkAoOXP95 nG/YPrx3m6zvqVGA2nsALPcOhYOhN4ZXHkD6m7C/cggb1N/W6LGO/ZA3NDJ5w+ZvKx5A2tUA/O92 hidGLb829wPs/DL2vzI8Nhgs+pHzxwBdRQAZB0aCN4wbT+hew/lnsJ8fDY6E1VmvlQEMT6HQ7ONj 0cm5++FB5OcLpH98Ijz+/Tr5SoCyAgBFJhDZyt/93pP2w+1b9HXvglYFJD3xq1MryPO5lqGpP+Zc flBzSTWAY9XAgphwnvL+2RoArQb779ZcopQWJK6atCTVw0bUG0ksGMAD27DnJ7oecYjsBfY7IAeV /H65F+sPik/mj7CNmWX1rEzFyWUKjpVdAHbOB7ItMdpr1vM88Ig8oqiZrWGCyvuZ53hgHqZEL8h7 yU6Bk/vhKcrq98Qir5p7P0ZB/jcwAEsS+8LiNsX3YXMMl7115fhE+o+TZG1QJ/sfUELx52BA1gD9 FF8GeeTJTkE7rX8HaslTmQPtspfFtljiZqCd+zJ0STR8f0X2EymREimR/lMl9qvwjX9rHhIpkRIp kf4jJS4I+/+teUikREqkREqkREqkREqkREqkREqkREqkREqkREqkv2pipd/ASAWOYCyAgvkdbfn9 0t/NwDon/SYH9zFUxZkc8xuu8i/iTvwdEGW8rpOeBgpNHzv/MEwhPArHEB7HcgLL7VjugDulEffA SYT3/UVc/jXTx0n+0yUZfBWhC3jEFIipIQlyYSX4oR3WQCdshTBshwjshFGIwi54ZG6OziPj+AXj ghCSxo3AhDSOmftg7j2Aue/FMlJelOcG4xbGf9yuRUvybQyHtly3eVP/xkBfb0/3mtUdq9rbWlv8 TY0rfQ31K+quqa2prqqsKPeWLS/1lBQXuQuXFeS7nHmOXDufk52VactIt6ZZzKmmFKNBn5yk02rU KqVCLuNYBooYq2Bt6mveIaQ3DQg6h99h4AXd2otrPAKk2OwOI+/1BIqlUYLcLYCpQ0jt7JsBX3VA ULiXDlkrcE7DH+w4eY2NbxZkTvxxrAqGhILuPrvD8DNbvD+Ac4SMpj673SawTvxpxy78WRXkQ4Kh E9vtNrGlXYDOPlLOzL1RjY1QbQ8g7O4TsmPVQOBqTD6Beji7hM21zLRhRpfe5BcgdQZ0bwhgJsMu VoMAdUKBGxkxIEapgUdgUv8gMCaBMa9BlhcvQaZdqL6KDJpDOxzNoQhKNDQwL9OLokTt/DQ/3d1n 9CJKme4Qnu/qm9FqmhxNYQ02AG2AGY0WW7SkAUmMzzC6eoYirK65doYFVRKKL4Ww20zKDsF3YgAR hx/lhj2m+Z4zc2dvW9gFOC2GmURMZEJQNAlKkQk+IviCApzgZ4rOTt92xgBbB9y6kCMU3NQncEEc MAOcs3moR8js6NyITbgUloEhnqjbTwFRHt88xE9jnYwdQOjwE6Uvag8NhQeImTADDj/2qZv6jtnP 2oQUfDYLRreQhMOS9r1p46abrRGeVKenj/HCI8jugl47gWgEVmR9utmBqyGx5h2NRCWeuNqoNbaH qHJ8J4K8cGjrDtH2grfF7N8+bRB079lRO6gfnEknSqIMDewgLO8Ikm027+CnT4TpVm+jW0N75Zt3 +EkhE9H6oRdnb+xrHnI0zy+IG0eEcy6da7cL6W4ycXq6mbAYDCH3IsvYMc8/8Qmbm0F+mgRfD31A D9UBrugL+gNSkzRgI5lGegb8gYBd1DsOFZTOY/ISBz9NKCqdQqrbYD+HfWeLizq6+5r9Nrp7gW3q W/G21fY24h2d8WbGimOmPW/bRBl1rHd0dIlWMBQDAz2iA7NxzeNQaTylet5qOy/im/paHC0D09Mt Dr5lemA6eGbu0FYHb3BMz+h00+PNAzx1fwbb//aETWi5LSAYBoaYWqohQo4nttfS3SGYuvqJqlr4 oaAYOBoc9mqb3Rgf0/mnuiWfQ+tHHyA+N234HfKmw+hk41tIqDmDEcImGKqJyyJDvX3oE4PUfilA X1mPxG3Ea7iAszmyXhIWWqZkPCQGdkmtSMRuJ/504owPtmJFONTVJ9Z52Gr7Ovg8btTjAOk5G+sx 95KeQ7Ge+PQBB+rN2rH+Y+x7oW1PGx0pfI2Hyp+G3pBwtgf3+H61oKqWVG9q6uNsrISxNo5gGjeG sjohzU0nEplgxJw2OPgXHYLBLcib+s7a6gK8wYihjsExbW7iQRhRX3T8gCFxFFINAlMnMBbSDhhX aXjn0qqxM25IfPP0gGRpC7clHQahoavvDccYHLg9mzjemOIgO3yBhjcpajtbiF/Z7OKIVQEhmcRm Ifl3FCC/tqY+HiMRem4XRfhmfogoW+AH/DQkBGwLm8/MXRjwkxCILJMhNsnEEYqiXWxrxUWf1NAP oaHffFtgqBap+ApxB3wFLku9padPklK1TfIoslY72cri/rgUY2NQ+eh4dqE04wdWNNQM69uBq4m8 o2dRbcFitK86Hhl6+oQWd4y4WG912xZW25Z0t8e6MXzst+0jxwgLjTMO5tauGR9z6/qNfU8Y8FZ0 a0/f11mGbRpoDMzkYV/fE3hR8tFWlrSSRlLhSQU6GKT2dVZFx9ue8AEcor0y2kDrg2cYoG2qWBsD g2dYsc0Qa2OxTSa2+WibeKtotg6hCPocqPSQ4OvsuykwND0QIMIGi2iAaNmOehBYR/0Mwyp0gsYR bhS0jkbS3kDaG8R2BWlXOhrR/NE5eOLq0wMOdH8MwH1gYwLEhIm5sE7+zNwcRtDzGHntgsK5CQsG WLU7wKMVr8JxraQMYHOrcGgwSPggZsqRWN4+GBBUcYI4pF1QIwW1RAFHtNA55BTASYNorEEHRbEZ neNQQAi4yaJ9EUKA5/E+1OaoFRQukabcRRbyBKZTHGX0OFE4BY3zGHmokTcSCGmLDau4WEAUklKH nA86sGtwgEdpy2BwPRqjzEV+NDaxJYynuswVpkVjkzpB9CBtkkZQl5CzSklxbQkSxB9lICAyT2vH pAG4tkHQIkeuBaKUJqB0sKud8II/x5BVMvQZQqbrDHQ7bkAfJExTSkrsFpKc7UEMOOJ8LbY4qmOT kZaKNhEa58RWJdm5jl5oe87MnXbstS9IxUUOPJ37iGGCDe+QPghML20Q+jFwqpa2JtHm6WlV0tUn iPJSJcWfpJFvjqCtAo9nCopR4WoPnqhOKS9+Angm+3G1lVnFn2GyYkhmDEmLIZYYkhJDjDFEH0OS YogmhqhjiCqGKGKIPIbIfG9R7BKFH1D4WwrfpPAfKHydwlcpfIXClyg8T+ELFP6AwucpfJbCcxR+ l8KzFD5J4QyFX6PwNgpPUDhN4XEKj1J4hMIpCg9TeAuFN1N4iMKDFB6gcD+FXRR2UthOYRuBnpUe xgUNWNZh2YJlDMtBLHdgeRjL17A8jeV/YtFCDpMHHiwNWNZh2YJlDMtBLHdgeRjL17A8jUWLinT4 bmBeu2BJy3z5pwhuvMliu/Gm9B//BPHdexCMjCMYHkOwc9Ri2zl6cCJjcleqOXP7DgTbIgjCQ6m2 8NCR6zPSo5Z9Ten2vViUz6U9x/76N4x78htM2lNM/s8Gnhp/6tBTss/ez7p99zNb7mY+cxfrxjuA z/BPtqwa9aB18LlBjh9M0teQxqLWHGeN4bHwgZqHTjlyrPe5CmvuO8W4204x955k3YaTDb6an59k tIJNmBK4lUmMkpGjObsZhfSUSU+5r30a3CewHMcyfUThvvkg495/QO4+MJWbc+sRxn0My9QRufsw FluV2VppNleYU8rNeq9ZV2ZWLzcrSs2cxwwl5jMM7zvUVG935ScX5Ov1hUzB+3Pu9/9V/94fk995 N7n0vdL32YvvM4Xu5CK3PteRnOfQZ+ck8zl6vcGoU2u0OoVSpeNkch0wrE7BhXK0+g49q4VrwM9t U09yx9RfgkfV/1uv1oKW0+qvgWvUAa5fvZub1D8AD6g/q39C/b8g+QnGzuT6UvQ2JivJqsxIMhvS klJkqUk5K5MZO/loAKEBiwdLA5aHsTzN2H0uRVFdYV1Bnasury63jq/LrrPVWevMdSl1+jp1naKO q4O6Tm8PI6R0QEdPo2Bi8Lm+UfC6O85wfLdQ5u4Q1J39fTMM818C2Cqwt+Kx2CPIbsWTsAdfuDb2 951h0kn3EYwqDANCx8CR2wNud5YQItewQ1kBoYwgd2YF8MJc1iXYHI3upSk6KT12LWoV3mkW3m+O BIX38Y3tPXwder95QHjP4Y+KvYXNQlFzUCjARpfDv4ggs4Q+4ALiGuQRjeJSUYIJVqEB97uUnxk1 2XhndyN50+gQQvieYOvsHxAyHI146cdaZWc/3h8bo9HoDOAtZYYlQIGgv79vZRaTDSEmC0smljQs FiwpWIxY9FiSsGiwqLGosCiwyLHIfGtCl0IfhH4bejP0D6HXQ6+GXgm9FDofeiH0g9DzoWdD50Lf DZ0NPRmaCX0tdFvoRGg6dDx0NHQkNBU6HLoldHPoUOhg6EBof6gr1BlqD7WFrhD0J0mBP2uWfBqS AeS9YAA3hSArkz57JB9KXRDxuYtz/5VAEQeY7RbxxUmxHwzcirmLLM6aewRHGD/uwzmSVFKhH4Tu h1fhedp8DxyCIXyeghOwAgbg+o8k8u4nWWlxYuqZSqYYo+rfwHGmFB3VCrdJ7WVMAf3UUEwHYBe8 CA/Bg/AZiMIQeu0f4ALcgj1bYTQ+ivDXiBlgI6jiayQzJfAOANt9FQZehhdwRAr2vwjXwQ2wFu7F tX4Bb2DfAPwW15jntSgOp5GPR0D8jPdbtHMr1o/SNgFCuDrAYzABqxYvpngKVOwk6udm1MsF+Bk2 7YJeqI+vUMsUov1/AeX+JnJ2LyuDXzAfwFlc4yKTjC3fwh1fYF6FjZwCubwXLsJu5PsXs6/M/nLu oqwdQ/lpZQcQNT6F4Ki8BwqgCEqhHAp8ZpjSpx+12k6aDffl6k7JzRZ5Zq4eGhoaDL8yvGl4k/G8 7XlzeSlTUV7PVtVzFeUuR24yq3RUVFZ6y7JZcypWkjmzOc3sqGCMdiMpbJXCUpiX5rLpV9bzpXnp 6oG6400tg/WZ+ry6It5lVqbcyXx4WcEFP6xmfm2xOAsr8tM93hpHR3dqXln2LdklWd6WZa76FS3F 9qL8gkzF6Oc+N/um7P5L22R//ODLyD1L/iZSnivfBNlgh9N4q2/q7fN5ecB3wxxGbpcb9Ha7zWJx yNV2tT6H4XLuwlcNxsYxjFrPKc1WTpOmVmse9avB6nEbwWtM81obUmo8W67bnPG225gCNaWM1VNm rEGujF6v4djZs6Qst/ly/myCAcauVCjMqWlmewWKEo06myV4ZSXKNN9p57j82V57csrQbK+zuiSD +RyjZVZZskvdl18pL0s2zA4wQ48wp7cUdBRuVTY2yopWt8quvfRIR0O+urFRUVKYs7r271kv+SeU AZRNHcaLTCiGvZJs7JnFXPFdmb5M26P+TE6fxWXdpffpDY/69Yr9+fmerANm3O/ryPDr4HFDhtXw thusDRK2vNTmS/+TBMiOr5wRYMqyOXOqAresVDhwx1yFsbyEza9gLN6yqkqScdtoS0p26PSFr+4s b29f+eSNOz43W+t0mxVys9vFfC6lfbSjOn+lPW/bEzfX2+S95eMPnL/5wff71m0zpzRq0pY1lHLX eXwF6ZrGS3kcby1sHr3hK09d2kP+TQllwI5QGfRIEjCnpZpTH/WbOYVapX7Ur4IDycnZWcYUpsZK N41KQ/YRkt3qlw62LhoQcKZmc1SPsV3ZzegDLCPTpRVkXf6X2BbYpGX5qapLjjpXhgl1JrK8pbR+ mVXT2KhNz6utJv9WtRkjQAh5rYYvSbyWV9p86tQ2m628ALxV2WauvNz7qL+cU+tc3DJtQcGyR/0F tozKytwqs/yg0VhbkZN7cwlRYFkZUaHXm0KsFuYtEZE0r9FrTMHNuukOHZ9giYW2vJRCgElmzcZU iyUuhsoqB+qacTCufIdlcZfLhRJiGLsiVOHS65w1l+eKck1qBWfW2Zyz7wizv0o3pWiSC8tnjzrd FnmSq5r5PWNmipifyk16xzUdHz68otWpb2zUpWRd42d+2/WLkoI1g5dLOHez//Ovz5avqnUloXCt BfWlXHB1dZ6h8cO/4yokT5A9hJLNhkK4Q5JtfibP8Xf5MjNTlamFXOFdqb5U06P+VE6uUqoe9Sut B/LyinLgQBIVp+QQoupF0ya+bPVkiF6R/dHE5s3mirnEhNjFJlRmQX9ROHLzK7xllXHvYDRp7uLL v4qbVPPlD3df+EKwfkNod03N6IYW1weNVXaLqnGxQ3zzO0fOhWXX19wUGbqxnCWyqMOTwMBdxMjv hYuSLNZol3HLHvL5tJ1adlzLaLUyvTnHfNDMaTizzWbgDKd8NkOB6zSaAuPlPOAxeNhUmczDee6V WYDRFsj4Ka+3QpXqMxcdURGJvZxx3kiEluaFBgwIGP6I9XhIaMggAcJwDptwwObrJQmu+PNZ8CEP ItmPWybgzCeCdbkqyvOcomDRVB0oe2+Zhdgq9WaORGcLlT37eX33A9duOLgSo7SrsLGkpKky6clN +/Zc59n7mTZFUmpWwext1gdO+utKuksPyzvbGsbb7/6iZcvm8DI+sO5by4qydL47D87ua2xzmJM0 jcwrsuGh+pXLu0tQDyWoh375KchATRyP2aRScdqvVDMabQGXp8/j8k5iaLVkc9bsUz6LJSPlsN1e qLFNZSywSdxnjbRd4pnWhu+LBvnRlNAgrzoxYCov4fIrnOjr9aw3bojKfIYKhB76KJ2HWQ0e1kza jUzdxm21X/965MVTDx1edYix9wY2BTf0F22oljW0ra7mU9WNyZe/x1TVOS598JW3dtXUpDAtN+56 5hvf/25Jr5f4JcpgGmXAgwe+IcmgIjvrtD8bX6JTketTvlSDQsWpHlMo5Kf9CoVa4+HcSW7OfdKX ZFGp0ziY8niWFxw2xE4tYm+xHXmIHRj+MW4MDQ1UNMs+8QILpHNVWgGG+q7cUSWaVUU5uQtZ0iqo Hzu9jCQuyZhkmfKUAs/sxb1qfdvD7d/65ujPP1vUW6swucoY8/7Z17p76wPFG/rdvbVM3uqWQpum SX0n077ug0uPvXWD1tC/M+DJ0DQlX4Z9uwNfiH7/u+5ALUqwf+4i96/ozekow6clCdbyJo4/5Rs3 MXpTjmmdaYtJZuFMJg2nwdP6lE9jgHRGy6VznIWznPRxlnRImcrIyOVNU4qYYf3+2TJY4EENGbGY hZXNksd6PuUyi3zyKhQDzoVCtKSRbLcQ0VVx1FOV3Gvbnr/lrX/a++rd/ce38i5TKnP5KHPwltX7 Wp+UtXWu6Vd/a3jj3KX/9k97CzsqGrrW7/7ml2ramI7P3vvg3cBB3qxPloWSQgOBdYxdklXAx6/N 16g8qiqu6pSPU6k8BgbKynB8q69M71nBrTjl8xgMazn92py1nrVcGrfWl5zSttZnsLZwLaesme2p 8qYsncOX5Shk2DKuEORHamu7yqcKJYv8/bMpaTWGc+cyDOcxv3yehkOM/efduPF5c5LEQY/VGqlC zm4i6JV/GY8+a2ZsmU+xbIDJV1qI/6P7Ewu2eOPhoIRFHVW5qKbog4aKNPvCGBGPoTTKOnJlWV+S ZTpfOj/YUJZeV/X+6Uf3vvHA9WduaW1bWejKX1m+trNp18ObvGudTOTy5tbVze2t7ata8/Kc+48d OGxt8X25ndto0mYG/V99PKW4PJs33nJ85/1dqRWbWmsGcrPX1ni6mwqK7hjYfKQnX6OYffrAjRO7 brw5+uFjmY3utuae1bmlPDn52hGskI+h3GzwuKT/Go7luEGfnl3HsnMso2efZl9DRKYG1sCyBo41 PqbXJ5/26/XpMpvstN/GpLApUypVVqZ0YzxnODd/McAIQez5us3XT0hOUvpp6S+4KiylFmDwmsDV s9I9AYN0arYMzyvmx7P/Z8dyZ5I63Z3LmPZzCm1KbuasVT727rsfvJRU2LaF+fHyujyT0q+6XFO9 wp5hSVE2kvtmLd6KXsToWwdnJGlULis47V8GbgaKikyc6SFfUVVG0UOlpTV4Sz/tr9LLVVbOpszI sJ32Z0BqeY1GUV+UOmWnUcPw07JzGDoWXza91OjeFnckhl/3p1nD+tHUAkzs3Ym8OuWXsA6HOXbf lBExiWeZtwxr5eRyjqc9l86wNZUF2bNpxQ7vmgw+J7NU5/TOWrJzTckyTpPqKmQsN9kdBe6NJYZr mXfyB7aze2Zv6fXZ8OKudmW0dkzmO1Je2NLmxrum0pSe3+zjdBu6quypqsbkD7+ZnNPV4LE063w+ RR35ziG0OcUFjDoB+IkkY58qT0vPY60BGD/nk/k430mfzBB47NprN5z2X6tPy1he3i5f7U3v6Fh9 2t9hnMpWFU1VZ1dXZ/cHoHmqM3a/r/F4DCh26V4qCYkYzfyRLsqKButPuaok+Y+kGmDSpFAtfQRg jL0NiSbqyE2WkTZ2vk1Gz8P4O8G8KTM/1PXftXrVVr85fLKrM+LP4XRml202uzg3SZfrcWUUFfMm pdzgcM7mlTh0cp3Z5sx0dlVp84pn7aXOJLkpv5RJOcD1cb0trvZrrltd2De1afbuojUlWamoN23h qi2MbuP1vkyDPbew/JrZv/W3FWWRd6/C9gFG19hfXZiRXNLtmd1/XYdb29hIneaBVa1umwbf+agW ZSdRizVwUtKiO42t4TLSM077mXRz/mNOZ95pv1NfYEwuTuaST/qKDd4pheKa7IJ801Q2URh9Y8L7 miS8uFC9VKZEQ/zHUYzdRq6cHLB/rHyV9D4X05Hs5KytJC9JkZSWmZfp6q7WOT2zWfNi1Ovqr9te 0z3clEW10Kh1t29htK39tfnpOs96z+zBLauukNKdXFWD07Pxlg2zd4lSB1FuHJGbC85Kcqs2MlpQ GVSsmlPJfKw2RZur5YwymZbTEnN0PZaX5zjtz9Nb0q3pp/1WlU+pLHDh/SQr/labcX5RvI3d+/G9 6jy5/otHZsmnW2Zx0L0aScnW04wOchXBd/yr2fDfJbXfv3FF0zeNVSWWimKTIrmwbNa0wDq7uA2r k2Z/V1tvW+4tL599Zstqt3qpsaHUuvBOtxGl5oGXRKk9AY6533xbbWjTOBwmx5m53/iWixUuzeQz ZXKZp0wG8OBly1PkK+I47lSRxZqWlp9zRK8vyT+iUCwHH/lUIOM8MUFSjDUe8SIibTGGko8L3EYC UIhXrmr/6FV9RbE73keQDZgssWtBfgkXuzGbHSRc0HtGmvhZInn9/Xvr0LUdaxxdW6uCbYVDz9zU ftvYVFpVY0nj2sy27dftrq8bvq//8z9kkvv7/SuX1Va4rbXtG6s2TrXoUt/ytdjqKl2VXnd+79iq rl2rnZ5/Rsn6yPsGdwGK4UTsjctYnAJQfNoPek7lyXwsQ5uVzSntSk550me3ZGWmTmm1HnbKGXu/ 8C58v/hH9Gl6Lhmp0WV9JK2FLxOLJgZMdhIk6SuC9AmAcfF7hYu6dr6POaLLXe5ydtcojHnLmKOx twnd5rtW7ThYjee+yZ7JXbj804HhhqyS9R7mlvbWApuu8bI/9jrBbfCv++xeZrS6zm7DWwDeib6B dyK5vBfvRErI8Ok4jlUKCpBz8q8pPK8/a3gWPJefbVheynAOjn6gK+//wjqmcPZf5L0fRrj7Lv18 9idMCblb7ecE9j28SxA6Vp9GoWTPcoxMCZznlz9DU8s4T34XllCRE0pH131mGbt37V0F8lOz6cyv GQLEj7hDUv4DycxkPP9QzOwemi//587cM7ImzG/K98r3KvYp9ilZzI8rH1fdp/ZK+UeaGzU3amWJ nMj/rnNBIifyv9PckciJnMiJnMiJnMiJnMiJnMiJnMiJnMiJnMiJnMj/v2TxTyzo33wwYIezIAcF yGBq7vcIj879CuExCu+b+ynIuMq5RlCCbO5xUCL+BpgQb0J4eO5HCI/OnUd4jMLjcxcQnpx7Cw7j yHMwReExCo/j+H9GODX3DsLb5/4AtyP+NsKjc79EeIzC48jD7bjuS3AHnXUnhffg3F8inJp7D+FR 5OEeHE/gcaRzD1J7j6sE2exvcE8etlb6I5Ik9lT8D06SYZjWxG/zCXEyCWcgmRuScBZUmtgYDmo1 ExIuAyv5X8koLkf8yxKuQPychCvhA80vJFwFhdpuCVdDi/ZnEq5RauJraWGDLlPCdVCgi60V45mL 8xz7xp4y3f0SzoBS94KEsyAzhGLf/gRZhi4Jl4HOsEnC5YiPSrgC8X0SroT9hqMSrgKz4RkJV4PD yEm4hjsSX0sLbqNLwnWQaoytlcSsNoYlPBkqU2bIN1vJ1JKcRVyUs4iLchZxUc4iLspZxEU5i7go ZxEX5SziopxFXJSziItyFnFRziIuylnEkyRrILgo5wCMwS7gYQSCsBefuyAKYXxOwhBEEOdhG44Y xTqPI0h9HPsncHwE2yYRD2HbVjqXzCFzm6EXVsNKae7Egp5xrI3hjF0wSClGkDIPe+hagwivvq5Y J2MHYRjnhqRVJ3EEjxjpH8cecQdBHBeS1opIFAYlWmEKS7Bl6b5J/zDFCnDWMnyGsW9rfKWrcTV6 BeVPLqN56iFKaTu2TWA9iiMmqDQmEY7R78O62t7F1a/k65oFEiA7EfcySdcbp9oIUvriXkPYsofu fIx+t9bVdyrKObhIpmGq1zEJirsS8V1YG6eQp9zuprsJx+mQkcM44qM1NEQlNw614MG8h+YSKtFB akNRLNvoSDJzBMdM4o7IDrfTPY4jhb30f/QT6UYRJ9xsw75duD6ZGaR2cwN8Edcvg1LMNYituWIN HproTmPyi2mmhH432TBmHrqxbTvlOkprYepHE7h7oq8SpBCkGic7DlIpiJZCbCBMdRmicwiVUUnH 2+LyHYVi7BukFiKOJlhwge3EdC7KmOhzDHYitp1iIcnLxLkLtRiic8keo9QXxN0QPvZRfsge22l/ jOPddF97qQ3vligSOQaRv6XciP4uym3englNP5XDdtoSpGvG5oj0J6kWxB6ycgTbhin9MOUiNlqU cgRlJbZOUEuboDYmamo3xffSsZOUH8JjUTzuDNMZQ5RHsmvRXoKSHK5GfaGkYnxE4tY7rwXR50S5 ifKc52GnFAVG4zqMUr6DC3xpks4dlWbFVhqTfEscN0J5HKa7FCXbE/fgmJ6JXsalfYo9I9S6CZVR 6r2ihwbRGmOjRmE+VkUkeZBR0bglTcTPibBkcXto6yDdb5j69BCVWZBGM9K3WIq7cD1yFiyMaFHq x8ML4sVWigcX7DlCpbNVipaxmBums0akCBKlktpGuSWaDaEHRajetscldW3cI5Z6pygl8Sxc6ImD NLIsjMwx34n5C1l1t6Q/ElN4av2idRQtkNe8xUwgZ1dK6kqfilIbJbErFJdKlGpFjDuijU9QjndR fS7kfF5a4ikjxsB5iwkviUCiDEYhn87ZQWUxCYvtfOkKu+hs0UOj0ukyiK3zOqldsNoE/c7HXdRP J6iewvG9XC0+hjFSL155D7XMIelsEulsl+QSplRECxiRvGph1CByDVPfEMfvpfofQyqLZdIqxdyd C2Y34WjxDBV94pNF810S56IdDVMPjPnBuHRWROicMUpB5D0o6SJmK6MLzh8xRk1Szx2JzyByGpdi aDQe58QTPEJ1MR+hYnIST6QI1fGYdP8QqRPu9yyKQEHqTTF/HZEsKRI/oSLUQ3jpPF5qVyVXOV9r r+KBjVQXIdonns2VsEGKITEJVSC1GmxfPLc4PvfqXh2WrEbURDBuieLuw5IH8TROBynvI3TPOyF2 3wn+yV4i/09+f1gaZ3uxFomfyuupxCcXnXeeq9y4BmlUGJXujWJsW0Ppjy3QQbsU+5ae0D00mo5R TBwrxsudNN78v7mDkZg2fw+7OtX5fonaF/my0tIafk1kcGIsOrZtkm8amxgfmwhORsZGS/iVw8N8 d2T70GSU7w5HwxO7w6GSpuDI1olIkB8KRvmt4fAoHwpHI9tHwyF+29gEPzZaHB2cIM0T4WAoMrqd D46G+MkxfnhsbCe/fWwsxO8Zwt7xicjoJM4JTvLRkSAuE43sC0dL+PZJSnh3eGIvH96NA6PjwcEY mfGJMeSNsIYj/ZHg9rHR4DDtwfGTkUGsDAUjE8OR0XCUNiPLkW2IToSRnWHc1O7w8F4+OjkxNrq9 CBmJDIf5obGJyL6x0UmcvGC4yBShQfgUtxAeGUfekE9KYWeYx3ZkLcqjuIbCE/zkUBD5nSSTxnZN YjU8Eg0P7ybb6hmKROmeByPjuCZWRsaik/zoGHIdDm4lTaNkAh9BPiKDUSIk5IK0DI/tCU8MBqNh fnAoOBEcnAxPSCzu2hraFSYM4qJ7kQSyuDVMJIrTIhOI4wooy/BweCQ8iioc28bvGZsIFUdG/i8x 5wIXZZU3/vPAzDPDzIDXRSwzMlexlMxalzVXs4uWkZFpF9Ma5CI8IncUFHEQIldNWzKlMrUyu/G2 vO1GvWTF1lRiRmVqZGpEKWWEaO6I5nr+3/PMgGDu+2/f/+f9/Of0nedyznN+5/zO+V0eMOLnqEHd pRaiYzkZUl5OYBET4jNNJZuro9YlMgMFs1MiMzNQx3BzXKZiskd0DqpzpXJSMvLSEtVQctLU3kHj 2UmJeQmBzs1hZSfl5KXlmopJCmwgRpA+NDfSyKPar/OOB/Jy1ILmRCZmJOSZMxljPpadNCcvLT47 ckGSknJ2PyblBx5ekJqbEhkfSZs5jCUpVylgXry6p7ZGQmpSegL3C+bNzkgLjGQSO3euWX19QXZq Gitxnm2eR+foKC0jR61BJlaRmoO2VO+sv6mVdNN+2FG5SfHzVEVSPu1yc9Sey4iMT52XZG4oNSYM KTUnlz2odm960gL/BorPNtd1HkpKVQaVmsmqFmR26Cq6017HdC7gdRlpiWOUNY++kx2iBvS76D+M DtSOULVdljop1dyx8UqJiGevMaDs+MSkefHZcyMzVE2Xy+Tz+4eOPTs9PVWZ8h258bl+u7tCOQJT QEJGXnpudiq77dYMNruawc3svg6DnpaanRE5jbvsy7k5Kbm5mWOuuGLBggXR8zrkRSdkzLuC5zLm ZMdnphRckZCbjK12bWpeq2b3ZOSxvAVqGzMsJqlqlAGg+nmpuWqIswvMAd84PXaCubXUBU6Fzan2 nHIICSldnuWIxablJfqXKzE1JzMNAX5XxEIzPbVRc6MjO2RnpLPbo1KH4Stmq4fOdpXe0fi8IzKb m+4Sy0BhCX7765RuajrQ1zXmAKJSkZKLS2Ix2KoFWMeC9LSM+K5CGXN8wNNmR3auCb4pE/eUmDQf 36PapCSlZZ4zoV+zFKbir0hMSo5nl0bH52Tmd/xskY9cJ9aL833UX50PEQ7hFDYpRY/AX6DXqYhS P9MTovNnkuf/WIJHu1wabbSVv7Z9aKjZvu3Xtu/RQ7UPmvZr2/fsabZ//de279VLtQ8e8Gvb9+lD e4v5t/ftwmK2Vz9h7mN+20SocIkLRE/eIfqIsaKEHKSULKOMjOxB4v+fxCKxQv1MXKwTq8Wz4mFR LdaIv4tHxQ7ufK59J5ro+Qg9nThHxs9dZIQhYwAyLuPOBGTchowZyEhBxnx6L0bGamQ8yfdLyNiK jA+QsRMZ+5Gh/t67j57OdJehnewioz8y1N/jmsCdGchIRUYeMkqR8QgyNiLjZWS8iYw9yPgeGafF o5pdrNP6at9pQ4NHa/Stje8uIzjmV8h4ABmPIuMpZFQh421k7EXGj2INXTyquZARgYzLkTEGGdd3 l2FZ1EXGhcgYjYyJ3IlHRhYyipDxBDJeR8Z7yNiDjENitRYsHtYikDECGWOQMQkZM5GRhoy87jKs bV1kXIyMcciI404GMlYh41lkeJHxDTKOihVaT/GQNggZE5ARj4x8ZJQhYw0yXkLGm8j4QNmf3c5/ ERHDh08smnjEbuOiPS2ZT1q73SLslja3+Wmzhwi74xuPSiTvNcv1otmjmttO07iQFroudD2zIiK/ oTBEFyG2Rrc7P41PfoiuhdhiIqjgU6hbVbOG9tptmSHqicKGhkxPe2Fpe4hFhFjcbtFoygux+btI T6STVt0hdOfPYp7HX36s1W1Ct7Wr7ltNuS256iHdotH3J42ZVY1mgxbVYJw9SLNbatVH1NYGB2sh 1k2bNoXYRYg57eFFEyceUVchp5MT1Cf5tBqJNTBxRuIUIc7GxqzarNoZlFjKtbVfN6oB2gNzV5PX dFtg8qqCkafNV5UhNi3EPsDlKtyxY8e+dN2qmgUmz2lg8ivPnbzd34WafPIJ3SV0V0vtAneyWU5k 6nah21tU9yf+xeRVg1bq038fEqSF+CcfmL1Dzd7hEA6Hi20UbpZLxXgxwTPB802tQ/21kzPqzdRz tiRguQ6LcHTqxN3mcGqO0O5K8avFYdMcIUotfr3YbJrNnr9STb/IYReOEDWrHKXm+xx2WobpetH7 fOoX2HTVcseO07XefFra7OOTk8e6i8Zf/26RKbtDOcgOUf0IN2WO+dOtQt5sEsQJj80lbKFnFaVU ZQsRtpBW863ZX2ilC5vNVBnDs2o2W/62xsyYijazaXNnwzniGo8jCHXVdmrPYtWcekPDww//T9Sn OfQu6nNpjrDGzMzGzMZ73Pe4p1BucF/rbmxTSnGcUfop6lBfSEB9TrtwKvV16M9p15wO9NepQKXq wvffP1P7TuF/r0BniOrJVOAvVBgmbGGtmTkVCRH+cmKr0ovjv1GhOi/0NuYPWNluNv2/qtCmVOh0 CqdTqTAMBfZBhSgRFU6o/abR6dCcLpSI6ty1HQU1es4Ip4UV6FQjM3Fpzi56nNFFk6Z6OjWJA7Np 9pD8Ha6xaejSFSJcjg4NqB8ynl2r+4RZaSNTUWU883g3UNR8zG7GJqPl2tljXfjOkPFqsytFv/tu kdMinGcV7W7rJuespv26tocJe4+uulbaNv1sV22bLZVbbp0f8MS6ZrcXemvbxrpWtpvNm7s0VmN0 BgU59dpuSneZSg91iVCXjQjSQzg9Ts+Fnl61vWrH10Y2uilH20KdWmioFDmerFql0bMlqzbHI0Wo VQu1tWee/bSHhmmhPdvG5sfk80l7XZU5MarMjnHHtBWGOrRQl78/f8nxLCEp8Zd2PK4W4hgnmskV VEybw9kRscAT6hChzrZAqwViUefT6vkMoTp12jzBZhnvyfF801kWeK6pDbHT6djk5maJdxpHXyGO 8TznL+NZhSWe8Tiq2tqvGUuoVYTqmZlCtHXOyNlFeE5tlieHDKeIYahJ/NwY0kuE9DqxQRQ0i6wP zv3v5yMeM1ac8BTUZnUpPKbCy4klOX4ZKiSEFB1qaiscuKr+tPnIT90eyKn9Y2NosBaqN3Z8BFh1 Lcy+Q338WaNDrA06IIITCrLTRN852Ulzxei0+Nx0Mg+H0O6Yel0khiXIsoMDOZz/XCOj6OH/E6Tm dRD5eE9aBt8cF3eTGDT1tlsjRfS0qbdEqr9sYrYIpr9egXO2t+gdOLdivH0C5zp5aF/xm7m8/AqP +V1mfq80v8vN7wrze4P5vVm9WooXze996lsLM7/Hmd+Z5vfT5vfOeXPnzQ0KMr9d5ne4+R1pfl9m fl9tfo/rzKZ/zXc/jkHmjNS/UMG+Au8lWAi66oFOejHTPmpWaKff/+iJ8P91Cf/7Y/p32weLCPLs C/6fzi4UMWKmSMNVruQ9spL3iR1in2gRpzWXNkAbro3VYrWZWppWqK3U1muV2lZth7ZPaxHq320E q38/wtuK0ovQXvcfn080j1rw3SLE3AHq75GQVw+/r/v11U3dr2O83a/Herpf3/RKl2ur0KaFd6+f trn79azJ3duntnavn1vavT63Z/f6XG/3ek929/ri3t3rl4V1r1/2evf68oru9WuHdK9/UnSvf3JZ 9/pnzxn/lsLu9a8wnqCOa53rx0WI1uX6te9ESHCX67cqhLZpm/JO+kDXRJfHVeaqcG1w/c112NUe ep+rIjQfykK3hm4PPR02JWx92Ds9+tLul2UDpayzVJi9nFsOBwo99xgUep/q/zxlA/LKTJkdZbsq SPeXd/ylR19VXBW9doRXh9eGbw/fFb43vKXfHq52RbgienNdbdbURlwdsTbCG1HP/caIU/0jIhr7 DzHrzi17Kds7Sv/hZo/nlP4T++1RxWy/69yCXCQr2ebTZ3uuPU/Zy6jWmiMLlAtLIzdcMkCN8zw9 nwqURn/pP0SVoZcNrQyvHXooyh4VFhURNSgqKmpUVEzUZM5ToCjKG1Uf1RB1OOr0MH1Y3NBDvyw8 M4hnO0qE2cu5ZVSgqJ4nm73/sgxCWpEpsaPUqzLsPqSbhRH4S5wqURGXDTe10NKhybO6C981YuqI mZSplNlXnY6JjomJGTdmjULdG3to3NYJE6/b1HG8ccikTm6uuXlfB5OjJ2+e3BTrmrw57s44d9zO uLbJm6c9HrdzeuL0sulrZhy4d9nMovsHq9r4sLidMw7MOBA/LX52fFp8UfymhKkJdydmJ+5KPEbu GJbcN3nQnJEpU1NSUhambk19J35awtTUXam7kgX3KKnvpO5NbTcOpO5NS0lLT/Om7UndOy8tzZse lt43/YKMkRmjM0eadV7OR2Yuz3w+a1DWmqw9WY1Zrdl/y5mak5lTlCfywvLceU/PT5u/fP5y7mRm rZn/fMHAgraF1y2qympcPDln6uI1ee6iMUU3FGUXLSvaULSV8g5lW9HeouNLJi+ZuWSmeb1sSfKS 457Jnkzq93rKPBWelz37PIc9bR4fnC4OKu5ZHF4cWTykOLN4YfFCz2nKvmJP8YGlfZdOWZrmaVu6 sDhy6Q7KzqX7lh5e2l4SVBJVMqYkrmR2SVrJ/JLSkvKSTSVbSrwl9SWNJa0l7aV6ad/SC0ojz+sZ OrxD19LN4ktnn7/47fy8ltphrV2LspNuFlaae7ao2q7Xfis6n0V0WkXX0m2vl5adv/j3d+nDodsj 2Pnhu/CmFaVrO7ya62+lVaGnXe3Kp5bWTC8L3V7qLT2lfFj/IWrvo6WKgK5MH6meUnWcd2iwwvTF ZfTrMb1wpx7D3uGqDI+6/QE7tdQ8EBZaZt71mKWsq3/tLKaXV0X54q7+ODSfUnZ+P6wigRkLVDRY 3+GHzed5xtWufLLS/gM7zPVoKRuIVTM//HB9WW5ZUf8hZQ+XveOfs2n5tV38XK1/ZZWHxRPQS1lj hKv/kIC/re66zsp3qvMyX3i16c8Dqx7RqL4ftDx4wYObaNO47Gzd9i6SOnZNS2lkZ++dPl35Ib8n Mkv3fddlhwU8eBcfHlHvL108t9ppp1Tc8UceVcKraYMvD6+O3BBevWwZ173RiDlyfHnEsqcDey0s KupPVXjwGNOj1y/vvTzS7z/ZoxGBner3zLQ2/eqozv0bYUaAIvqz+9v7yzCd8zC8eH2UXbVc/kpU kXnPbpawbj7dX/xRJabT/5+NACmUovN7fjPyNJi+/7Q//pjjq1eRAGmqF/VsjIoFat7LvSuSH4oK r31oHN9K57UPVa4KXxVX1hi+a3oZXrvM76NnHFg1X73Pr6rCz3r9HjVjJJ7+VxY8+zmF6NCtnKfF zu5leqJ/JGfLL58hlvybxR9TUnd1HDuuOq6TxTmlb3Jff/z514XI9O+Uvb++EM26F2/3QuwL86/N +cr51mX+8qw1xMJAUVcqJvrjoRkTp3aczV9ODF1O9GxUcdKMn2YhflLUk/OXr6rhSZ7NalQR0YyV ZiFGLiva5o+WnG/1HwOR0x9PVdlrlmWqNW0nr7YTKYOIov4YahYi5z4zkppR1IykbZ1nZZ4yZSFm +9P+QsRVRT21cHUYT/FcIGbtUr4wwrU6avVO5RdXt/vvhu96eKnfv/zZVZ5cXvHIoEfWPLLnkT1r xJqX19SueX9Nw0NRj55ZU4vv8K61rHs6wtt/yLpt62jRNc8Mr624qWKG33cFvFV9/yGP3fTYVNOb 7QpveSz/bL4c4X3sZXzVkMe+fXz7E3HrJz8pnty+YdPGURtbNr1C7rHXr2l0Y+qpONI/N95NK+Qz YreMET/KFs0ifdoseVQz5BbtkGzQmmVVcBzcLqscm8RYx1PwihjrvF+M4j2kQrbwBlIhm7RY0Tfw XDP3d8sjvNNU8LyFe2frjvIurFprsp6aKq0HLa7kPFZEabdzPku+pSVwbTASDxyiTbNs4E2Vp+i1 iZoG3nsrZEFgtI08O1a7S+7T7oEZcC/MhFlgSC99VNJHrIV7Fu5Z7oP7wQ3xkAhJkCz3dZ0h71gV 8gWlF3opooct6KEBPTAa5NbT/w9qfOaM6mlXw6zUiJqoaeaZpsDo1XP1PFffrfdgUztKM83MzGX2 0WRqxksf5WhmdxfNKGnrTc0cktGqT97bK/j+kTuaqeWNPPEZT2w19XE7x1nyNZ7YqjSGLn08mcuT NfotItH2oLzT8Qxshg9gG6vfhx69Aa2+TW/NAfljA/JfC6yML7AyJfRW/y97C1Hjo6cGcwazOBrM 4BA0S4OnRpk7SM2iCJkNAd1tQe4W5D4RkLs+MO8qnq7i6Z48va6bzIA85xhZ47xfGgG9GqxGs/SJ F4UuG4UDekNfCJfHRD90HSEPiP6s5QUwQH4mLqPuchgOIyAaxsA1MBb+CNPhTrgL7oZ7YAbcCzNh FtwH90MCchIhCZJhDqQgNxUMmIv8NJgH6ZABmZAF2ZADuZDH+ObDAsiHAsa6EBZBIag1e4wd9ATH do4n4RT8DKe59084A5J9xXpprWjnCByDn2RDUDBYwQb92N+/g9FwDcTJJvZtk8UlD1hCIQx6QE/o Bb2hD/SVn1l+A+FwnfRarocbIFfWW8fLRusNMAlukg3WKRxvg2nUTYe75AHr3fIzaxL3kjmfAymQ Cgakcz8DsiAb5kMxLIUHqC+DVZyvhofhz1BOf2s4rqX/x6h/kvON3NvMsQrehw9gG9TBJ/KY9VPY CZ/BLtjNs3vgc2iAL+hnL3wJ+2A/HGA+X0EjfA3fys90q/TqY2AylMMjsEY26Y8Ca6Vv4LiR4wvS 62iG72ST8w7WZoywyJXCij+1gR1CwAkuCIMe0BN6QR/4DYRDP1nDbvaxm2vYzbvFhbKUHV0hLpJb xUD6vBgi4RIYBJfCYPgtDIGhEIXlDIMr6G8kVnklx1FwFVwNv4PR8HuIgT/AOBgP18IEuA6uhxvg RpgIk+AmuBlugVi4FaZAHNwOU+EOmAZuiIfZkACJkATJMAdSmGMqYN9YkA8L8mFBPizIhwX5sCAf FuTDgnxYkA8L8mFBu7Gg3VjQbixoNxZUgQVVYEEVWFCFWIyeimAJ4NlEMfNfijfS5ataJFwCg+BS GAy/hSEwFKJgGFwmY7XL4Wvp1r6Fg+CDE9LdaVHfy5XBh+EHaIEfoRWOQBschWPwExyHf8iWYB+c gHY4CafgZzgN/4QzsgXr9GGdPqzTh3X6sE4f1unDOn1Ypw/rrMA6K7DOCsuN8lXLRJgEN8HNMBlu gVi4FabAbRAHubLGUoCMhbBItljHwh/hWtEXa66xsq7WycDaWllbK+uJZddg2TVYtg/LrrDeI7da Z3H/PrgfWGMra2xlja0JcqWVNcbyfVi+D8v3Yfk+LN9nnUtdGsyThjWTNrmQBwsgHxiTdRH1hbCY 8yJYAqyhtQRK4QH6KYNlnP8JVjCWlbR/iPNyxvYI52sZK3kMnsJnfZzrJzjfSN0mzp/i/Gl4Bp6F LfAcPA8vwIvwElTCf8DL8Bf4T3gF/gp/g1ehGl6D1+G/oAbegK3wJrwFb0Mt/B3egXfBC+/BdvgQ dsBHUA8fwyfwKeyEz2AXkI3gvWrwXjV4rxq8lw/v5cN7+fBePryXD+9Vg/eqwXvtxnvttjbJUus3 8C1zP4ieDkEz/EB/LUBmYG2VW3Vk6cjRd8Me+ap+AL6CRhmrf8c92uutXB8BKV+1YUe2UOgHCfJV EUTMept8ab15touzXM5UbmchRqqccruZU+4XHwuHWfsjxzFit0jXvhMvaj+IF4M0kR48EkbBVeLF 4Di4HTKgABZzvwiWQAk8C1vgOeqe5/gCvA8fwDao4/52jh/CDvgI6uFjkW5dJ5Zaz4g4fZSYSOZx So8VK/U4Mcq2SFxJFlLvWCFGOVaKiY6HgIjjWAfPwGZ4Qex0vCjWOl6izV/hNa5f5/rvtH0HPqDN Nvm545CIc/wgEh0tZAah6OGwtV0kWk+S5yyGYpFvWyryHU/SYgNsooen4BWx1jlV5Hfm4vuF3czI d5u51E6Vf9I2jrZxtI0z20XQopWM4RgZQysZwzEyhmNkDMfIGI6RLbQSwVuJYq1EsFYiWCsRrJUI dowIdowI1koEO0b0aqXnRHpOpOdEIlkrkewYkaxVOJG9mxUZyIoMtBXLettSZvkkbFA5MDwl651T 4f7AHjiqVl9YVO7Mc1E8F+V4mrHqgVk0oU8v+vSiLy/6WiZsZgZODSvg/UVtcEADH5v5ucZ3i5nN LyPDbiDbVJn6X7kbqzJJsdr8P+LV/w+/HA2sFL3M/yt+FTzJ/Q2wETbBU/A0PAOb4VnYAs/B8/Ci PClegip4Bf4Kf4NXoRrepM+3YDvsgI+gHsg/xB7qG+AL2Atfwj55Uu0FzSqPa1+Lgdq3cBBaeWs4 AsfgJ/Bx74QYaOknj1gioD9cABfCALgIBsLFEAmXwCAYLE9afgtDYChEwTC4DKLhChgJV8IouApG w+8hRp60HpPHrT/BcfBxzS6ynmZ3aPK47uQYKo/oPeRJPZwjY9MZm34h9y8WvfRLOR8MyNeRryNX R64+kvqruY8cHTk6cvQ/wDXcn8r9O+h7GkyHO7k/E2bBfXA/kHPr5Nw6ObdOzq2nQBrMg3TIgEzI gmxYyDOLoBAWw3rusdY666tv4fw5ecyWLo87QtjdV8njzklwC+excKc8ok1k5xwUD7CHy+BBWIYd EmvYTc1iBazk/CGOq2A1dQ/Dn2lXzp5/hOMartcCfsN8r31MrhCPy4+xzwKxXn4pXqBNJfwHvAx/ gf+E1+B1IIYIYgi7q5nd1Sxq4X34gD63cdwOH3K+g+NHUA+fwKfc2wV76ONzaIAvYC98CftgPxyA r6ARvqb9N/A9HIYfoAVaGfsRaIOjcAx+guPwD/DBCWhnbifhFPwMp/EA/2SeZzhK3vSE/FILgmC5 n11/UNvIcRM8BU/DM7AZnoUt8Bw8Dy/Ai/ASMBbecOp5w6nnDaeet5p6crB6crB63mrqLZfKo5bh stkygmM0XAEj4UoYBVfB1fA7GA2/hxj4A4zhedXHWPgjjIPxcC1cJwt481nPm896S57cb1mCDI/c j5UcxEoOYiUHrf+QR7GUo9YTcEo2W3lLw2KarVLu14U8iuUc1Jk7/rdA1+WXuoN7Ttmsu7jXg/Oe vHH3gt7QB/pCf+LthbQZQP1FcDHXkRwH8cwwjpfBCNpFw0jaMU/9KvpmfljZUazsKFZ2FCs7ypvL eiytWR/Ls3+E8dy7FibA9TxzI8eb4GbqJjPGOxjvNJgOd3H/brgHZsC94IZ42ibSZxIkwxxIgVQw qEvjOA/SIQMyIQuyIYf6XECf+nxYAPlQAAvpexEUwmIo4s1qCaBzvRhK4E+wHFbASngIHayC1fAw /BnKmccjsEauIMat0NfKj/V1gC3qjzHnx+EJWM94nqSPDbTZiJ7Ykzp7Umcv4ima8RTN+vO0e4Hn KuV+vMZBW6Y8asuCbMiD+VAEjAuP0uxg/A7G7uCeYymUAr7EofIKxunAXzjwF45y7uErHGuggni4 RX7peA6quH4VquG/oAbegK088ya8BW9DLXzIfWzd8Q39NssC4vUKx/fyS+coIvFV8qCTPe9k3Z0T YBLXrLOTdXZO5niLbMbjNTtv5XoK3MZbaxzHO2SBc5r82Dmdflh/J+vvZP2dbmz9YjOT+/+UtWkl RPXB+GUdv6zjl3X8chV+eTA+uQafXIMvNvDFBr5Yxxcb+GIdX2yIR2U0/rgcf2wwAwN/bOCPDfyx gT92kxUYZAWDyQoMsgKDrMAgKzDICgyyAoOswCArGExWMJisYDD+WyczMMgMDPy4jh/X8eM6flwn UzDw5TrZgkG2YJAtGGQLBtmCgX/X8e+6+C9k1sAb9LUV3hYD8fE14u8c34F3wQvvwfvc/4Bnt3Gs 4/pDzj+FnfAZ7II99PU5/TZw/AL2wpewD/Zz/wB8BY3wNe2b6Osbjt+il4PkUIegmfPv4Ht0ehh+ QF8t8CO0krEfoX0bx6NwDH6C4/AP8FF3AtrhJJyCn8EfC4wuscBNnraFeOAmHhhkQrHEgyriQRXx oIp4UEU8qCIeVBEPqogHVcSDKuJBFfGginhQRTyo4p08RmvieebAu3kM7+Yx5k8SfRxPQDvnJ5Fx muM/pTsoSMYEWUCXMWRUg8moDDIqg4zKIKMyyKgMMiqDjMogozLIqAwyKoOMyiC26GRVBlmVQVZl kFUZZFUGWZVBVmVYLidLG8479QjaRUs3scdN7HETe9zEHjexx03s0Yk9OrHHTexxE3vcxB6d2GMQ e3KJPQaxxyD25BJ7cok9ucQeo0vsKSf21BB7qog3OvHGTbzRiTUGccYgzujEmHJijEGMcRNjdOKL QbZm6GFiIHHGTZwxiDO5xJlc4kwucSaXLM4gizPI4gxizmD9AtoN4NmL4GJZQ8zR9Uu4hx7I7gyy O4PsziC7M/Sh9BsFw6i/DNCDPhxG0G80XMmzzJ3MbzBxSScuuYlLbuKSm7jkNuMS8yYmlROTdGKS TkzS9etkNHHJTVzSiUs6cckgLqmfLyeSLQ4mQzSISzpxSScu6cQlnbikkzUaZI0GWaNB1mgQp3Ti VJWeQF+pzMXg3lzGl8MxF/JgPiyAfCiAhbRdBIWwGIq4twQ8UAxLeb6EYyljfADK5DL9QVjG+Z+Y x3JYASvhIdqtAnwScSmXuJRLXDKISwZxySAuGcQlg7hkEJcM4pKbuOQmLrmJSeXEJMOMSZuYM7ZB XKoigx1MbConJrmJSQYxySAe6cQjnXikE4904pFOPNKJRwaxSCcW6cQinVikE4t0YpFOLDKIRQax yCAWGcQinVikE4t0YpHhWC+jiUdu4pGbeKQTj3TikU480olHOvFIJx6VE4/KiUflxKNy4lEV8Ugn HunEI4N4ZBCPDOKRm3hkEIt05zUymnhUTjwqJxbpxKIqYpFODDKIQQYxyCAGGcQggxhkEIPcZOSD iUM6cUgnDunOWWIgscgQkXjyOjx5HZ68EU9eh/epw/vU4X3q8D51eJ86vE8d3qcO71OHRdVhUXVY VB2WUscOrGNn1bEqdaxKHatSx6rUsSqNrEojq1LHKtSxCnVou44Z1TGjOkZXx+gaRRiSW3kv9eKP GvBDDfihBnLVVnJVH7lqK7mqD5/UgE9qoNdWem3lyVZh13rw/hcL/t+i5AZ+m1MfHCe3BN8ut/CG a/D2GmT+jo13Ys4M2UyrZmpm8WbQUdNgtqzlTXuW/EK9G3e8bfM+3YM7sTDL/B3bVNVPx+/9hJVa n3alPEYLn3Y7qN9u9NLu4s49MAPuhZkwC8jq1PMWri1cW+6D+8EN8cA7moV3NIv6vYga6yH1GyVz lF/xnNccn3q793b8FMG8s88/58Ad1foV9fsk0ZtxVDOOasZRzTiqGUc1tdXUbumYIWOpZizVjKWa sVQzlmrGUs1YqhlLNWOpFsE89U3gN3dN4ipNl29oFzOfSI6XwCC4FAbDb2EIDIUoGAaXEa0uhyU8 40HjxRy/prdv4SD44AR6uVG+YZkIk+AmuBkmwy0QC7fCFLgN4uQb+g7eQ/dwPABfQaPcordyPAJn qJPyDRtjtYVCP0DvNvRuQ++2BK4N9FzHbCo1m2zRQsABTgiFMOgJvaA39IHfQD/oLz/SLmC9L5Tv aQPkLu0i+aw2UNaglSa0UolWKtFKJVqpRCuVaKUSrVSilUq0UolWKtHKArSyQLua/sbANTABrofJ cAvcClPgNoiDqXAH3AmzIREM9sRcxpMG6YwpD+bDAsaVDwWwEBbRrpAxLuZYBLwTsBpNrEaTpn6u XwpfY4ffwkHwwQnpZVUqWZVKVqWSValkVSpZlUpWpZJVqWRVKlmVSlalklWptNwuWywzIEX6LAbM hQzIJPZm8T6YDfPlR5ZC2iyGIt7L/gJvyPf0tzi+LX36B/IjfRts5/xD4s4O3l8+oW4n7DJ/vlqp f0HdXvgS9sF+OMD9r6BRLtCbaXcYfjR/7lrJrqjUj3LeTruTcJrzM/QrZaVNyBabVdawWyptIfIj dkyljfW39eZeP84jOOd90nYBDICLYCDwTmmLhEthMAyBKBgGl8NwGAEj4UoYBVcBa277HYyG30MM /AHYBzb2gW0ssBds1wH7wXYD3AgTIZbx3QpT4DaIkz4bvsc2Fe6AaTBdvme7E+6Su2x3wz3yWdsM uJf5zJRNWEETVtBku5/+3PQRT5vZ1CUw1zncS4FUwOZt85QPCnpEpAQ9Iz8WWtAUMUzbIizyExGO T+pHttsfX3uB3CEulKvFABkrLuItZyD1F0MkXAKD4FIYDL+FITAUosiih0ECfSVCEiTDHEih71Qw II/+58MCyIcC5CyERVAI7GrBrhZL4HF2rg794UJiwwB2+EVkzgO5ZsWwUC8W6sVCvVioFwv1YqFe LNSLhXqxUC8W6sVCa7DQGvNfS8yFNFhAX/lQAAthEfcKYTEUwZLAv9Aoli1BA+SnQRfDJfLjoCEc o+WIoCvlajQ4NWiquCooUb4XNAfQdFA6x/lQINcHFXJcTfunaL+Z9n/l+k3OGzi2y/eCHRAq1wcP 4fi9/CT4MPwALfAjtMIRaIOjcAx+guPyE0tfGWv5DYTDjVj3RJgEN8HNMBlugVi4FabAbRAHmZAF 2ebvsKOxYq/1JrnFOk1GW6fD3TLWeo+stybIT6xzIQ3myRrrIo6FsIK6lRzLafcIx7U88zjHjVxv 4vgJ/X0KO+Ez2AW7abMHPocGOIC8r6BR7rB+DU1ytfUb+JY+DtI/sdDaDK2ynmzBS7bgxbM04FG8 eBQv3sSLN1EexIu38OItvHiLGjyEFw/hxSO04BG8eAMv3sCLN/DiDbx4Ai+ewIv1ebE+L9bnxfq8 WFoDltaApTVhaU1Y2nosbT2W5sXSWrC0FixNWZkXK2vCyrxYmRfLarE1y2bbd7LK9r3cYjuM9f0g 62wtMsn2o7zd1srxCPVt8lXbUfmp7Rj8BMe59w/a+5Bxgmfa5We2k7Q9JSfZfuZ4mjb/pM0Z+pVy i13IGrsm6+xBMskeLG+3Wzha5Tq7Tp0N7PL/MHf/8XHVdb7HJxMhM2kR1EEUKYoFJWCQNhdRadUC 0gBVacWKCSICIRCEIIQfobT8iKP4I84yKFlz417j5s69m7oxdjf3zkbFuyYsuppGLpozWRzKJLRD aZhCwQIu9tznTAesruvexz7u7t4/Xp6Zc86k53w+7+/78z6TUrti8bA1Vh+uji2yf3F4cewQ21c6 dig88cQ88cRe7ZzXOCcRHhk73PHXOu91YW/s9eFA7Ei8wfGjnLckXBM7OlwZe6PzjnHem/2MpfDU EzvO8bc4761+zvGONzguG8Rkg9jbHPfUEzvJ8bc7frLjyxz39Bc7xT28wzmn4p3hYOxdznm3c06z f4VrWOlz7/H+vfa/z3bVvvnY6T57RtgUO8s5q32OTmNnO/cc+8913hrnfcDxDzr+obAnttZ2nfv4 MM533kect955H3UvFzivxfFWP+NCfNzxixz/hOMX+zmfdPzh8P7YL5HHI9iGR1HAHObxGLZjB4p4 HDvxBHZhAU+ihN14Ck9jD57Bs/gV9uI58ILYC+H98UvDB+NtYSZ+OdrDXJx7x68MO+Md4dr4VWE6 /inHrw6L8WvC0Xinc64Nt8Y/Hc7Fr3PO9eHF8a7wrviNYV/8pnAgfjM8xcVvAW+N3xqujG8MF8Vv Cwfjt/vsHbjTMU9w8c+ErfFkuDr+WcfvCsfjn/fZL+CLftaXws3xXse/7PMp3O142mfvwVcc/6qf d6/jfT6fDRvj9+Fvw1T8Z671QezwuojdYWP9QeH99SfgRJyFs8OB+gtsP4ZrvO7ETeH9ngomaxab TMOmUqb6t5jmTKUOUyltKs2ZSsOm0rCpNGwqDZtKw6bSsKk0bCoNm0rDptKwqdRlKnVV/s7HFX7W lejADX7GjTAFTKE5UyhtCqVNobQplDaF5kyhOVNorvz3JUyAYRNg2AQomADDJkDGBOjg7sPcPcPd Ozh7hosPc/FhLj7MxYe5+DAXH+biw1x8mIsPc/FhLj7MxYe5eJqLp7l4mhNnqn/vIMeJM5w4w4nT nHiOEw9z4mFOPMyJuzjxMCce5sRznHiYE6c58TAnznDiYU6c5sTDXDfDdTNcN8N1Mwf8jZ45rjvH dTu4bgfXTXPdOa47x3XnuO5c1dXyXC1fdbVxrpbmaj1crbXqaoNcbZirDXO14aqr5bhajqtt5mrj XK2Hq3VxtVauNlx1tTxXy1ddbZyrpblaD1dr5WqTXC3P1fJcrZerpblaD1fbytW6uNokV8tztTxX 6+NqvVwtzdV6uFoDV9vK1bq42jhXy3G1HFfr5Wo9XK2Hq3VxtQauNsnV8lwtz9X6uFovV0tztR6u 1sDVJrlanqvluVofV+vlammu1sPVGrjaVq7WxdVyXC3P1fJcbTNXS3O1Hq6W42p9XK2Xq/VwtTRX 64mt4oin++wZHNHU5mp5rpbnan1VV0tztZ6qq23lal1cbZKr5bhajqv1cbVertbD1bq4WgNXm+Rq ea6W52p9VVdLc7WesqtxluH4ZWGeu+S4S467THKXh7hLD3fp4i7d3GWYu+S5S5675LnLJHd5iLuk uUsPd+nkLuPcJcddctyll7v0cJce7tLFXY7kLpPcJc9d8tylj7v0cJc0d+nhLg3cZZK75LhLruou fdylh7t0cZcm7rKVu+S5S/4Ad0lzlx7ukuEuGe7SwV2Gucswd+ngLh3cJSPbro80RBcip8i25f/9 avQk+eye8JRoEI5Gi3gxvKh2cTh68LmRe+uKkVPrHo+sqtuJXZEVdQu2T9pXos7dXj8VOb7uWe9/ 5fVePO/1C7a/tv1H6v2N7T7vw8iqWE1kRSxqWxs5lYKLsYMijbGDva9DzL64bb3tIiyOHB87xPFX 2ncoXmXfq21fY5vw2cNtX+uc1znn9fYfiaPsW2J7tO0bdfgYx97s/VIcZ99bbN9qe7zPNzh2gvcn otG+k2zfbnuyY8tsl/vZpzjnHfafinfa9y7bd9uehhWOr7R9D95r//tsV/ns6bZnOHaWz662vxnn 2Heu7RrbDzjng7Yfcs5a56yz/8P4iH3rbT9qe4Frb3Gs1fsLcZF9n7C92PaT5tplkePjbZFV8ctx RaQxfqVtR+RU6szHr3bsGu878Wn7rrO93rbL52507k3e34xb7Ntge6vtRp+7zbHbvb8DPfZ9xjZp +1mfu8uxz3v/BXzJvl7bL9umfO5ux9Le34Ov2nevbV/k1MhXKoqakO6DcCNVbaSqU/6Aok49QFE5 ilpBUUv/gKJWUFQjReV+T1GnHqCo3L+gqKV/RFG5qqKW/p6iGilqBUU1UlTujygq90cUlasqaum/ oKilf0BRuaqilv4RReWqilr6e4pqpKgVFNVIUbk/oqgcRS09QFHHU9QKimqkqBxFLT1AUY0HKCr3 e4pqpKgVFNVIUbk/oqjc7ymqkaJWUFQjReX+WUXdED0mslKiGD3g2SFjyqYrU/YpU/Q5zxkvhH2m 6F2U0n3As0DG1ExXp2Z5WqZNy4xpmTYti6Zlt2lZnpKjpmTalMyYkmmqaDIli6Zktyn5kOmYMR3v Mh37TMe7qtOxPBVHTcW0qZgxFdPU0GQqlqfhqGmYNg0zpmGaEppMw6Jp2G0alqdg2hTMmIJpU7Bo CnabgmlTMG0KZkzBNAU0mYJFU7DbFCxPv1HTL236ZUy/dHX6FU2/btPvIVMvU516fabeXdWpV552 o6Zd2rTLmHbpyrRrt7avND065OGr5Nir5ejfZuWMaZbW5R7T7CFTLGOK3WWK9Zlid+lwgylWnl6j plfa9MqYXmndbTK9HjK1MtWp1Wdq3VWdWuVpNWpa9ZlWGdMqHflmJSueFK6RE8ejN4YFeerH8lSP PNWt0306ndHpNTp9kk6vlKce0u1eGeohGapHhurU+T4ZKqP7a3T/JN1fKT/9WH7qkZ/KSuijhAwl rKGEkyhhJSV0yE9t8lMbRayliEUUsYgiOihiJUV0yE9t8lMbZTRRxlrKWEQZi2KJfU9SRgdlrKSM Vvlpvfy0nkKaKGQ1hSyKHb3vxdgbnXeM897sZyzFsY4f5+e8xfG34njHGxw/wbET8TbHGx0/ybG3 42TH5WeKWUkxPfJTm/zURjmtlHNk7N3+jNN0e4U/c6XPvcf79/rc+2xX7buHctbGzvAzznL/q8NO +amNgtooqIOCmijocApaREGDFLSWgvrkp075qY2S2iipg5IaKOlwSlpESX3yU6f81EZRbRTVQVFN FHU4RS2SnR6SndKyUzd1bZadximslcJWUlgbhf1YbkrLTT2UtpnSximtldJWUtp6SuuQm9bLTesp 7nSKW01xi+K37nsxvnHfIxTXJTe1yU1tlHc65a2mvCMpb1H8s47fRVmfl7++4PgXnfsl9FLql8PD KfBwChyUmzrlpjZK7KLELkpsosTDI+spcJrichS3QG1FauupfB/xnBzzvKT/gv2/9nq/t+QoaoGa itTUQ0FF6il7yRi15KilSClFHtJDJWOUkaeMPGUs8I487+imhhw1FCmhyDN6dD+n+0WdL/KKHl0f 0+kifyh7w5gOF3lDkS8U+UIPTxjTzZxuFnWyqJM9ujimc3mdy+vcgs7lda5bt3K6VdSpok716E5e d3K6s6A7+Uqy3b/+c7qS15FiZe13e30LNjh2q+1G593pnB7Hk/isc75o/5fQ65wv26ac8xXnfNXx vrAYGayu8WkVvs36zlnfP7C+x1Q7o9qbre8uFW9T8dOt73x1fees7zHru+zsGR3YrANdOtCqA6db 3znr+wfW95huZHRjs/XdpSNtOnK69Z2xvses7zHd6ba+O3So1frO6FKb9Z2xvses73LHOnWs2/ru 0LVWXTvM+s7oXJv13Wd9b7a+N+tipy526mKrLq7RxcOs74z1PWZ9j+lop452W98dutqqq4dZ3xnr e8z6HtPhTh3utr47dLlVlw+zvjM63Vb91mfM+i53vdf67tD51uq3Pp263637rdZ3BwW0Wt97rO/M Ad/6jFnfZUWkKaLX+u6iilaqaLC+f0AZndVvfTZb35upJE0lPVTSQSWt1UlR/tZnzPoeo5g0xfRa 311U00o1Ddb3Vut7zPoeo6AxChqrPhu1UVArBW21vn9gfY9R0hgljVnfPdTUSU2t1nfG+t5sfW+m rE7K6qSsVspaQ1mHWd8Z63vM+h6jsm4q67S+OyitldIOq37rstn63kx1aarrpboOqmuluobqty5j 1vcYBaYpsNf67qLCtsifVX5zdHu4QI3z1e+m938XfSNldssVj8sVO/GEHLHLdFkwWZ6ktpJt2Qd+ 5Zy9KOeM/d9DdlLjWmrspMRxShynxElKfIgSOymxlRI7KXGQEscpcZwSN1FiGyWupcRBSuygxEFK HKfEcUrsosRNlNhGiWsp8VhKHKTEjqoSRylxlBLbKHETJa6nxNWUeDglDlLiOCWOU2IXJW6ixDZK XEuJx1LiICWOU+I4JXZR4iZKbKPEtZR4LCUOUmIHJU5S4jgljlef1NsocS0lTlaf1DdR4lpKbKPE tZT4JCUOUuLK6pP6OCWOV5/UBymxjRLXUuJKSpykxF5K/AEljlLiaPVJfZAS2yhxNSWurD6pj1Pi ePVJfZAS2yhxLSWupMJRKhytfP93JaV0UED5u79rKKATZR+7zv7rqaPL/hs5/03OvxndFHELNpgy t5ogG02G2yjqdp+7A3eGmyivi/LaKG8t5R1efSIfpbzRA77va6O8tZS3hvImKW+c8sarT+SbKa+N 8tZGPktxCxQ3XvG/JyhpFwUthAPU1Utd6yvp9VnT5VemzF4855znK2k2TWGbKGw9ZY1R1iRlDVBW L2Wtp6wcRfVR1ABF9VJUjqI2UVSOkgYpqY+SBiipt5pmc5S0iZImKWmOkuYoqY+SeikpTUmbKKmJ knIUNEhBfRQ0QEG91VSbo5xByumjnAHK6a2m2hzlbKqm2jGKGaCYXorJU8wgxfRRTC/FDFBMr+l1 LMXkKKaLYnKUMlhVygCl9FaVkqOUTZSylVLmKGWOUgar31SnKWVT9ZvqHIUMVhUyQCG9FYVcZhq1 SbKXo50vXWEyXUkJHbr722m3tfrdzQCl9FJKN6VMUsocpcxRSh+l9FJKmlI2UcqxlJKjkEEK6aOQ AQrpraberRQyRyFzFDJIIYMUkqaQTdVvhHOUsbn6Xc0AZfSW/05HZHnNmsjyaDZyWnRXZFl0IXJa 7TGRZXV3RIbrvxG5M5I44IxllSNPRJbXPRdZHovgMLwBx+JtOBvn4+OR5fF2XItu3Ikv4iuR5ZEl 0aPChqhnl+hbkPKU/qNwNvogfo4AO8LZuqfDhro9eAYvctZL8Sn8LDwl/mB4Sn0knK2vwZtwDN6G RiwPZxc/jT14Bs9ibzgbObRmRxiU/yty66AlenL4N9Hl4Ybo+8L+6PutjXPDoeg6r9eHQfSjMCei N4fZ6C3hhvLfPomc45q3u+btVtIe173dT9kTfbtUsSzcFj3NVtaJXhbujLbjGtzop9yEW3Cr93fa 9oRB3bgnjLztI9iGp8Pt7nO7+9zuPrfHzgwLsffj4XBn7JfI4xFsw6MoYA7zeAzbsQNFPI6deAK7 sIAnUcJuPIWnsQfP4Fn8CnvxHJ7HC+HO+LvCIP5unIYVWIn34L14H1bhdJyBM/F+XBpu15/tNa+u KYT1NY9hO3ZFGmp2R9bVPIO93j+H58ORmhfsf9H2N5GG6BGRdaqbUN2E6k5Fl4YjKpyInmB7kqqd rC9NXq+kFn96dFWYjJ4Of3J0tf3NPnOO7QfCC6MftP1Q2BQ9z+u1+rvOeR+27/ywudLbC2w/5ue0 2N/q/YWOfdxT/UX4hM9c7P0ncQkude5l+/ZG23Glc6/ymWu8vs623N2bw87oBp+51b477PtMeGHt aZF1dX8djtT9D/x9eGHdT5ELk3WzeBhPhwndTuh2QrcTsfPCkdjHcInsQ+Gxy9CGy9GOK3AlOnAV rIDY1bgGnbgWn8Z1uB5duAE34ibcjG7cgg1hMnYrNmITbsPtpp9rj90J6ox9Bkl8Fp/DXfg8voAv 4kvoxZeRwp/gbqRxD76Cr+Je9OFP8TX0u8f/HFkZG4icFfu67Z/hv/CJb0Quiw16/U3bP8eQ1//V uRnb/+b9f7f9C+cNhxfGNuNb+EuM4NsYxXewhQ//FdQ+Ngb1j/1PZPE3GMd38T18H/fhB/hf+Fv8 EBOYDJtj9+Pv8AB+hB/j7/ET/BRT2Ipp/AwP4n/jIfwcv8AMAuQwi3/Aw/v2xn6JPB7BNjyKAuYw j8ewHTtQxOPYiSewCwt4EiXsxlN4GnvwDJ7Fr7AXz+F5vLBvb/w43vtWHA8+HX97mIyfjGVYjib8 J5yCd+Cs8ML4ajTjbJyDc7EG1ln8g/gQrLP4WqzDh3E+PoL1+CguwMfQglZciI/jIlhv8YvxSVyC S8MEB0nEPxeOxP8kHIlEK6v/Rs9vR5X/DQWesY5frIvWctqDUIelnPeEyrPdlHXcYB03+MS4NViw Bgs010BzDTTXQHMNNNdAcw0010BzDTTXQHMN9NZAbw301kBvDZE6TpSPNvrzTwof5PHfi57NEcou 0B0GkSdqCq5ljofN4zGvt0fWvfTve9Ts9fo5PB9O1/w6/FzNP9q+iH1eh5J+VOqvDW+IvsL2INuD betsl9qegEb3cFK4l++NRJd5vdyfyoErs2qV+3w/VnvfjLMdP0cdPuBqz/N+rWPr+N5+z9s/yy7A xypeF6hRkxo18br873ldEG0z/a9AB65y/FO2V6MT1+I6+6637cINkUR1Ro6YcJ+ObrTvNtyOOzw/ nyQn/HV4vx7czwfzfDDPB/N8MM8H83WPOj6PHZFlvC/gfQHvC3hfwPsC3hfwvoD3Bbwv4H0B7wt4 X8D7At4X8L6A9wW8L+B9Ae8LeF/A+wLeF/C+gPcFvK/sPwEtNNFCEy000UITLTTRQhMtNNFCEy00 0UIT/wnooYkemuihiR6a+E+e/+T5T57/5PlPnv/k+U+e/+T/H/hOwHcCvhPwnYDvBHwn4DsB3wn4 TsB3Ar4T8J2A7wR8J+A7Ad8J+E7AdwK+E/CdgO8EfCfgO0Hs12r8j3gRv8E+hJFl8QhqEEUtXoGD cDDqEEMc9ViExTgEr8ShOAyvwqvxGiRwOF6LI/A6vB5H4g04CktwNN6IN0GejL8ZS3EsjsNb8FYc jwacgBPxNjSCtvhXnn/l+Veef+X5V55/5flXnn/l46c6552RZZJrISxIIwVppCCBFCSQgrQxK23M Shmz1vazcltRbivKbUVZrWhKz5rSs6b0rCk9K4sVZbGiLFaUxYqyWFEWK8piRVmsKIsVZbGiLFaU xYqyWFEWK8piRVmsKIsVZbGiLFaUxYqyWFEWK8piRVmsKIsVZbGiLFaUxYqyWFEWK8piRa44yxVn JfUdsuuy8CkeMMSNktb7iPWetc77K65UyzEmrf6RctKpWefOD6uZ4zvzeMzr7dgRNpb/1Z4DMtlh KnIYr1pT84JP/briVWtqfuP1vopXNfKqcV7VyKvGeVUjrxqvZrYlqriEU5Z41wOquYR/PeAqUq6z 7FnNPCvpelPy2oboGa71TNe+2r5mr8+xXeO8D4Rr5Lb+A3LbhVUPS1ZzW4qPjVSzW7PstkF2G+Jn yQOy2xp+luRnSX6W3J/d5Lw29yBHRa+w7cBV4UD0U7ZXQ4aKdtpeC89f0ettu3BjOFNJ7je7nu5K em+IbrT/NtzOb+9wbjXNV/LeSeE0r3uA1z3A69bwujW8boDXDfC6gd9J+486Vz/qduDpcAmVLaGy JVS2hA8288FmPtjMB5v5YDMfbOaDzXywmQ8288FmPtjMB5v5YDMfbOaDzXywmQ8288FmPtjMB5v5 YDMfbOaDzXywmQ82y4AbZMANMuAGGXCDDLhBBpyUATfIgBtkwCEZcEgGHJIBh2TAIRlwSAYckgGH ZMAhGXBIBhySAYdkwCEZcEgGHJIBh2TAIRlwSAYckgGHZMAhGXBIBhziwclqBly+PwN6rv7dDNjC g1uqGTD5BzLgGh68hgev4cFrePAaHjzAg9fw4DUHZMAkL07y4iQvTvLiJC9O8uIkL07y4iQvTvLi JC9O8uIkL07y4iQvTv7bZkA5/JfI4xFsw6MoYA7zeAzbsQNFPI6deAK7sIAnUcJuPAVPy5ykgZM0 cJIGTtLASRo4SQMnaeAkDTFrOyaLxGSR2G9gfcfkkXgENYiiFq/AQTgYdYghjnoswmIcglfiUByG V+HVeA0SOByvxRF4HV6PI/EGHIUlOBpvxJtwDN6MpTgW5bz6FtuXMmuD1yfgRJTza6OtdWcODJgD A+bAgDkwYA4MmAMD5sCAOTAQP9U578S/7ol2CeddEjmhZoEjvfQkuqriZOWnzg0crLniYB+0PY9L rOUY67w+39OrBMy1Lucm3+Ik9VZx2srtsHI7rNwOqzNtRXZYiaNW4ahVuNXKuMyKuMyKuDc2GM5Z ETdbETfHMl7vXwnLKyvh2+Goybm8mupXqNAKVTkvspLn9/P6fl7fz9v7eXs/nx7i00N8OuDRQ9VU OxJ9u2PLcBrO5seX8c328jNu9fl2v/cl68bDfl41xKuGeNUQrxqKnRn2x94Pz7T0nKTnJD0n6TlJ z0l6TtJzkp6T9Jyk5yQ9J+k5Sc9Jek7Sc5Kek/ScpOckPSfpOUnPSXpO0nOSnpP0nKTnJD0n6TlJ z0l6TurPkP4MRf5CGm86II03SeNNL/0Lb9J4kzTeVE3jtx2Qxm+rpvFxE+42E27chLvNhBs34W4z 0bKmWVYaT1SeLk4O/8TkKiftQI8vN50mKun6Qvs+7pyL8AnvL7b/k7gEbfZdgQ5IsBJ1QqJOSNQJ iTph6gQSdUKi/m2a3uj1bbgdd5gYJ0USpkvWdMmaLoHpEpgugekSmC4miuPz2BFJcNgFDpugowSH TUi5CXpK0FOCwyboKUFPCQ6b4LALHDZBVwm6StBVgsMGHDbgsAGHDThsQGsBhw04bMBZJzjrBGed 4KwTnHWCs05w1gnOOsFZJzjrBGed4KwTnHWCs05w1gnOOiGJJiTRhCSakEQTkmhCEk1IoglJNCGJ JiTRhCSakEQTkmhCEk1IoglJNCGJJiTRhCSakEQTkmhCEk1IoglJNCGJJiTRhCSakEQTkmhCEk1I oglJNCGJJiTRhCSakEQTkmhCEk1IognrKSGJJiTRhCSasLYSkmjC+kpYXwlJNCGJJiTRhLWWkEQT kmiCAwUcKOBAAQcKOFDAgQIOFHCgQBJNSKKJyC2/863nSplmVeU7q37O0c85hrhGUsZJyTgpSuqX YVKVDFPOL+WsIodQQD8F9P/+t6OyQ0p2SMkOKdkhJTukZIcU10nJDinZISU7pDhQigOlOFBKdkjJ DinZISU7pGSHlOyQkh1S3CklO6Rkh5TskOJUqZdn9TcjZ1HRWZRzPNUcTTX9VNNPNf1U0081/VTT TzX9VNNvnqbM05R5mjJPU+ZpyjxNmacp8zRlnqbM05R5mjJPU+ZpyjxNmacp8zRlnqbM05R5mjJP U+ZpyjxNmaep/8h5SiErDnDf5S99Qx15Vd1zqhTBYXgDjsXbcDbOx8cjl8XbcS26cSe+iFTlG/LL 4n8aWS7Nrwr30sVC9PzKfw+0jp/I9ZFX2B/Iyj+Ud34o7/zQk0FJWt9T+YZgyiwKqudO1dJgLQ1G PkVvI9UsPhQ91/P6B2hr//NDytkruVm7P2eEo91Fg/00OHKAq6W4WjtXa+dq7XTZT4epunLfLvHs eikuQxsuRzuuwJXowFX4FK7GNejEtfg0rsP16MINuBE3gRPS3QjdjfxfO9o/dbMUXaboMkWXKbpM 0WWKLlN0meJm7dysnZu1c7N2btbOzdq5WTs3a+dm7dysnZu1c7N2btbOzdq5WTs3a6frfrrup+t+ uu6n63667qfrfrrup+t+uu6n63667qfrfrrup+t+uu6n63667qfrfrrup+t+uu6n6/5ITfRsnnHW S1Ot8v3PqsqzUvDy9zznH/DdTnnyXGoaVCfEv8t3Kv/StPg3/E4j8joqHqk+JQYv/9bmYnwSl1Rm VaC7ge4GuhvobqC7ge4GuhvobqC7ge4GuhvobqC7ge4GuhtE6mSiifI6q9a7vA6Dl9fcGToypSPZ akfKT+FT1W5M/YFuTOnGlG5M6caUbkzpxpRuTOnGlG5M6caUbkzpxpRuTOnGlG5M6caUbkzpxpRu TOnGlG5M6caUbkzpxpRuTP2HdqOWtyzoRqUTtPu+SENl31R139TL9Zqo1muqWq/sAfXK/n9Wr6x6 ZdUrq15Z9cqqV1a9suqVVa+semXVK6teWfXKqldWvbLqlVWvrHpl1SurXln1yqpXVr2ykeaKH6/i s+dW1nT5d1Zfq+SAcr3K3+fsr8yIyoxUKzOiMiP/Ln47jM34Fv4SI/g2RvEdbAm/Zg187d+0QgdV FHX2y/Nsqjr79utpwWTLmmzZyHkqmVXJH0ZPD3c5v181Cyq5y4rdpZI/ja6PNKnmjGpmoy32fcLx S8MZFS2oaEFFsyqaVdGsimZVNKuiWRXNqmhWRbMqmlXRrIpmVTSrolkVzapoVkWzKppV0ayKZlU0 q6JZFc2qaFZFs7EN4a7YrdiITbgNt+MO3Ilh17EZ38JfYgTfxii+g8lwRqVnVHpGpWdUekalZ1R6 RqVnVHpGpWdUekalZ1R6RqVnVHpGpWdUekalZ1R6RqVnVHpGpWdUeqY8acIRlf1tdshWV/HZkXWR Os9R0zW7Kr/72OsZ5QbPKEH1t+KZyLvk05J8WpJPS44+G7XKPDfOV3/rXYre6X1POFWXxyPYZuU9 HJZktpLMVpLZSjJbSWYryWwlma0ks5VktpLMVpLZSjJbSWYryWwlma0ks5VktpLMVpLZSjJbSWYr yWwlma0ks5VktpLMVpLZSjJbSWYryWyl+LvCqfi7cRpWgCvF34P3QgXiq3A6zsCZeD/vuqTyG+3y v8Mwj5d+s/1Pf6sdVH+rHbz8W+2X0vv+3x5PVFL8dbb7f3ucjW6QxsrfLt5h32fCocq3iblwwrPd hGe7if/QdPv2cMJzzYTnmgnPNROeayY810x4rpnwXDMRP8vT92o042ycg3OxBh/AB/EhnAdPN/F1 +DDOx0ewHh/FBfgYWtCKC/FxXIRP4GJ8Epd40q8pVy5yOE0WXv5tYNR6fgUOxlWUdx1u9PqOcF4t 59VyXi3n3c+8+5l3P/PuZ979zLufefcz737mrYArw2LUtCj/xpGGvxc57uXvFMr/fn6p8jcZltU8 Vfn3Lhv0flnNs14/H47r+bjrGHAdA65jQO/Lz/uzrmU2ekPkaL22Kmjilsp1zdaeEllW+w6cFknU nhdpcJ2zrnPWdc66zlnXOes6Z13nrOucdZ2zrnPWdc5GjqfGBSpcoMIF6lugvvLfPClQWoHCChRV /tsjBcopUE6BcgqUU6CcAuUUKKdAOQXKKVBOgXIKlFOgnALlFCinQDkFyilQToFyCpRToJwC5RQo p0A5BcopUE6BcgqUU6CcAuUUdKm7/C++lJ0i8n5X2/jb72a83o4d4f1qebkaXu4OGt1BozoWquun UFk/0XBaPafVc7q6llrcYYu6bnOXLWq7rbKGbvX6jnBbde1sU8dt6rhNBVpUoEUFWlSgRQVaVKBF BVpUoEUFWlSgRQVaVKBFBVpUoEUFWlSgRQVaVKBFBVpUoEUFWlSgRQVaVKBFBVpUoEUFWlSgRQVa VKBFBVr0cJsebtPDbXq4TQ+36eE2Pdymh9sqtemPvEdtAjUJ1CRQh0AdAvc55T6n3OMUNW6t/j2i sqtOuNepf8ZRp9zrlHudcq9TsfK+R1HAHObxGLZjB4p4HDvxBHZhAU+ihN14Ck9jD57Bs/gV9uI5 PI8XOOS/xlFfe8DKGtDpUZ0e1elR3d2is1uqDjmis1t0dYuubtHVLSq7RWW3qOwWld2isltUdovK blHZLZV5tf9vef15+N3oX4U7o9nwqehD4d7K3+I6Ovp17vANZPy5W2x/YYXmrcjFkRNrD7XCvscN JsKB+CS2ouwcv0Qec96XbF8MZ+ujOBhWZ/25WIP16AhnF8+F84vn8Ri2o8hdjoqmwu3RwXBPdIhu MzT9F15/B9/HjBW8B8+HO+PZcE/8PvwtrfzQdiKcdjXTrmY6/rNwe/xBzHm9w/Eidod76peGC/XH 4jhcEO6s/1i4M3JY9J5wsSoMREfCyehEeHH0gX3zKjEZDcJzoo+q0Fx4bbQYXhfdFTkluntfKfoU F3sxPKJ2cbi49ojwikg0mo0cE12IHCPL36NOu9ToTeV/k18Vp1VxulLj8r1swQz+IbzIWVe4l+la 1amNlyvr9aHhXO0bKtWd/p37eRi/RB7leyqF0/V14UX1MbwKS70/FsfhLd6fWan2nGrPqfZc/aXe X4a2SuXn6m+sVH9a9adVf1r1p1V/+pBIOHtIDXTtkFocxEff6i5K7qKkK2U9TOrIrI7MupuSrszX 1leufLb21TgS5d9HZPX/e3LEfbY/dEcT4aS7mXQ3k+6m5G5K7qbkbibdTUl35uvf5+rOcgfn/FOt 1N/kCmUeV1xyxSVXXHLFJU+ffx5+R/2PiE66ogdcUeAqd0XOKf93sZV+3E3ZJf3aGrm4prCvWPMY tqM8q/baPoffzqb7K3/b5ODKv3Nypk+fGP2qn3cv+nX+6zT4DXzTnzVkvWzx+rv23+e9fvnzT4z+ iO9stX3Q9ucI/CxeQkE7o7wkykuiu8MjaPgKvV/Q+wU9X4j/lUr9daVqZU0/Ff+x1z/ZV6LlM2n5 zPiM9+4tblar4B4V3KOCe+KPeL9NhR9FATt8togFny05/vS+Un0knKqvwSvDE+uPsH0j3oRj8DY0 4mTHltueYntmZX1cYX1cQTsLtLNAOwt0s6ALe3Rhjy7s0YU9urBnMf9bzP8W87/F/G8x76OlBVpa oKUFWlo4pPz/lFGrW/dzm2cr6yPx0m/Z1fkiRzJWYMbR7ftXoRo+FN5XXYWfswqPUcMb9LZB/Y6x Cu+uPSocr11CfW+KNNQeE/6ivJb3Pa/f9/sJR1jHd/sJ5/sJx0TndKlou4tSdtv/lP0v7htf/HDY sfiJ8J2LF8KBxS+E76z8PYiNZs1Gs2ajWbPRrNlIC+VrvJ4WpmlhOtrv9SDH+GblX0q424oYsCIG XPtsRW3fdfz73t/n+ANe73b9L4ajtbWu+djwbr2e1uvyKhmwQgb0+26rZEDPp+M/Ca/X84yeZ/R8 Ws+n9Xxan6f1OaPPGX3O6PPd+nx3fMH5u3326fD6+g+Hd9d3oTu8u+Lwld/sqOzdrqygFgtqsFCp fV30HpXIcrSFyHujL0ZOjG+PDNc3RO6tvzpyb+Tr0dS+2Uot96v+fKo/3x3PuuOymx1R8YARndnv A+e769nKSvi+7X3OmfD6/rAp+nd4YN9o9Edq/hOvf4opbN03Hp22/RkedOx/2z7kz/u517/wZwc+ n8Os/f+wb2P0YdtfIu/YI7bb8GgYjRZs5/z8edvHsMPni8553DXtBC+OPml/Cbv9mU/tK0Sf8frF ffO1/4e8s4GPorj//8zs7R63FwIoCj6B+EQUUBoKpXpSRY0iqCfGp6AR5ayINFqfmmqFGv012lJb sOZnbdRYLSL2AWtsFZX6EDRWCT6bKCiJQlBPCCGNGDH7e8/cXnK5XHgQqO3/v/v63M7uzs58Z+b7 /cx3Zvd2rfY6LHAUFjgKDiuxwozWsjwXHiuxBnB+b7b7cO6gds1pJdZQ73paTLNzPq1WZ3jNWGh7 Xeg18B7HV4CV4ANaaxWoBwlLzKeV6rQ1hpq9UaFW8AVoA5u59iu27cDzRrmifa4rgWqvc22s12Eb bL/B7QV6cz67fbHbh21f0I9jA7x8dz/Cg8Bgwvtz7RBwCOeGciwHHOqVu4eR1jAwnHMjwEjS+Rbn cgmPIo/R7B/jlWD9o+DhEni4xD2D49PYj4GLwSXe9e50cCm4mnPXcuxHxPtxu+5R8mGGfJghH2bI hxnysza0z81qBhtBC2htnwszjIIZRsEMo2CGUTDDqN4Rb5T4NjambSuOpo1G02robfLRtGFo2TDf ruJo2Gg0rAaPJNGX6j7U9cppvTi9UDmtt4iWW0SLldNicVpsNK01mtYaRi+UTy+Uj43F6Yl0K9XQ SjW0Ug09UT62FKeVRmNLcTyX5Xguy7v0raPAMd4iaqec2llEL1VOL1VOL1VOzcSpmTg1E6fH0u99 KWd0czf2UGFspC7pQ2kOQoe0vtShL3XoSx36UZfuL1GfddRnHfVZR33WUZ91YgoWXS83CVduFi68 VE9dNcJBjdRVHXXTqJ4X2aoavAbeBG/jIa5huxZ8DD5FKn0P5Au2beBL8BXjKwEkUCAAbBAEvUA2 6Av6gd0B3G3tCQaCvcAgMBjALNaBQN8TfNxrpN4b4bZG6r2Oeq+jzuvgtnq4rZ761n1VIxzWSJ03 ukJkuxIMAIPB/mAIONB7h/p/h/p/xx3O/giQC8aI/u5YcCQ4GowDx4Lx4DhwCoiCySAfnAmmgAvB ReAyMBNcI/pnbRDZWc1gI2gBrSK7N2mK71PDzbRhnDaM04ZxevdWevZWevbWRM2yXQs+Bttaq47X 3FGzIcKu17jVGt6HeBlqGS1vRJfi1GoztdqMTsXRqTg6FUen4vT8rfT8rXBEK9zQSq/fSq/f2rVW 2R8BcsHWavV4vOg8WmtrtTuNeDFwMUipafiiGctoRLfj6HYc3Y6j23F0O44X0YoX0YoX0YoX0YoX 0QpXNMMVzXBFM1zRDFc0m5bZjZZ51njbd+mex/h+dfhdy+lrl+NbNWHjWteepVaexa5hXqwqG/sd CUaDc7wm/JsmvInb6aXv4qr7YJn72c6nH3oIX+ERkGCd5VjWMHrw5fTgdbRXqfYuYZu5sE0pbFNK r677iFK0fhhaPwy2GRJ6vn1TqAq8rL14tg0gTng95zcYJimlLkthklKYZC5MMpceXPu8c2EQ3ZNr v7eU3rxOKM3g2ksRYUq6SL3UySehz9O4IwvsneAQYTPWoPcAvUA/cIg5+rypsenGW27wGqi10fgE 7+IDx8Vo4i8m/mLiLyb+Yu0XMBZ/hyslV5WLgPFqEtfGtXcjHD3XRKpv+qnW4Wl8wJnpYg+5Dk+b VpHNbDcaL3l5h/y11K8eV46mPsd4i7qUxfbWdSnPYewPA7pcAfOU5/NIkMhL3/nVkh8qFooD8eGy 8OGy8OGy8OGy8OGyiNtAzvlY8Fz0ZDRWPBcrnmvepdNAf4I/hSWXY8nliZGe+e8UPTHIJjwATh8M 9md/CBgORoCRnMtlO9objQbT24GNoAW04ofp8tdR/jrKX0f5k+WOU9tLKftnHWXf7H3mlztuyh30 ltIKS2mFpbSCftNYnPLHTflDsE8zqTTBOs1c0YRFN2PRzVh0MzGbiNlEO7/trSTGSs6u5OxKzq40 dbcc37kZn7nFzE/bevyWPuZC0zZ569D2Fqs3o7xDvBa0tcWdwEjtHFrhXFBE+HLwI68F334zIxra ijFxk5D4kQuFZH+p+Y2jOdiPsPDXm639Td6t5ks/9ULpeS7kScQZhm0TU7Uba1tE/uuwsnVY2Tqs TPfr69yjjPWsQ551WM8693T2z6A/LmR7NdsfcezHjP90yuWk3KJTFsPweDd7+aSaBQeXwr3ajkcj bzn8qm04yxotzrPGiPPguVJSzILHSuGxUnislJSz4C9tj1nwUim8VAovlcJLpfBSqehtmKEPSLIC jJBm5aXUcCk1XEoNl2rrFtkpMwB1evRvRu+pI3ZG6xlH5kHaZzV5riaf1eSxmnZZTbusJt3VtMcm r54j9RyppzfqZC/9zqjFyFmInIXIWeizVyGyFpJOIbIWImshshb6jFSIvIU+IxUaRpL6DVRCWeeg G1O8T2nZc9CUKd4b1vlaG/zjn7DXamKtMbFCVr5Xb53pfWqdBc72GqxzvbVWgbeKs7+3zvM+J/6L IkCsDzm6nqPvcuQtNPQs9s5Gb9A9jlZxtNnEa+XIL4n7mclX5/SZzteEPiJETVgzuGYmvezlXgN7 M70XCdVYP/TWmL3FVhFp668RSvY+E0FrurfBupR6neG9Yl3mvWX9gPDl3q+54h3SvZwjP/RqyP1S 6m0GZbzc+xlH3ia16cgz07uKFMuJORN5dbpaAn1cp8Io2LqHPPEKrfvEUPJ8wCsxv3WirzNRLHEm iTznfpFrvlV2B+j+jbKF7kIRc//O9nG2iW+S1ZhvkQXM91fXmK+p1pJaVH+ZjX73F2KQ/7WtcvMm 7sQbsyUx8uDudSIm14sy2cx2oyjDCsqwgjJirmdEvFHkChUe638Btvc2f/m2PuXrt5Z+wz+5O+Ej kUDnmyuOELeKCjGHfOaJmHiC8GLwJHhKVCghYvYmWWh/Ab4UMScoypy9RIWzNxgkFjqD2R9C+AjC 49jmiRLnRDCN8CzizwZPyOnOM/LkYB9RErxBFgZvlFcGS8At1NxNosS9E5nuloXuPaBCTnfvAwtE hftXOZ3yFofHiVj4NDBZXhmeIsrChWIudfB6+EKk7i/+QRmeBc+B50EVWApeErmBYSLXyQZDQQ7Q +8PBRCS8jG2JyKUddRvGdBuGz+e6PeSnph1KqPESNUCUWEcRe0c1QnE2yhk0gVAB8fReAfGiIsve JObYX4g5zhNiTvAGcKOoCJZQA3eLOe49oMKrde8Df/Vqw5NpmSBXRIgVJVa0y/elJ5Oerf8JzZES jpRwJEZt5Qgr9ctzJk7HHnEKiFMshojfcf1m8BVoB56IBsaD48DxIqrzRdKIY4uocyQ4GcwDt4M7 wb2AklKKTvnu8GZQVzOoqxmUKEKJIuReQO4F5F7gNoqokeAM8629IqS4tUMby9DGMrSxDG0sQxuL kaAMCSqMNu6F9u0NBnmtaGEZWleW1DokqECCSiSoDN6CT220TJSRexm5V5J7JblXJjRLLESzitEs /VXAajSrRAwk9znkPgedLyaXOeQwhxzmpKZMihWkWNGR4gI8A53qWFIdR3mOEXPCUVM+nUNJlxy0 xRejacVYfDHaVmy+efg4ZT1OjkIHR4Mx4DuA9OR3wXjRJo8HJ4A8cCI4CUwAk8AUmGIa+D5xLwEz CP8AXA6uAD8EV4KrwNXgenADmAV+KiJyLfzzCfhUrEG6NqRrk01iodwgqpGyDSnbZAv7/xLV2EYb HFUNR1VjI23WUrEmgLYFzgD54ExwFjgbnAPOFW2BS7HKmQCZAkUAeQLI47wj2pwmWo48HPIIDqEF DwAHowUDKXUZpS6j1GWUuoxSl1HqMkpdRqm1tCVIW2bYk1SQNoa0ZZpFkTaGtDGkLUPKMqQsQZIy ciwjtzJyKzNfMPgApmw131E4SDreDLk/GAIOAAeCg8DB4BAwFOSAQ8Fh3lg5zBsbOMGbEcgDJ4KT wARwMpgIJoFTwKngNBD1Zjhvg/fBB2CVN9ZZx3Y98LwZQfIP9gYDwDRvBv0J3ElJS5xn0L8+2EiO sRHN2hlsRGWJhaov6C8WJu0lxVbiPmuXOUcQHsc2Dw0/EWA/+k0KaPZCbCYOOxd3s5kF2FJXDS9O sZ8itLsS7S4WV4ibabufwyG/gFXngF8Svg0sFIPEw+AJsBg8zbEl4B9c9Yxh82LYvBg2L4bNi2Hz YvECx6sNqxeLfxL3FbAM1IBXwVvk1UAvupo4a9Blm1ZfyzZVM3yNoHYqqZ1Kaqcy2ccarRgmigP0 DoHZItemD7Y3ArTHboP34ETzNVOJjobZZhtOGOTsQ3gw+juE8FCO5QDSoZcpdkaar5/mOkexTXwB tcw5neuxDwf7cLAPanyQE+P8xeD74BIwHWAn9FDFzkzCPwBF4HJwBfghuBKUcP5nxCsF5ezPBw/C uUUwXQjenQOoc/qbFR1fU/074cSXVKPuc+brqUVhuCZ8IsBPCU8C54virJ9SjzZSV6f3amIfsdzU dxn1HaWOY/BFTH+njDqssL8yZY45E+VAylvpnEoYhqXcZXg//ZEphkwxUm0j1Wpk0j1QHqm3kXo1 csWQK+ZWiRgyxMTepFxGC1bTgpqBqmnB6tQWNHadbEXsO5F7Z21nqIW8TLUgsskp6vtgJb4Ppvv/ PFKPkXqM1PNItaBbjYTEb81X5KvEF6ANfGm+Xl7l3GG+XK6/Vl4lsrv8X+b3oqTX/eABUdyLNtP/ kwkdJPJCB4vi0FBRFMoBw0U0dLiICGX+g/Ygod2/1l3STd7Y1DuljEbGMhoZy+jwUGzK4Xx56qiR 8+WcLxeHbSfHlJmesmeemQPPFMEzRYZnbujGNUUpXLMQrlno96YL4ZoC4wUeI36s/Z+0vrpYhJAg DwnySLGAFAvSPCDt3QwSB5jydC9LSVpZKgxfdi1Lh3/Rza9I9wD+Kh5F3mm+vHPSfIslRt6Mksg4 vVSaNEjR6eUkazIDW2+BpQu2KMlZsHQElo7AzhHYOQIbR2DjCGycAxPnwMQ5MHEOTJwDE+fAwDkw cAQGjsDAERg4AgNHYNwIFlSUgW0rKE0FpalIt1UYowjWzYFtI7BtBLaNwLYR2DYC00Zg2ghMmwPL RmDXHNg1B3bNgV1zYNeIz64R7H0Nllnss2sEdo3ArhGYNQKzRmDWCMwagVkjsGoOrBqBVSOwagRW jcCqEVg1AqtGYNUc2DQCm0Zg0whsGoFNI/BILjyixwvVPo9oBqjW35+GQSMwaAQGjcCgERg0R2R1 8AlcQi2UUAsl1ILmFM0lsW48coBvbxXpmtGDTmr7qjBa0TnqStfP+FY81CK0otL3TEs6RlX7+v3m NrOu7j/pH/NMi3Rl32StJdi3k3lzYd5cXXumr+lLjnnd2DcLnukL+gNda51MrGuvwq+9ClN7LiPi qm1i4mGMcgoY5RQwyilglFPAKKdAZcls1Rf0l9mMeAoY8RQw4ilg9Btg9BtgxFPAiDePka4e+RQw 8ilg5FPAyKeAkU8BI58CRj4FjHADjG4HBm8ifAt9zRwz7mhjZDuQke3ujGyj7h91ryf3Y+RTQDtU 0w7VYfxbRkAFtMUK2mJF+AJ5AG2xhvFikg01E16AtUnz/e1A2gguT0zwPa4YthzDlmPYcgxbjmGv Mew1hr3GsNeY6cFfZZvsxRPeUteevKsHFMMmY6Z3T3hAMWwyhg3GTH97VOYev4unEwMXA0Ym2GIM W4xhhzHsMIYdxrDDGHYYww5j2GEMG4xhgzFsMOZ7NLHt9SBSPJsYdpnwKKSZj7mEuooa3uv0TtP5 L+p7o1E4MAoHRuHAKBwYTfFGo5m4kHot6eKNStGfOo724I12sH26VcGN0RSPNEp7RGmPaJIjjcVJ 2iTBk1HDk4PNfEcUrozClVG4MprGlameaJT2idI+0YxcmfBCo1vhy2iKF5rKm1GfNyM+A7zuM8Dr qQxAG0Vpo2gKd0ZFKNXytReKxNFuFm9h8SuTViD2zdSndjBnah+aypY9j+MT/Wdn31nZbfweMHNH Czvnj8RR39R3e+3/Nfyrfe88v4XnOFFaRM9XXS++Zeas0HRaI4/WyMswd1XZMUZ41IwTKv1WyqOV 8vy5rHfcNcZbjvlzWhXEvA8dD9HrxKjLEuoxRj3GOFPBmQrqsIK6K0nMWSbnuTLPcaXMyYxNzHNx VXSrVy3hqiVctQQmjXZc9V20oU3ME5VwvZ5HakMr2tCKNrSiDe6Pwf0xuD8G98fg+xh8H4Pv9Wxn tv0lPGab2c7X0Zw2NKcN7i9Ae9p8/o/B/3r01ubMIu5sMI/928GdAC+fviBGX5AdnE0/cCP9QaJP KKJPKKAV9KwnWiez3XtAhRxO3zCcvqHA7xuG0zfEKNEr4dOoj8n0BXBpSt8wBg1sMvN1phfTPVZa T1VgJE3vpZI9VEKqbKTKTpGq2PRU95je6gAkOsBI9Fe2uqeaLLPTeqjhpocaR/2WUL8lcGYMvozB lzH4MgZfxuDLGDypR+e5ST7Us8qpvJc2Co/5LV5m+C2I1NnU595Y7BAwlHAOIB7cFqOUJVh0DIvW 475NhtummfndGNwUS3KTGV8k+uISSljSoaEJXqo240K01eenyg5+GmtmVcsodRHcFPPnOLT3XCRG oGEltEEEjYrQDhE0KoJGRSih9pfWUMI1lHAN7RNBwyJoWITSraB0K9CyEtoq4vRieyTbk8EswrPB PMK3gzvBveAhGPUGsQL9b0L/m9AebWsrKMkKStJGSdqQvo12isBXS9AaPe5por0iSF6J1Np3aEPq StpgHuyY2QcK4AMF8IECXX0g0YbEbUhcZrRL20WqHzSL47NBJn/oGq8hVdOMlt0JsyQ07UvfLzog xS8a6PtFL+ATlVCSshTNe5eSVPu+0RtitF+SqF+SaGdJRBt130bdt/nz1128Ob8k0TSPLppSktQ5 7QIzp32NV0sbtGE70TTb0V5eUUqpkt7eQEqVl1KqqPH2jqc/SZSql5nzTrengyhVhSlRsjRCrOhS ou6lqfDbJM+UZBb7s8G9vlXfaRgzXbKO+kaq5/y6rjB1PYVxQCFI1PMKcfiW7rL43k5OircziP6v eDtHgsX6bo2x+Ex3bHS/5t+x6bDoOWYu5nW/34qkeBZ5ZlSm7+Z8y9eQmK8hsR78/VgPuh7zmbTA 15BYioak8n2Bz/eaWWM+1xf7rJquGZ3M+kfaJsHzqVox0Of6NbTBGs31wjbP4S3xalKflROKMgUY 9wiRLfqIoNhNDBAhsZc4mr2J4jTxbXGmmEFPeI2Yzd6NeKcF4jURFwvEOpklqmRf2U98KPvLvcRq uY/8nvhUniJP5WhUni53k2fLH3DuR/JGOUzeJG+WY+S98mE5VtbLRnmC/Jh1koyzniLXyfVc1yw3 cmWr9ORkpVRQnqfCKiwvUr1VbzlN9VF9ZEz1U/3kxWp3tbv8vtpD7SEvUQPUADld7auGyEvVgepA ebk6WB0ir1A5KkdeqQ5Th8mr1HCVK69W31aj5fVqrDpK3qCOVuPkjeoYday8SR2njpP/o05UE+TP 1ER1mrxVna7y5W3qLHWunKfOU5fKMnWZukw+oH6giuQf1BXqCvmgulJdKReoq9WP5UPqJ+oG+Rd1 o7pJPqJ+pcpkpfqt+q18St2t7pZPq3vVH+QStUAtkEvVH9Wf5AvqL+oxWa0eV4/L5WqxWixfVU+r JfI19Zx6Tr6hqtSL8k31knpJ1qplapmsU6+p1+S76g31hnxPvaXq5ArFKuvVKlUvG9SHarX8SDWq Rtmo4iou16p1ap38WDWrZvmJ2qQ2y09Vu/Jkk6UsJZstx3LkRquXlS1brH5WP/mltYe1p9xsDbT2 le3WEGuIsqwDrQNVwDrEGqpsa7Q1RgWtfOt8FbKmWz9Uu1sPWA+o/axl1jI1yFpuvaoGWx9bm9UQ ywuE1ehAduAcNT4wJXCJ+mVgRuBadVdgdmC2etA+yj5KLbDH2ceqh+zj7ZPUn+yJ9kT1V/tU+1T1 qB21T1eV9hn2mepv9jn2ueoJ+3y7UD1pT7Wnqqfti+xpaol9sX2xesa+zL5SPWtfbV+rXrKvt2ep V+wb7ZvVq3apXaretH9u36nesu+yf6c+su+2F6k19uP2EtVmv2DXWtJ+3/7U6m9/Zq+3DrCb7Wbr YLvF/sI6xN5sb7aG254jrRFUTy9rpOM6I60xzijn29b5zhjnSOsC53vOMVbMGe8cZ33fOcmZaE13 JjsXWDOdC537rOucB5yF1pPOn5w/W885jziVVpXzd+dJq9pZ4iyxljnPOs9aNc7zzvPWcudFp9p6 1XnZecV63XnVec1603nbedt626l1aq13nPed1Vat0+h8bK1y1jkbrA+dFudzq9Fpc9qsT52vHM+K B2UwZK0PhoNha1OwdzDb+iLYN7ib9WVwQPAgqz14SHBoICt4RJCWCB4dPC2wR/DMYGEgJzg1eEkg N3hp8LLAkcGi4FWBo4PXBK8NHBf8SXBW4ITgjcGSwEnB0uCtgZODlcHFgVOCzwSfCeQHXw6+HDgz uCy4LHBW8M3gm4Gzg7XB2sA5wXeD7wbODa4IfhAoCDb2ygoU9tq/V07g5l6je50Q+GWvc3tdF7in 1129mgLP9GoLSXtA6IjQCfbg0LTQZfaY0MOhh+3vhf4c+rN9TOiR0CP2saFHQ4/a40OPhRbbx4We Di2xJ4SeDVXZE0PVoZfs00Ivh962Tw+9F1prnx9qCjXZl4VaQv+yZ4Y+D31uF4W+CLXbl7vKVfY1 ru32sq91s9ws+zo32+1nX+8OdPe2Z7uD3YPtEneoO8y+1T3CPcK+zR3jjrF/5Y51v2v/2j3KHW/P c09w8+y73AnuJLvcjbqn2xXuGe5Z9u/dc9xz7fnuee4F9gJ3mnuF/Uf3evcn9mJ3ljvLfsq92b3Z ftotdW+1l7hz3F/bz7q3u7+1X3DL3fvsZe797gP2G+58d779lrvAXWC/7S50F9rvuI+6j9q17mPu E3ad+5S7xH7ffdZ9zq53l7ov2h+6r7jL7DXu2+479lr3Pfc9+5Nwbnic/Wn4mPCx9qbwieHT7Lbw 6eHJjhXODxc4dvi88PlOVviC8FQnO+u9rPecvln1WaudflkbslqcPXuL3ha+rxr3bbheHNM6qUpM FheK/8cWr7bzNxnyNrBe7b1MSOMWDa/VPz91J+c/D9yT4XgNqEuN581HpkXeJLP3mZHzsy2m3NIR akhg1yzeJ2Ad+HD7rvIWs36yzfHfNL8btle6jGnF9WpCaxJpeh8BWtj74GumuKGrdN3l9Jp3lvQ9 5Z8p9U697vHKeGcKHWn0NzZgNMZr3MK1zZmOZT7aVVrWtV5DUie9jVuTskcJNmj5E7bpt2i841y8 W+x4pqM7azGpf62SJFspQxskytSY1J7uJUjyUtdjmY92iUE7eau8Wp//NnSUYLvrx5ulOcmb1a0E foh8dpneb+vSlQG98WlnZ3iO19+bYcKMdagV/VsjBpn9Wh2GMZrYa+q4Ju59DCPPN+HyDDmWw9Vx zXHCtKVuZdZyv74f86q0RKwbzK9m+8lbkL+KlGpIsdakJ7yDUs7VJq2153o2rf2MCWm2/id4qefc dmwxqb8K1m7XVa3UwsoUHe2fIU5KL0191CZKs+OLyTvBdrp2nqTdqgA9jvfpVq+Nb3ffKr+mmLt8 oRbe2pWewq5fvPXeC7Tf+m9Yimd2UjoJrujwAlNCmfU+g83sikXzXYKH/CWHnHPZ5naLubLzV+TC Uis173FkPqEGfVwzqGY/FtfMKCVjp6WTcnRQ19Q7YrzBOs/7cScbY9cP8/uPDOlV4UvXGM++Zitl bej8TQ15k73l/GpMSsA/Pm/L6W3v4p0FftCTXCn7Y/116lbS0/3EKhOaBcf90/DXPG+I94uOGLN2 UOIXvYe8h/xws5fl/cIb71V4GUaOWodSavZwH+MTchp+/y/ionTPCa+tyntuS/7zv2NJHUOa/S14 qN10qsb769YspLN82s68f+yq8ia1wXt6i7HiSU/P585GmOZ325HLC+Y3AwPtyOJV+h6RZouPtlyG ztr2medwb7eEXWTmIjOS7dNxeX+R2gvk7KwS+MtefupumsxJiRJ+7lg/ri8HnNS3fbPmsaSnnMLQ s9CxrlrXH35PpFMOP0R68K6NX21iJHNtMN52Yry0yPx2jgQbTD3GTdq6r8oRaX1lwps0i/b5+yZD ib6GviJX//pxmxO/mUe6/65ly96156TtT29vbve86Sb8aedvItRzOcwoSG+XZTi3TB9lDLmq61F/ +7H3cbcrjkvbb+qyV5XqVbRvoXx+C2xI3fc2ei34AP4I1qtOYNcsZrT2ZobjPYydu8/CJFgyyZXU YaP3uglpLX4+Mabw7jZ6myirDr2XIeX3Mh9NysNqxvjemsQY1j/6R/K7H1/5iW5XLkqOMTvnRQ3M aNFb7b2vfzOX0k9hTUdoreHfXTTfYupou+cVvCnau/CmmPAHnb/JUHJe8JtcjHZ18Yq6nH3SeMxP bleK3yBPZfAqlsP6t+q+cDvT2alt492Rtr9qC3HT+mvv+97x+teE/2Z+n+k49zdjJz3byKAez+zU xWjJoo69gzp6M+MT0Cc7Xl9/zm4efmp5YtUjOG+G9wfvNjPb9Bh7jyVYmf3F5lyCFyZlyLGKtdab ZPrriDlyizlmRkTeVNqv1hyZxdqge1P65FV+6lWp0vrXjueag9iaPLvMeKWNUBJ3HjrvP+iQ4b6G 5Ly4nhHYdbMCPc6+78Doxas3v4vNXYlWsRPv4fg1U5tqTWYkntFz32X8vdU7E1u5/jnGGhlG9lu9 rsZH1Y7l76eWYTSFJ5Lx6M7Ib+ctMEDCF++b4Zy20PnEuIVWytF6wf5c7PBm/8r56KWOcwtr+VZn HOYlZ0j8GfYU7tjhuYYdtAgsYSXrdjJDysiiakf1WCz8GldkumZ701mYgq+94ENqZm3ZekzRbyd7 IYPSxrrf4IKXu3Jnzxlstwyf9TBv+oYw91u7HH0jdd/Mm8a3zbv6z52Towz/1Hee/j9cYj52fNlB Lupog2+Ei4wEO9ofvOW9mWlkv5Wr4h3j5Co9Qt7RJZMlJuwz/c5+x9Mbncf7m3Xbl+1l0Mh2xk9f BplRSO4W08ntfidpJy67Mu3/lKVsG+JEu+yZ+SeRtxPyTeJrL/Ra74tB+q58hnMNnbNiZj/x7M9O 6pO8sf9BXkVrer+93Sk07aAIg5DgowzpfmTuYqR7FRlifr1czf2FHW6DBJN7TYl7OmnnXtBH0bPk DGxiPtaPmT6nvQ15dfGLvPFG+h2e6fHe9d41PnaGO3BejZl972gDf243Ofu+egc155ydU4It5pFR uzM9ubaN6W3zTEXXp9So3w36uRc9Z0ao0szmzPNmdt7J96ZyfE2GdNb0cLSjDOjgW3hFD3n3e/f7 Rz72pnj3eVd5//B+0+1K/VTThyl3AKeCiaLjeTWvMf1urll6sJSOZ8L6+PcH+2SI1Cft3qHIHNNb 2/GkYH3CWjpqr/uskdvtSDKVQ9s3e44/+15u7kiYXz0nSegF/5muxq6pMrKZ6j9nl2nWcR5rg3e1 mc1IzG3q54rnJeaGOJ6Yu6zBMzO/7O2bqdX81Gq8w7l6kn4G0Oz3TTm32GjCSOE/A+7fGetsLT2r 9P4W/L9/18xvVersFj3aIP+OZ6J2jm5vbm/22+ARUy9/957ynjJt8CtTd7WJtu6E0aPr/CcPL86Q 43xz1+hmrt2Q8Cq8hwkv8u/DXm+eqNQzv/NZa8wT78eYe+Fd7tV3pDaP+p9v4t9jzu6Wcq7ctOkE 4d+N9VZ0/iZDXn1i7jTj8u9qg5rUUmG/XWffL/IO8vbyfmLCf9dPf/Kr7UDf7V7kVcMYDfT+yXuZ 8Q7v/07/6anZGXLULfeRd4dppcTse3XiqVETvs2/P17jz9JrHTnVWFqryPDcb8dMfZU/A31oyrm0 mVP9jEjyNxnyWrZpTmiXLl3vJ2wxZup/QPqb0ps7o2jhG/gCb6TbVErstHR6OJq875qYd6/1/qZn UP2zmk/nd69Vc26xeT5iltjqU2r/bYtf41Vou9bIpd47Pcbs5NfFsO9i6jCjn+kt90Z8fVlgff1s doNhLSMP26Xe0i1e57eYz0TztymvxB23np4TWJz5+FZTnS8676LFE7mYYxl4YkcX/cxk2jKs83fb bS5Dylyr77Rm8te3em1Cn7bJA/z6HuYWU42nbWv8ttiG+9x4DYtMT7cy09Mcfpzkc6fndfgfXca8 XqG/rc/kJW3LYvrOSdiAtoM7jL0Zedi+uMXrkqOmxP2kLdpMxzWJuD2M2rf/2QD/uirRcW/PjFBn JeTZFXaQMf8B/NxgQlk7OenClFwWdej7DNapIMFATvub7WvxjpxM9/S2dfGy2usSbQijZnjybqvX d8u7Z3lS7+mb/bPaN2tvKfGs4H/O0rM86fc+aYO17W9iRU570w7kl5XUH3ihcMtxMy3d8+5Zngxt sPa/uw06l/Zv8NnrTM8vZpZHM/rOWfD/9ZMvzfpfy93OvWz+y9zYdbyejOmPLxq2fR7V+Bs99dRK XCMCQvdDp4rTxARxurhRTBQ3iXniJ+I34nHzdvMa8Yh4TawVL4hPWN8XcdYPxDqpxCppyyzxL9lH 9hNfyd3l96SQE+WpcoR5P8i35Blyphwli+RN8hTzZpBpsl6ullfIddKT15g3gJSaN4D80rwB5Dbz BpBfmTeA/Nq8AWSueQPIPP1+Cnm79XHgHHlHYErgSmUHrg5cq/YLzA78VO1v3jpxgD3OHqcOtI+x 89RB9kn2SWqYfbIdVcPtfPtMNco+1z5XjbbPt69UY8x7JSbZ19ll6jT7Tvt3aqZ9j71eXaHfFqGe s1vsFvW83WpvUlX6nRHqRf3OCFXtWI6lXnZY1CuO6+ynljmDncNVvTPSGak26LdIqGb9FgnVot8i ob5wJjgnqy/1+yPUV86FzoVW2Jnm/N7Kch5wHrAmOfOdhdYp5l0Sk51HnEesfOdRp9I60/m784R1 tvOk86RVYN4rMcV5xnnWOs+8V6LQvFfiAucV5xXrQudV523rIqfWWW1dat4l8SPnM2eDdZ3T4rRZ s81bJH5m3iJxazAczLbmBfsFd7PKzPsj7tTvj7Dm6/dHWAuC3w0WWn/Rb46w3tJvjrBWBouCl1ur glcFr7IagtcEr7E+1O+PsD4K3hq81Wp0z3PPt9bq9yNYn+j3I1hx/X4E6zP9fgRrnXub+ytrg3u7 W2ZtdO90f2t97pa75dYX7mPuY1ab+4T7hPWl+5T7lLVZvw3B+spd6i61PP02hIDQb0MIKP02hEAg nBseFbDDo8NHB4LhY8PHBvqGTwxPCPQLTwyfFugfPj18emCvcH74zMDeQsnP0eCAOErYrJZwWG0R ZN1T9GINipBZ9X+WwqxZrL1Zs83a18yr7ca2L8f7sfZnbzeu3Z11b3OHbk+xB+u+bPdkvD6A9Wgx kHV/sRfr94i1tzhW7MN6HLH2FQeI/Vj1c3xDkSpHHIoMh4nDkeoIMZI0viW+y5EjSSUsxomTyHeC OBlZJrL2xRYnkb+2xt2wxnzyPxOfYk9xAWtQTBUXkcM0cQmSTBczSOMycTWSXCOKkeHHWO0B+DWz yf2nrP2x5hu59ibWg8XNrCPF/7AeIn7GOkKUsuaIW1gPFbeyHiZ+znqw+AXrCGx/DmOFX7IOF7ex jhC/Er/m7FzYYSTs8BsxWtzBqr8/Uia+I/6XdYS4k3Ws+C3rd8VdrKeL37GOFeWsR4q7xXxSeFAs IN+HxJ+Q5M+sQ8VfWEeIRTBODozzFJI8LZYQ8x/iRY5Xi5eQ5J/iZSR5hXWEWMY6FGaqIfyaeIuY b8NJI8Uq1hxRLz5Eto/grDGGs44wnPUdsU58TvxN4ktk2yw8MRa+UuJIWMwWI6UjHSElRoNO9ZK9 RECGZEjsIV3pCkeGZVj0klnwnQvf9RG9ZV+J9sh+cF8/uA99kf1lf+Kzir3knhK9kQPkALGPHCgH iv3kXnIvMUjuLfcWg+U+ch8xTu4r9xXHyP3kfmK8HCQHiSFysBwsDpT7y0OR5DA5jHyHy5FI8i2p vzoySh7FkYj8HjJMlJOQ4RR5CjKcKk9FBjiX3zPkWUhytpxK/AvlhcS/SMaQ4WJ5KTLMkDORoUhe iww/kteR+/VyFvnOljeSb4ks4dqb5E1ce6+soE7uk/eJQ+Xv5f3iYPmA/IMYIefLB8UwuUA+JIbL hfJhjtTLejFRNsgPxfHyI7ma8Dq5TkyS6+V6capskk3iFLlBbhCnyWbZzPGNciPHW2QLx/8l/8Xx Vmx4otwkN4kT5RfyCzFBtsk2cZL8Un4pTpab5WaOfyW/4ni7bOe4Jz1xMv2HEicoS1kiTwVUgLCt bMKOcggHVZAwvYvI1b2LGKV7F8L0LoTpXQjTu4hRuncRUetjq0UcZf3L2iyC1ldWu8iyvIAt9gw4 gbAY+H/MfQl4FUXW9um63dW362YDQliSQMISAgQIJOwJhBC2yCYgsgmIqIiIqICIiAyDG+Mgot7u u6p8yKiDiOgg4obo+DPAIMMg4o7sKqKgMqhIvrdOAFFcAPWb//aTom71qaWrq85538upKjPBTKQs M8mshniqmUb1zBpmPWpo1jebUK7Z1MyjZmYzs4DyzUKzPbU0O5gdkVJkdkG81CyjdmY3sz8Z5vnm EJKwYRdTdXOMeTnVMMeZV1Bdc7x5NeKTzGspG7ZtMhWbU8wp1Nacak6lOnp3JZQ2y5xFzbW1I5+2 dpQGa9cFYanVlRKsMqsM8W5WN7Kt7lZ3crQVpM6wguW4e54F3WL1tnoj3sfqQ6l6TybI97P6IaW/ 1Z9qa0tJxdpSUgNYyosQjrRGUgdrlDWKkvQuTdTUuti6GPEx1hjEL7EuoY7WWGssSrjUuhSlXWaN pyzrSmsC0q+yrkJLJlpXU8CaZE1C7ddY10JmsjUZJU+xpqDkqdZU3J1uTUd7brRmINdN1kzkutma hTL/YM2G/B+tOZRh3WLdipJvs27Ds99u3Y67d1h3oCVzrblI+ZP1J5R5p3UnSviz9WeUMM+6G3kX WAuonnWPdQ/S77XuJcu6z7qPqlpBK4gn9SwPeUNWCCWHrTBkIlYEeeNWHDXeb92PvA9YDyD9Qet/ ILnIWoQSHrIeQcmPWksh+bj1OPp5mbUMT/GE9TRatdJahSd91noBtbxovYSUNdbf8XSvWv9ArnXW evTzBus1lL/J2kJF1uvWNrTkTetdtOE96328r+3WB9TF2mHtpK7WLmsX2rDb2oun22d9iDI/sj5C CR9bH6OE/dZ+lP+J9QlqPGAdgMyn1qeoBTiG8jWOQXjYOkzNrP9Y/0H8iHWEGmtMQ3ofLKKmUHgG 5WtkQ201sqEOQDYKYUAm4G6iTKSGMkkmUTOZLJMhmSJTEa8uqyOeJmvgbk1Zk3JlLVmbmsh0mU55 MkNm4m5dWRclZMkslJYts3G3nmwA+YYyB/KNZC7KaSybQLKpzKPWsplsjhRgKcgUyALkKpSFiLeR 7SHTQXagdhpXId5L9oJ8uSxHygA5ADID5QVIHywHU468UA5HOSPkKNQC1EWNgbouQe16L+mG8gp5 Je5OkBPRzqvltYhfJ29A+nR5M0qYJf+IkufI26mNvEPeiT75s7wbMgvkPajrXnkftZdB6dL50pOw cTIkI2hnVEZRQkzGIB+XccjcL+/H3QfkA0h/UD5ILeRCuZCaa+SHlMUSFlD+Rf4FbXhYPowSHpGP QP5R+Sja8Jh8DOFSuZSExoVUXeNChE/LpxGulCvJlM/IZ8ivMSJ10hiRkoERV1M1vQMZZIAUqZZG ilRHI0Wqr3cgQ7hZvk6Jeh8yMvQ+ZJB8U75LdeV78n2kbJfbScoP5A5ScqfciTJ3yd2Q2Sv3Ie+H 8kOkfyI/QS0H5KeQ/0wehPwX8kvIHJb/oXR5RH6F0r6WX6Pl38pvER6Tx5C3QlaQNqomVbct26Js W9qwszY+ZNp+209VbMd2qI7e7YyEnWAnUF070U6ETJKdRBLItQql21Xtqshbw66B9Jo2cJ+dbqej hAw7CyVn2w0gmWPnkN9uZDciBXTbkpLtVnZrlN/eLqJqdrFdAskudinVsrva3VFmD/s8yrR72/1Q e397EOq9wB5MnewL7SFUYg+1h1GpPdwejnpH2COpPlDyaEhebF+Mu2PsMUi/xL4E7RlrX4paLrMv Q8mX25ej5CvsK1D7eHs8cl1pX4l6gaopX6NqhEDVVAhUPYOa2TfZN1FDe6Y9E+lA2NRMI2yqDoR9 I+Iz1AzK1zgbIXA2Um5Tt1FTdbu6nRqqO9QdiANzI7xH3QuZ+1QQMkDe1Fojb2qjkTcVauRNHTTy RspL6iWEa9QapAB/Iy/wN/ICfyME/qZ84O9WlBsoCMCiAYW3psaBNoG21DDQLtAOKe0DHah1oGOg I7UJFAWKqG2gOFBMHTRSh0yPQA/I9Az0pGaBXoFeyHte4DzKC/QO9EZKn0BfyPQL9IMMcDxKGBQY ROcHLghcAHwoxEhG82WM41MYtaccx+tVGadrRJ7CWLwbY/HujMWrMxbvyVi8nLF4b8bitRiLZzAW L2Ms7mMsnsL4OwWyGnlfAGydwqi6G6Pq7oyqqzOqLmdUXYtRdQYj6UxG0lnA0bdRNqPnZoyemzN6 LmD0nM/oWe8YPw8pGjcXAjffDfkFuNrSPbiyGUMXMobuwBi6iDF0MaPnzoyeRzN6LmH0XAr0HMOT xHFl0v30EOKLgaQzgaQfQWmP0l+BkpcASWcDSS8DVn4CVzYtpxWIPw1snU3PAF23oGeBsJszwi4A wn4RjGQ1rnx6if6O+Ku48oG7/x/athZXPtD3P5C+DlcBMPh6pG8A8i6gTbgKgL//hZTNvNfuFlyF wOJbgbzfwJVN2+gdxN8FLs8GLv8Ad3fiKgQ634Wn3k17wJH2Aql3oA+B1JvRx0DqRUDqB8CNPsVV TJ/Rl4gfBnYvZuzeGdj9KNjOt7hK6BhwfBdDb9VSagig+VLDZ/iokDF91imYPsCYPhmYHiyQcXyy kWgkIZ4C7B5g7J7M2D3A2D2ZsXuAsXsVxu7VGLunMnbvwdi9F2P38xi712Tsng7sngW8nm1ko956 Ri7ijU+ieQE0n4eSmxnNyTZaANknG62A7B0g+wKwi0KjEDW2Ntoj3gFYPwCsXwys3wmIP9koMUoo wehidEF6qVEK9N/V6Ip4mdEL8XLjPMT7GP0RDjAGIhxkXAD5weADAfCBC1HOEGMIyhlqjEB8JLhB MrjBGNwdC4YQAEOAFjMuMy6nqsY4sIUqxpVgC9WMq4yrKA2cYSKe/WpjMuJTwB9SmT/0An+4kWob M4wZ6IGbwCVqg0vcjH74AxhFOjOKADMKx5hjzEH8FiNOXfWvQceZwzBmDgOYOQxj5jCcmcNFzBxG MHMYycxhODOHi5g5jGDmMJKZwzBmDhcwc7iQmcNgZg5DmDlcwMzhQmYOg5k5DGHmMJCZwyBmDgOZ OQxi5jCQmcMgkSASqJ1IEknUXqSIFMSriqqIp4pUxNNEGuI1RA2qKzJEBklRV9RFmCNyELYQLaiG 6Cg6IhwihtBQcYm4BOFYMZYscbm4HOFEMRHhDDED4V3iLuorwiJMDcWD4kHKFYvEIuovHhGPUH3x hHgC4bPiWdx9XjyPu2vFWmqi94xFuEVsQbhNbKPzxR6xB/F94kNqLI6II9THhw810PvBUo7P8TkI lU9RI1+iL5H6+ar6qlI9X21fbYTpvnTcbeBrAPkcXw5kNC8a5evo60h1fTN8M6irb5ZvNsI5vrkI n/E9g1CzpjKwo2rgM5oX1QIvqkGZZk2wozpgR/XBZxqAI+WBIzUFF8oDU8oHU2qG9ObgS23Al1oj 3sZsh3h7cKdscCfoZrMjGFQnMKhixDuZJYiXmqVUYnYFm+oCNtUNbKo7OJUJTnU+BcwBYFZ+c6g5 lBLNYeYwpAw3h1OyOQJcS4FrXYL4WPMyxC8H70oG7xpHqeYVYF9pYF9XIj7BnIj41WBiqWBik8D0 rgEfq818rDvzsSLmY9XMGeZMlK9ZWT6zsmZWZ6szULjmYCnMvpKsHlYPxDUH68mMKwmMqx9SNMvq bl1oXUjVrSHWEKrFjCuD2VQZ86gU5lHVmUeVMY/yMY+qZFApzJpSrBusG1CmZk1lzJRSmCNVZy6U wVyojFlQCrOgWsyCypgFpTD/6c7MpzoznzIrakVRWsyK4a5mPrWY+ZQx50lhhpPCHCaFeUs35i3d mbdUZ97Sk3lLOfOW3sxbajFvyWBmkgFO8gUYzpfWl5TNnKQNc5Js62vrayqwvrG+obbMTAqsCquC CrXxp2zmJ1nMT4qkJS0qYZZSyiwlGywlQAUyAVylkLlKHeYqLZmrtAFXSaFiWQWMpRO4Sk3crSVr AYXXBldpwVylgLlKNnOVVsxVspmrtABXqYcy64Ox1GHGkseMpSUzljbMWFoyY+nEjKVAtpQtkVfz llLmLZmytcSoZvbShtlLF9lRdoRkkSxCycWyGE/UWXaBTKksBQfoKrsibzfZDSk9ZU+EmucUMs8p YZ6TyTwni3lOHvOcbOY5eXK0HI24ZjvNmO20YLZTALZzBbjEeDke5VwJ5tMSzOdapGvOUwjOcxPa NhPMpy2Yzx+QMlvOhswfwYIKwYJuQatulbdRR3k7GFEHZkRFYER3oVfngxd1Yl5UwryoM/Oi0cyL SpgXlTIvKmBeVMS8qDPzoi7MizLBixaitZoRZcqH5EP6TBgwogJmRKXMiErkErkELXlcPk4BuVwu Byd5Uj5JDnOhZLlKrkKoWVAPZkEB+aJ8kVLBgtYgXfOfanKdXIeU9XI91WQulA4utAmSm+VmhFvk FoSVjOgN+QbYkeZFinlR6im8SIAXfYAyd5xkRwlgR7uQshscSYEj7UU5lRzpI/kR4popBU4ypc/A 1g6CLwXkIfk5atGsSTFrSmDWlCq/kd8gflQehYxmTenHWRPZRAHmToq5U81TuFMys6ZqpzClgJ1i pyBdM6WapzClADMlxUwpAKZUDxypPvhSwG5oN0Rcs6bAcdaUazdGvIndhBLspnYzxFvYLRDPB4MK MINSYFDdEdfcqQpzp2rMnVKZO/Vg7tSLudN5zJ1qMndKt0fZo5BLM6hqzKB6MYOqeZxBXQ6+FGC+ lG5fZV+F+ER7ImXZk+xrwbKm2FMRao6UzRyp0F5lr6Ia9kH7c7C+o/ZRkv4yP/iA/xX/WzTU/7b/ K7KcS5xLSDoTnAkIVzorKdd5wXkB4UvOS9TfWeOsofrOemc9NXQ2Of+ivs4eZy/S9zv7kfKp8ykk DzoHwbIAlqiJspRF5ytHOVSgaqga1FjVVXURZqls3G2imuJunmqGeCvVCmGJKqF6qkyVUY7qrrpT I9VL9aJ+qlyVI32gGkgN9L7T1Eddoi6FzER1Ne5OVpORPlVNRcr16nrkukHdgBTNBrPVTeCB2Wq2 mo1wjroFoWaDxWCA8xDepcAy1ALwwGwwQI/aMgPsoBarv1CpWqaWIf1vagXCZ9SzCJ9TL1KRWq1W gzG+rF6mrmq9Wo/0rWorwp1qJ8rcq/ZSidqn9lFn9aH6kEqZGRYzM8wKFAYKKZt5YAfmgUXMAIuY AWYxA8xmBtgsUB4oR/w8MMACZoCFzADbBvoH+iM+MDCQSpgHjmYeWBoYHBhMmYELA0OR66LARdQy MDowmor1ftfUJOFwwmFqone9ppxEK9GiHBLp+Xrv68y19bZSO7CF/w8+FfsrfeXOdR/qyl0rfpDG /jbf22367orFFVNO7DZ9Svqhitcrbjm3uit2V9xyWmLjijf4f5J3nvT5KWCvd71aXO/Uotc4HF/r 89/ZmQW1p/Jzn2vtqefqb3auXlA/KGXRGcjsZy9U/XfcD7Nir96z7MxLOPfPd095wmu7wvs96/v5 T8UU+j/aLeeHO3QhZZzeVYbfxjm3gOfL0tNSK/25TngcLzrVD6VyTlakVvTkf3uey9uuGFExggZU FOv8P7hTwGH4RJsqGn/Pk1z9ku/L2fUEv72f26/8tD7/LWv/Qd6f9Gg+o08qNM4HP3wWraF537k3 f2aFw6/6VGSfqOc3K/GMPSGPvXlMP9+gU33dtZ/jsQPsg3qd9k09rfSs7+ROpt12ssSz1KBno+N/ Yy2h3/f+Hxu7lSu7fziafm3t33/Dv+X7PoO6N55q2TCWT/1WfjL2Gq8Q+o1bVnH3qeODU277Kdnf +oMnKsc4PjkfKg5URL8/O070xG9j+U+r/006dUewvWfWu/wWnvuZ+6dhh5+Q26RX+5389i8Of2Hv nEoUUvHcT62LOB07/EJ5Z3G6R8WwH6vru3p+cbXJoONyutebal9q7UV/oscrHsdfDV7veTf02mvf f+OwkpnHY3o9ymsVzRgja7lK7J9y5s/xm3+u+yUBzOjfS5+c8c4Nx87qLJozKvEX1+Z8fzdrTvk/ 2innF2beD1pe8cJZln5in/MzWtnxk6X8V1YEVtoTsMuzHg/HjvyqenmWaGtT+e+vWRf1I6WfFfr7 qZ2pfnzUnLK32Tm871M08mu/jxX7mbq5t0/YGOjbXzVeTyv9DPr85Jr44/sJ/IjEuz+mGyt/0+G/ c2zz8Wc/B81bMejcajye+8Cvyf3rP8d3tD6DPZuOW87v7HflHh116aSlPstP0++V/iMrLn6vz9nr srMq/Xdillz2aeP8BP8//TeL36jGk/uW/+IvDaN/8P2Nyt8TzqnWM/499bu6NfM+MRf5V9bFP0Sg dHxf4Z//hea031MHnfp76hm0ffkvy/xk3mXnmK9yNKSi7St/bB010vXb+NkV1kDKN7PVufls+FPF dRVvHru78neCioj+9h0jPKa5YuuK634MCZxI+/HVecdO/537LD6nWOD1v6xXju/K8bMrdM+i7u/s 9++H4n/nz4+dVfC713lCr/2qN/8r2/Dyf6HSE2d8VPa5oInst0SirsgiQ5+rTT72XjL1idpkiTyR d9yTydbnapNftBcdSYkyUUaJoo/oQ0min+hHyWKgGEgp7OdURQwXw6mqGCXGUjVxuRhHtfS52pTO 3k4Z+kRtyhSTxWSqI64X11NdMV1Mpyx9ujZl69O1qT77QuWIBWIBNRL3inspV5+0TY31SdvURDwg FlJTsUg8RM3Fw+IRyhd/FY9RK/G4eJxai7+Jv1EbsUo8R23FC+IF6iBeFi9TR/GqeJWKxFqxjor1 edtUwr5TXcS/xVYqFdvEm9RdvCPepZ7iffEBlYudYif1EfvEx9RXHBCHaAB7U10ovhHf0BDxraig ofqkbRrBnlUX+fy+AI30JfqSaIyviq8qjfWl+tLoMl9NX026wpfpq0PjffV9DWmCr5GvEV1t/83+ G02yn7ZX0TX69GWaok9fpqn63GW6Xp+7TNP0uct0g73X/oZu8lv+BFqgz12msP+P/hD91f+o/zNa o89dNhx97rJRRZ+7bOQ6S53HjZb6xGWjQJ+4bBTqE5eN1vrEZaOjPnHZKNYnLhtd9InLRld94rLR T5+4bFzkfO58aYx0/uMcMy5WhhLGFcpSCcaV+pRl4zqVqtKN6/Upy8bNqpHKM25VbVR74059srIx X5+sbHj6ZGUjrE9WNuL6ZGXjATVEDTcWqZFqlMEnKxuPqmlqmrEyYUfCbuMZ/b+5xvMJxxKOGS/p /8011mBcvsHjUrA/nRBZGJ0mj85K3zrBo1Py6HR4dCqMzkKkt8YYNTFG2+Nuh5MjtZBHalMeqW14 pLblkdqaR2ohRuoo3B0txiBd++i1Zh89g330DDEOI9jHI7jSX8/gEWzxCPbzCM7jEWyzH58hbsI4 9mEc/wEyszGa83g0N+fRnMyjuQqP5mo8mmtgND+AuaQ9/mqJhRjZLdnvL188hPGdrs+TR6h9AKtj lP8V4RKM9Ro81pN5rFfRZ8ujtGcx4qvziG/JI74Oj/gs9hOsp8+ZpwKxDqO/CY/++jz6G+rT5hFq /8G64nXxOmbdVsyHXPYlbCXexKxopE+hR/gu5kY25sb7CLdjhjTkGZLFnob1xEeYJ431ifQo+VPx GTUQB8VBtOEQZk4uz5xmPHOSMHO+haY4Jo5BR1RgFmXyLKrKsygNs8hPAfZSTGAvxZq+AOZVBvsq tvAlYXbV1qfZI9R+i6mYY6kIq2OmpfFMS+KZlqJPtkeZDTDfUnm+ZfB8k5hvTyNciVmneNY15VnX lGedxbPOwqx7B+G7mHt5PPcEzz0Tc6+IpL/YX0yOvxPmoeJ5WIh5+AQ19S/3P0lt/E/5X6a27IHS 2v825qeh5yf5MD/bkOW0ddqR32nvdKM8PVdJ6NPRKd153HmcqusZS8l6xlI1zNiVCJ9xnsHdVc4q pD/vPE+J7L1Si71X8p01ziu4u9ZZi/Afzj8gv955DXHtydLc2ez8m6o4W5zXqYaz1dmKu2877yH+ vvMBtXR2ODsgudPZiZJ3ObsQ3+3sRlz7v+Q7+5x9SIFGQAmfO59TtvOF8wU1dL50vqQsfR47FThH nCPUxPnKOUr1nW+db6mRc8w5RlnQGgbV1ee0Uw77y7RSUvmpEXvN1FFKBaiePrmdCrROQXqqqo70 NFUD6TVVLWqoaqvauJuu0qkJdE09pNRXDSkXGqcRys9VucjVWDVGXHvctFJ5Ko8a65PeqbZqq9pS qmqn2lFAtVftKQm6qSNVVUWqiDJVsSpBvIvqAslSVYq73VQ3SmDfnJrsm9NClaveuNtf9Ud4vjof 8tBiiGs/nWZqmBpOKdBlI5E+So1CmZeoyyhNXa6uoAw1Xo2H5JXqSpQ8QU1A/Cp1FeLar6eFmqQm IQW6j1Kg+3ZQbsLOhN1UAxrwIOKHEtDDWg+SrZc6UEaikeijNBLoUO0j3YZ9pJuxj3Qb9pFuyz7S 7dlHuh37SHdgH+m27CPdnn2k27GPdAf2kW7DPtIt2Ue6gH2kW7GPdCH7SLdkH+kC9pFuxT7Shewj 3Zx9pFuwj3Rz9pFuwT7SzdlHugX7P/u/p69P19SVCEL7QtuiWBRDd5SKUugOrZ3zRQ/RAzpF6+j6 rKOLWEcXH9fRQ8VQyA8TwyCv9XW+GCFGQP4iMRJ6R+vu+qy7i7+nuy8Vl0ILn6rBx4vxJ/X4BHEV 4pXa/GoxCfFKnX4ddLqPdXoDcaO4EbbkVJ1+s5j1Pc3eQMwRcyCj9XsjcZ+4j9LYfzuJNXsV1uxV WLNXY83ehDV7Y7FYLIZl0jo9gf26E8RysRyS2rs7ib27q7EebyL+Dg2ezho8kzV4nlgP3Z0uNoqN sBaviU2Iaz2eKTaLzYhrPZ7JerwO6/G6rMebsh5PF2+Jt2A53oY2T2dtXlu8B22eLj6ANk+HNocW ELvFbqrJPuSZrNkzxCfQ6emszWuyNq8rPhefI0Xr9BzxFXR6Muv0ZNbp1X3oIkpmn/NEn+mzENea PcVnQ7Mns2ZPYc1elTV7Kmv2XNbsyT5c5PhSoN+TWb8HfNWg35N9adDvydDvtRBqT/UAe6qn+Or4 6iJF6/pk9lpP9DWExk9m3/WqrPdT2YO9I3uw++3mdnPy2U/ZT8EGrLBXINQ+hLa9zl5H9e0N9gaE 2+w3of3ftt8+bgMa2Nvt7ci1096JcI+9B6H2ORTscyjY59D2j/FPp4b+G/2zKYutQr4/7A9Ttj/i X0T1/A/5H0J8sf8RxLW1qM/WooitRfFJa/EVW4vm37MWPrYWDZzuzhgy2ZtRsDejYDuRxj6N1Zzn nOegqbVtqMa2oTF7NiY4L8NCKLYNaezlmORsdDYiRVuIRmwV0mAV3kVebRWasFVQbAMasw9kknPA OYC72hOyGntCJjmHnEOwDYedwwi1JciDDfga8aOwBLVhCSoonb0lM9kG1GEb0BQ2QCJuwxLUYO2f pxJVIiSTVBLVUskqBfEqsAc12K8yg21AnspUdZCufSwz2Mcyky1BXZWjciDZCJYgnW1AU/a6zFT5 Kh+ltVQtka49MDNVgSpAva1Va6RrC5HMtiFZdVAdEGrbUB1WoRPi2lczANvQFXHtsZnCVqEqW4Vc 9tgMqPNgGxzVR/WBjLYQyWwhqqsBagDi2p8zUQ1SFyA+GDbDYZuRo4bDZiSzzaiuLlZjENfenils M1LZZjiwGROQru1ELvt/JqopagpStBdoCnuBVmUv0ESNmqlKwt6EvQi1J2Qme0JmsidkCntCpiQW JRZRemJxYjElk2G+Yq4jgxKoql4gdZ8nhrhN3GHuTHezV+aNcKPeAneb96i33TvkCW9caEhorLsr NMnNd/u6o92ZXhJSx0BqFiSOhUx8GxG5MxKPrIhsjByJ1os2j3aPjo3Ojs6LrI0uj74Q3Rr9Iro1 VjXWIJYf3REbFBsW2RMbHZuAPB7ybEGeAdHx0RnRcPQB/L0T3VcpGX0h8lb0i9jM8KDwsNDi8Ojw ZeEJbinaEg3PDM8Jz3WHhee7+aHbcSeo648tjD0cORKbEO0eewr1z4vcqWuPrUbdG9CClFh+bFvs PdS9K/aR2yQUDheF33Nnhj9yF4aPRvzhvpGsSI4bjZTh6Ye5RXjisaHloSWRybimu30js0L7vDsj t4a3RQZ72yO1I61Cy9EHnVDzMq67NHIknhNZG28XL4uPQc3dK+uNrEC9NeMbUW9CfEt8e3xPfH/8 UPSVaPh+834Vz4o/CokGur/ik+Oz4ssgtSa6Nb4WZQuUUOQdieW7DSD/SnSdV9udgPdz2FvkjfDu dBd6R0Lj8V5edVd5K9z57mY36gbxfaY3Am+llXere5m3Hd8/c+d47fCWlrm7ILnHbeMdCk0K9Xan uRvco6HbI49GlsWmRdZGnou8Fdke2RM10fcK77Ew2iE6NTopem90Jb/FAzGK1cEb0j2ZH+sb6xm7 DL2dFs2IXRs5FF0S3YQ3vzWyPzoyJvHmX4kuxjs+ElkQWROtF2sTLYksQh/dGTkWvT2WEKuJETAn Njc2PxaM9o41QW2Lo1/jLfWOzkOutdHc6BC0b74bdHd5qV6WN5jH5aNhibbXC5WEOoQGuE+Fo+GF 4aXhpzAC5ngrwg/rv/AqjI9p4dXha9GWFZG1scPRMN77wtirsaOxVXER98c2h0fHorGlsc8iIjQg 0j+8IfyqHgWRpPA0b0wkJ9IuUh7phJFe5I3ToyAyLjIR93aFd4WWYJTkRHIwKrIwF+a7T6GuovBm jMml4c/ChyOpkbzIiMgYNxjuG+8UPxaPx1PjSfG8aBhjon98cHxEtHv81rgXvzOyIr4IPTA6sif+ HEbFW/Ej8QXxBdGx8fL4OPRB7/iW6PKIh/eQhn7PiNeO7InsuT/l/rR4q2hJfGJ8erR5fEVUxcdh nJa6PdHWuWjNQvdhd6nXzt0WeiE0wxOhTei1coyFr8MUmu29hWuFt8bbGK6KebsllBIaGW6CcTAJ T3FtKOxGQ6+E1nmdQvtCGaE0z+/5Q/NC97qDQg+EFoeWYCasdINeXuid0I7QgdAXoa9DX7vDvMne RG+6d2u4DUZeNBQOTQ0nhGviXm6oubsr3CCc772FtKLQvHAp5lvPcN9QodffG+fFvee8td7+kPKe c99zPwpt9XI8L1wn1B16BxrIW8DaZxxmoNY6pdBMQTzdfHeaJ9zVkbLYBugtw/yKBD3Ia2+J968x eOcawatufXQXRcmkxfQXaLnHcKXSSlzVeQVrGq9XrUGv46pJ7+GqxXvE1Ka9uNLpY1wZ9AmuTPoP rjq8erSuIY26lGU0NpoAP+cb+VTE6zSLjY5GR+rEazA784rLEqOf0Y9KjfONAdTVGGWMom6860p3 Y5wxjnoYE4wJ1NOYakylXsZsYw6VG48Zj1EfRsJ9RYkooX6Mh/szHj4feLgnDRDl4jwaBFQ8iAYL XDSS8fAo4NsbaTQz/GnAh+vpBvD5rTQLSG8HzRW7gOLuA37bS0Hm4R6jtbD4UhymiDjiI4oBzteg xb5avgx6zlcXCGq1L9uXTS8BQeXQGl+uryn93Sw0C+kfZpFZROvMMeYYWm+ON8fTBnOKOZX+aU4z p9Fr5gzzZtrE67m28Equ162vrW9oK+8rsQ0UwUdvSUs69A7vFvEBr73aITNkBu2ULWQL2sWrpXbz Oqk9skh2or2yRHajj2QPWU6fyT6yD30hb5W30pdykXyIDsuH5SY6olfuGNl65Y5RT6/KMerrlThG A70Gx2ioV98YOXK/3G800jsRGLnyqDxmNNbraIw8W9ppRjO7qd3U6GT3snsZne2x9lVGiX21fbVR bl9nTzbOs6+3rzf62DfY042+9gx7ltHf/qN9u3GB/bL9ijHcftX+p3GR/Zq9ybjU3mxvNi63t9hb jHH2G/a7xhXAinuMSf55/nnG9f6D/oPGNCfNSTNucIY5w4zpwE5fGzc6R5XfmKOZsHE3UFBV4x6w 3zQjBPZb0wirDJVhRIB2soyoZrxGDFy3qRFXzVV/40EgjQuNV8BChxnr1Ag1wlivRqvRxgY1Vo01 /qmZp7ERnPM24zU1V801PlLz1D3Gx+o+dZ9xULkqahxS96v7jSNqofof4yv1kHrY+EYtUUuMCrVU PSFIPameEqbeI0BI9aJ6Udjq72q38Ku96iPRWO1Xh0QzvfpDFAbaBDqJ1oGSQInoFCgNdBed9foO URboEzhfdAsMDFwoygNDAyNEv8DIwEgxMDA6cLEYBGRSjLFsiAFgWhqT1COL6M/mD/+MGsFpwbnB YPBhhPrfw3cNcUVwrpvq5s2LB6PuGPzd6npu3F3mrnHXuhvdLfODyDMHssgxv2h+ket3U3WO4GrI eu4iSLbD9+nuIV32ggHuEcih5ODqu4Ygz0xdspcWjKKmMcENbtzL9QrdjV4HryQ4zT3mmZ7yMrzm XnduGfJ7U4NzvRnBV1HCYe8BNw//VuYNIu8m7x20KdXb533hfR2ikMSVgL+ayPeC19v19PN4DyDn C5BaF1ztrkErl+F5ynCVB+ejpfuDC4NRtHFpcGlwldsfzzE3uCv4EfrhMO62Qj+sdge7E90F7nbd XlzPoYQt7lvBzcFt7p7gU8Gn0F+pbie3E3olqr8HjwaPupODr6KOEfN1T01DrbXdR4OfocQVwZkI k9xZ7p3uluBhN8vNcce5t+raILsw+B7kdYmduJzVwaA3wOvtDfFy0Q/1vJFeijfWG4/+noanKjke Hnb3e8t1f1X2lHevN88L6x5zJ3tLUMJKd4u3Fb38CnrqQEh6i73FeBuHdc8g3IdenROqiudZ7U1C 2zZ6O0J1QnW82d7tLBH0XsCdB+4aAjtgmWvNtUTmOo12zQ3mBhLmRnMj+cxN5ibYBkGdEWpPvUaU C93fHFcG5ePKpPa46uB+Z6pLPakXZVEfXPWoH/Wn+nQRroa891oOXYarEY3HlUuTcTWmWTSbmhhL jCXUTGSIttRctBcdqFwUiSLqLe4SLjR9SCyFFl8mnqQJYoVYQZPESrGSrgHjf56uFS+KNTTFlKak G8wkM4mm82rjG80bzBtphtXRGkM3WxOtifQX6xrrGnrYmmxNoUes660b6K+8G9JS6w7rT/Q473q0 3LrHup+etJ6ynqLV1j7rIL0k/yX/Revlv+W/aYN8Xb5O/5T75D7aKD+WH9Nr9pP2StpkP2u/RFuZ 0b7rz/Jn0Xv+of6h9D5zze3OTGcmfeDMd+bTDmeps5Z2Ouuc1+iYs9nZbJjOFmeLYTnbnG2GdN5x 3jFs/bui4Xd2OwcNJ7FjYkcjDTO+u+jLMz4Nb4L+l72vD4sjK/c8VV3dnbQMIsNGRMTcXC7LMBEx IoMZBhEZBiOyiMgwMUuQgabDkKap7ks61dVN011f/d10d1Uwg4gMYsSIiFzEyI2RBzGDmchEBmPE yI0R2YgxcrkxizG776lx1/vsH/vfftz7TM5zgNP1njrnvB+nfu/vOan2peJKvFMuDV+QG8JIdstD 8rg8E6DjmfINeUN+pFBKrlIJtTE+FZ9VDoQXFYvSo7ChYblUrpAb5BbZHRwI0PKKvBG+L2+BZOGb kgolt4TrlbB67w1lWHZDn5kwAtkb0BfuHLgJ0stKpRwD+dVEDdz3lrIplypjyqxyUVlS1pRduTSY rPanZPeZJDl4Jju4faZAfiTP/KVvQ3w2mHFGUXrOjMg3MBYDZHXhzCXA51dAUgd4lo5P4fUAooFs SwbMruSeyVPylVYYNTNQoxyQa2EMl3xMXY0pmCwLSq4cxJoIZshX8XxDPaoeDivVSpMi4fnGZ8O0 0qF4YE0DUEZls2yTtwPXFYOSIk9Cf9y+LM/7Z+UgjFEGcm5YdUP4PvSdko/AqKWyO56p1IUkhZVn 4A6jwQylUZ6T10H2mDwaQDIjP1D2yUyQhPs1qPM7pqzKQ0quf0dZ8A+fQcEtJaGcV+4qZ5UpZUde P3NJ6Qlkh6fPpMpBZexMgZJ5pkieA6TaecaINaWwCguo0R8qC9QEt5UFZSFAQxZacqb+TA1or0qu gJEGlNxAdiA7tAs6vQT5TfqZLPkyzKP0DCcHYdXL4D8kRPbyW7H8/zaWda177DiWiSl0AsB45Vv1 /+9KNvKHRDomxabiKJ7Kl8bzfAnxSrw5TseW+fX4udguXxwb4w/FelSpVV8ing5SCEvE7bHleKrv bGI+seK/lngkH0hclcvkOrkjIMg9/sGQTk7I5+VEYCaYK69Ca1O+K+/IuwqCPnOJlcQG9KkE+VaQ TpV7QHr4TcmQLrEhX/TfE4v602KzIpfI8SX4bbGZL00c5Bt8icShRDE/Hl8U6UQpHl8pCMwkHilI LgslyXUBwXcWj64UyYlQOsxgn7yqlPjW5B3/iFLOH4qWJDKElJiUaInkhucSNrGgnxQkvrQ/LZ4H dxRgxbuJWDwrAZAkMZQY9YUT44nJxIw4zRfHm8UCQUrE+FK+GEa+isdWjDB2p5ziv4Lxn38QdKCO m1iBcQGfyTvKSGAPoKJLymJgCz4BDBZKV5rl1cQKrBf0pfihz6oyIq/KCWWaL40twx10cVpe5Q/J Ei6x1ZhHKo5ei+eBxvPjnXEa2yV2PjYWvxBLxKbAJtPQluKpYLmdeJFIx5uhvRCThDVfor8BpJfi Rv4QXB2Lj0jj0lVxOr6YuJy4qqQm1hM3wBZbgRyZks9CQnBAzpcL5Sa50X9b9qhWHJNn5UJFhzUJ 5RZ8Blb0Z8mZSlLiQWJLDoPlE4ltuTpgllNkKbGioMQj0M+KzIL84cB+eQ1aj2SLvCAvQd90JUvJ VvJg1csy69uRpwIzcllAgF7rcq4/TxqHNSVgzmuxW/Ek7JfiFdA9LZkid2MGEVYWzUpUxCyJI+HL fEPsLPwNNVHLl0ZvJhrid2AuK7AqqEqJUuDbUar8g/4JpSawLnK+s3KZUp4wi80JW/xabAp7QcKW YKL3wK7u/jQp9qYPqF4QjGeJVYljUGzY7oIUz+onYz0wuzHwxQzovwtSpoQJX43fSQixhFig0KEs JVWp909jrwCfcAU2FA5GxUh5EHuFvAtlRzkX2CMvKVcCW4EtuQ77DuijLLDHP5iYU0pAuwnwraMQ MTvgGzeVKihRuH4Q+hsUv0j7EjELRGU4lojkRnJjw9jS0ZLYMETlTdAajufx+MP4pfhRKCXxqng9 tJvj9aHF+ISUBt4BhR+HHmfj1wUpthu/F/fHudCd0B1xMH4lxoqD0ZLwZYGNX4O7343fjt+J34/s xpqiWeA7WTgi49lSDkRCadSVIEGfe/hxsSoehXhJTqTFayJ3ExniYH8aXN0vFsSVuC56HfyzPF4j ZcRd4LezsYvCWmwzXgC7yiBUmDFEIOw+YhXoFXYdWKGEVxdLgEcsx8b600Lp8IRvJCaJSYSIaWIa EcQsMYtIYo6YQxri+8T3EUX8gPgB0hKvEq8iHfEa8RrSE68Tr6M9xBvEG2gv8TPiZ8hArBPr6G2k QAooiZRICT2mydfko2TNqmYVvV1zXXMdpWhuaG6gd2jWNGsoVXNTcxM9rlnXrKM0zS3NLfQfNLc1 t9E+zYZmA72Tepl6GaVTX6C+gN5FfZH6IsqgvkR9Cb2beoV6BWVSX6a+jN5DfZX6KsqivkZ9Db2X +ib1TbSfeoN6A/0N9VPqp+gA9TPqZ+hvqZ9TP0fZ1C+oX6C/o35J/RLlULep2+g/UhvUBsqlNqlN 9AT1O+p3KI/6PfV79CT1B+oP6CD1R+qP6H3Un6k/o3ytQWtA79cmaZNQgTZZm4w+oE3RpqBD2lRt KvqgNk2bhgq1+7T70Ie06dp0VKTN0Gagp7SZ2kxUrM3SZqEPa/dr96PD2gPaA+hpbbY2G5Voc7Q5 6BntE9onUKn2Se2T6CPa92nfh8q079e+H31U+wHtB1C59oPaD6KPaT+k/RCq0BZri9Gzer/ejyr1 QX0QPacP68OoSh/VR9HH9TF9HB3Ry3oZVevP6AE36T+v/zyq0b+sfxn9J/0X9F9Atfov6kfRp/Rj +m+i55NeTXoVvZj0o6Qfodak15JeQ21JP076MTImvZ70OmpP+knST5DpLf7vLf7vLf7v3wf/p+vQ 0X9lA05TuGqeCJYGjwhpbFXQHGScGcEYW+Wt9dYGJ4NzQkZwJbgBf29zC8EHUl7wUYiSOFd+sIK/ FBzwpsGVUW8tSF3mFuCTFVEK7ZPSQ7k8ZJzhm6E6z71Qk680sj9SzAxEzJFgZEAaiVyObES2I4+i VHRfeCKUC6UuVBYqi6T5SkMdIF0Kssc8I6EyJhaSQnWRAb4mMoALExML+1PxX/3ZoULHWn9qf3lk wGd2LPi2+qv6a3wN4mZ0VTKGKsVqtgSksiIDjjXnI8dCqLI/NZTitAVL8coca95aWEMstIxXKjaF VoNz3IHQrdAmtHa5BecMVxaiQndDO8FSbl9oidvnWHI+Cu2KbEjyVURbmZjvYLSDGXDeCA7BPM87 J7nzzECUjXpcmywCCSmsi4bDSb4MPHso4zCXo2KhdN87FxkI1eHZi5uONVaJDHDnHQv9RiHD19Df 2U+/OT9chIMSYi95a8N5MLvYm3MT0pzjYSO3KbTA552wGetYFKa9tZICPaCnyyKkBbfZqnBRaDdc 71oN3RLMouTa9Ix4Rni/by68GJ31jESbgrHoAjPAchGzlO5bjxrC/sijcDS65tv2bUdvRTd9xVKW MBq9C72U6I7nXrQpuhyqE+8yA5KOvfKXNWEruPyUtxR++/uzRbCHeDEy4HwA65kQbsB6pqP50fz+ C/2XQCK9f5EvigyIO84HPrN3jl3sH+wfccYca1J9qAz85wHY/LJjzbfFgI/wXKgsWBs8wha4KCGN v+TaDB4TZkDKBt4puChstSBuX3XGvLUhA7aZUOFksGcK8JMZDbYETaoPzwfnoQ+0gkNQ1kGn0WAp aGkU/DkI1x+A729JXDAWHIdyQ71zQ9DNVoX2QTkAvnw4csRXHBFCTaHW0PmICTyg1pkcNYDvXpdQ KN9XKtaFL4Gv50dTnA/4qGiIxKR0KYv3u5qiBu48ez10UTgiFYUy4X7g6dJIqAe8qzHUBLosECrC 9337paTIQDThTA7WhiqlpOguf62/gInx1/uT+tMdraC9PPD1Il9LZMCVK6WKrexN3xb2dGeOVO+b 7EdBU2QA9FAYnGdib7aCQ/0l/TqnOVTnvOx1g0V0QbPjFoxeJG721/OLETJcAnZwO+rw/cFqyYIt fD+UyRbgeAxfcg6FqkPV4TtwlYzskbIiB8E+aWEX7xe2I1vhK8IxIQ3bxkU5Z7y1/BXhSGgtjLy1 vgrnHljJjejZ8GDUw0547uEK0TAc7QmnRi3h9HCWY42vcSbj2m+E/aBTyutv7rfDnEvBz3eiHeBp hTgScOt/xAJYZcs5Dl5fDrVGypPyws0OuBquwhYLlwQrwnaBAX/PCbvCXDg7XICjJXw0aPOMRNIi 5uiYbw5HQTjqm3ROOrfCd8J3YKc4GjocPR9WwhNgwSvMgLA/PBgeiU5FL0aXHJRvwzkE0VqJq+RS /T2Lh4gVLzozxE1x0xcMu8Tz0j3vnGTsN/ZzjjVhxTPRf0UY6o/2K84b/eeYmCs3fE6qYq/A/S+F F8OLQVuoWkqNZobCoTpfccgSYiOHhKvRsuiB0Fmp01UZGYqMRsZhzjORB74B51D4WmiYTQ2NhS+E FjwjTjP0zY9kwJ4ThoKvFIYKI/OROdg5m0KzoanwQ8nFNYWnvcm84hnxJsOKFyPJUg1bFC2MHuar ormRWvZ+pCHS4nQzA8wA7AaV0WomyF6IXI2shDxOW7Qu2ujMCQZ5GnYBF8t5RnxMtClyA2abC7rI iVREmOCRoDkyGdkI3w7fCyXYIk80YvNVRNZDTRE3WCMaGVAZw1nqO/CUeQPwIX5/QzKgvL0oF8q7 VMYwQ+UK340+DiVT5Qrfo3KFWSpXuF/lCv9GZQkPoD4UQH+LQkhG+egMIM6nAG9+BT2DJtA3UCm6 CKUM8OZl9FEVcX5M/YaSCvRjtIyeVdHncyr6rFLR58fVdx0fISgiGVUTKYA1nyfyAGu2qyjTpOLL E8QnAF92qPjyJRVfdqr40qziyy4VWVoIL2DKbuI8YEqrylr+vcpa9pMlgCnjgCk/Afjvk2QtGiHr AEGOqQjy62SEjKEfkAnyDHpV5TRfUznNX6mc5m9UNnOTvEQuot+SlwFlbgPKvIXuY3xJJGF8STxG 3iHvEG8HlPkHIoXcIf9EPE7+WYOIdwO+fIx4r+btmncST2KUSRRilEkUY3xJfFjzhOZJokSzrFkm PoJ5UqIM86TERzHiJMox4iQ+hhEnUYERJ/EsxppEJWBNlniOclEuogq/bZX4uPZp7bPEEe1z2mri M9oabT3xWW2DtoVowewq0YV5VcKCeVWCxrwq8ff4WyKIHm1ce5Y4pR3SfpHoxbwq0afd1N4hPNot 7e8IXvt77R8JEVDsIyKqQzqSkGGCOmJAt0eXRLyMUSwxjFEs8SX8plBiBKNY4hXdId0hYhS/25P4 Mn6fJzGmq9A9S3wVf/sT8TVdte5TxNd1n9Z9mviW7nnd88S0rlXXSvwDxrXEjO4V3SjxbfzeS+I7 uq/qZonv6i7ovkf8SPd93Q+J13Wv6t4grqsY99f4LfzEBqDbLWJTxbW/xW/YJ7YA0T5G/E7/DsC1 /6Ii2j8BojUSD/Um/Qniv+lf0neRhL5bz5I6/O5EMlXv1rvJx/WcXiLTMF9Mvkv/Xf33yPfqv6// IZmtf1X/E/JJ/ap+lSzSX9f/gnwKEO1t8hl87pEsx5wy+THMKZMVmFMmn8VIl6zESJd8DiNdsgoj XfLjmGsmj2CumfwE5prJ6r3f2PtN8pP41CJZu3dm7xz5qb3f23uJbMQnFcmjexf2LpKfxWfZyaa9 r+19jTy+98d7f0w2Y1aa/BxmpckWzEqTL2JWmmzd+5u9d8i2vVt775EnAFX/C2nGZxFJGp9HJ634 JDp5Cr82nrQbNAaKPI3PH5IOwx6DgWQNjxseJ3sx5ibdGHOTfRhzkx6MuUmv4UlDPskZCgyFpIT/ dwsZwqcEyX7DM4ZyMoZPBpIDhucMVeTn8ZlA8mVDtaGGHMSnAckvYlxODmNcTn4J43JyBONy8hVD l4EmRw02g508Z2AMHvLrBs4gkTOA0QPkdw0hQ5j8R0O/QSG/ZxgwvEz+AND5l8lXDecAkb8GiPw7 5E8N3wVEflNF5OuG7xt+QP6T4YeGZXLDcA0Q+T1A5E9r3vG2Z95Wqnk3IPJKzXvw2/Y12fj9ipq/ e+zpx56BzI5AQZT4K+Y+GVXrY+p3VeXBPlgEO1gFqkZ16ChqhmzbjMi+SaEcafrG+UyhClojTCv8 HBSq4TOF3yMchlZYqIWWxO3Cb/Lk4T430pws7GO4LbhGC7lwrZO7KcCIfa38Q2g1cctCxr/alQn1 LeAIEdQytaXOLgu/w7Fz+19XspG+7KnkdywWb2rffnbpdKZQ0jXH1Av3T2fyO2Kt2MDvdG3QlwUd lhKOso2Cwi4Ji0y9uEdMA+lzUqtkkSQpIc1Ka9KmT+fL9pX4qnz1PruP8w36Lviu+2777vtJ/x7/ fn+O/6D/kL8Y+nRAn7PSrC8V5ItA2ug7CtLn3pT0cdJZ3zX/Ece4OHl6QZzpO+KdcBSLc+yS+444 L15m7OLV06uiWQyKK+r4MLI06y/26fw2uF+V1IpH97t9g/6g74K0Cvcc8A/B2KP+cfqy03XqId/I 73g6hCLxgVAijrvtjnF2yek/nemp7F6EdTdIh9lqqVKqlur65h2l3YNSk6OBTekeZOqlFCnT6WeX 2B4Y2YPH9t+AsdelZf+DAOU/AiPr/jKu5CcDicCw/2AgMzAbWAosB1YDa4Ex6VZgU+rxrwR6JMl3 H+srcDhQF2ADU4GwbzBwli4WD/pG/MkC6ILfAb34fVHhqJDuSBbqezqEc8I14Z7wUDzWtXF6gZkQ W7iYxQKaudm1ARYaFJMFWrgppDL1jP10j5DVdUQosezClRrhNr8rkl0b4hF2zUEyN0WzxMIK7oIl wmCLYWlMWvANSkugzR1p11fgywM7ulQrTvgWfff8paomSd9RfwbUYmkZ1lwhTflonyLdhZ7nfVm+ K9IyzHcars6CfiRfM8gjWG0atC76yn03fXfAA2r9Df5j/hbQ1ENfs6/Tdwl8JMlXA70k6ZYvnV3j Yt0PYc7NfbWCH/tl11zfinBfPMS2MtP8Dh0Tb4g3+orFdW5FnGctTBaup9fAMwuc5d4JmMtf/vkH wD6Cf8bP+Of88/6YOOM3+c3+SfGR1Oj028fFDXFLKOpq4Gc9Ke5y6UDfpCf8pg/wO26jlC9MSGVM EpMkUeK45RZ4SbXbLui4GB1jl049tI9LhWKDuN19XTJI+5hBKbf7IVvmfxS4FejwXwWNbUjLAUNg H9j/gC8p0BhoDVRirwANHAqMBaTAxcCCzx9oCjT5sgMpgdxAJUjNBsqkDljBMnjRZf/lwHnwn7HA Xf+WfztQGKgOWAIeaSmQLyC2mq3ufihkC3lCEV/oqMWWZkbYVaGkRxKigkuY4Fa6RkUTm2Lfw6Z4 xsxX+laYenrcfFusdTBdG97bdIw+5nSxS6LbMS7Yu7bFHHE/P8VPOY6JNiGJWxcZS4cnLNyBUTpF gQ9bergMbsVZwxQIF4Rp4ZJwBWaxBP2Dp1d7EmLMMdOtiMUQP0Pd50TGXnHqoeOY0w9ROiqOi6UC J4wIE5Ye5rpwR8w4lceMCFWWfMEoXBcHxAqhHO9ApzPx7oMjEO86bDW/A2MXCQXsGlwJOv3+IOxs FP4qQoS0pBZ2OS38Q6RWr9UjzVs85ls85ls85r8PHnPP3N79KmqZR+9DqLXk31rVPKQfWD2WYVO5 Z4E2W4YthcYVr65r3dJq7fBm2c10hbfI9NBc0FVrPGQ76uVMqdaU7nues54xz3lLo2e5fZ9n14ss rSdslla72VvuNXbVel3ebEuj0WzrpIX2xhMMbT51hT/smDvJeu+151uX6A36QVs2f9Y72D5lreRX 6ZmTrd3T9ChfSQe5bZeNp04wJxjPmmMO9v457x3c59R96PeIl+gNfqnrMtxv1THK1/FsWxaX0d7Y PUi7ncrpajrY7jlRzGSLadZNcb94yNRsslvviiab3Zrbfc+S0lZgNdjSuzlHCzwTrnHb5hHhXvsY YMRkkIaninjk1E3R3X1PHBKLzSNii+m6LRXrp32XFjwLcIdC+zHjStc6fAbaMU/Yzd01dMUp1FVr 48xXTKl2xvEArrGuq+YR59GTd7ni9kzvTesyX92WRQ9wR/g6rta6KWSDToaEgvZGrqEt25YqFLVF uW1bVltUKOf2C1XcMVs2XpOYwxSdrna0nCi2ephs62Z7I14RbTPZ6VLr3a7i7nsmo2XMlu54YBnG s8Tz5NyeBcss6HPEVN59ztoBM1bnaBnuqrVvddlMqdxVS11XsCtmOe8asuyYELfujLbvdtstw+YC bPvuc5YlboZb4ebsZttRW2dblB46lS4YabOtqivZPGI7amxxRo3mtmzAa2fbG22dfCW3QY9aKUuK zWVzsbM2P70uLNqUtuxT6dxWW5a1Elve2GI0W5eFCzTTln2ytb2yvbHdg9corpyuZg22KGgQ5iwe OlH85vposENbgaXJlt51zKkwF5gLJ5etbLcLEMy19rtiDgsS1lxsa1M59KElA+jD3lZw6ordbDzU lk3PmOyWFG8nvyYG29K7670F3fU2u3DBZvdeOHXFIYDXr1nrwOMbPWOmclOWtwRsvGYZ9mzaD2Ib e9Ox/3ur2GFvc7cO29hLW5a7LmP/79bBT5fxiGfWm+RN6lk23bYMe4tw27Njn/HWnGz1FoDl/Z4l z7Bn6oTNaz+VTpcaD9EPPKtenbfekm9N8dy1HLAcsFLeo5bCrvW2AtO055YN5kALpmZbiamZD3sn vBOWWf58e/6pe/QQz/IJLsNax68BtoRI4Qs5wTrsHTHrnEdphj/Me7wj/K5XMXGCjs/k9vA9/Cbf 2q14k/gUfpkT6HH+gPc+3+Ed7C7hK73X6YH281wOd5CeP3WOFk4wEG03rXV2knvE33LMtQNyAyu1 mqbbz1rPC9faPVytsNi+CxFzU7jdRjvm2rIEZDkgPHSM0/PWTZdZBLuJtd3ZImOaxr4pxto7LCk4 1rpL2hvpUeGO56J40Jsqlnrz2j2ApKDdndoVFI8JzeAVbnGUz+RThOsMLQ44YvSM0dTeCFg6A/In G9xlHXKssDgjkqLA0HSD2CBcgLjYFMeFRROyHrCktLd6B/G+QUPxDnoH+cq2e/Q8fZkep7dhn8jm p9qyvBe8F/g1U03XiukC7Df5dtjxsA9Y62xc+66lkSvlDpk4roKttC63J4zj1k26wVYglAhF7bvG cVwhPmt4D9fi2eRMQr33HmcW8sBf3cIiriajmEM30ONMjXFUnLPO0g8shY4HQhbsgsU4RnHLXmHZ oSsgUhnLLCeYyu0V3cghWAq7b3af48a5SS9tPGY8ZrM771jqLOCZ9hVu1LjCxdruc0OWZe6GtcMz dprq1tnNnA3KZW7elnracLKVC0LkQrR31dICNyC42hv5s0Izf9hWJdghjptNzYKfFmxG67LJDtnZ BHjMYRMSpq0UPUMLQic4Hgd4fEQYFC6ZRk4fcNnAq/LbsoWjXANfTY9iz+xKNk6+GcewtzOCYlmD GE1vLxQvswbxBuyY66ZyduFEsc3fdczlFh+JsW6um7N1dh91Kl3HjANWVnzAZAsuW6q4LW5JKd0T wjXrZncJeM68eFWibOnt+a4G2AuiOKYd23D3LHFDfYY08AYaZtSV3JVMC9iLLQdMWXyd6rULpx5y yd6j3UW8BSwdtd6yjnH7rWXtU/wCP2vLazt3wsYvey95L/EXvYveK/xdOo0eNeVxgpAEPnDQOESP c1v2WnqIdlsOGM3eh9yWdRX7EL5mKvGeM5UwNZ5Nzybs+tN0hunhCcaSCbl5Y1exkEq34Dhug6eB dbYrmW8S0q3L1jV4RlRYKIgdeJa1XbcaTElt2bDXo65HcPVuWxSeaT1cmmmaTrbutk85Yl0rtig9 YNm1IZvO2GJljeYTTM8uvWW5yI9Zc9unTMg4aR3my/hqtsk4T1/lh08wVo83CrOc8A56znMkPBlZ /jzkRcvg4zt8NSdwD05AJHjW+Fw+H2LiNr/Pe42e4YTuGssuXQoZRwqxRqwhRPyS+CUiNJuaTURS X6cmkYb6FvVtpKcuUIsoiXqdWkHvov6J+hV6D3WH+i3aT/0zdR8doP5EPUQ5ao6Tq4WCntA+pX0K 5WkPaw+jJ/VT+il0EMYY+D90TncQ5alZ0nOQI30DeuMsqVpl4D+JFtFlVKPmSp9SGfg6lYH/tJo3 fUbNmxrUvOl5NW9qRP8F8qYX1LzpmJo3/WfIm96LmtSMyaFmTE41Y3KpGVOvmjG51YypT82YvGrG xKkZk6BmTKKaMUlqxuRTMya/mjEFVJY+rLL0UZWlP0+WQDY0oWZDP1JPGP9KZeO3MBtPkJiNJ3T4 hDGhx5w8sYf8Hvkj4m2YjSfSIUv6DZGv8vCHyC1yi/igysYXkv+sQcRTOD8inlUZ+M+qDPxxnB8R zSoP/zmcHxGtKg9vUnn4EyoP36Hy8C+pPHynysOfVHl4M2WjeoguyJjcBI3PMRMOlWl/BZ9jJkZV vv3LKt/+FZVvH8fnmImv4XPMxAQ+x0x8Q+Xb57SbuiTiH1Uu/ZbKpf8KZ1LEbZVR/7XKqG/oPqD7 IPEbnE8Rd3RP6z5F/Bbz5ySJ+XNSg/lzktK169pJLc6qSJ3uFd0bpB7nUORhnEORT2O2nCzBbDlZ irMn8qM4eyLLcfZEPouzJ7ISZ0/k8zh7Ihshe5LIF1Q+3KX/rv4XJIczIPIrKuM9oTLe31AZ70mV 8f6mynhPqYz3t1TGe1plvP9BZbxnVMb72/h0NTmLT1eTP1F57J+pPPYNlcf+ucpjr+HT1eQv9v7a 8DbyJuRQj2u0OIfSJOEcSvMYzqE0yTiH0rwd51CaFMihajXvwNmT5sM4e9J8BGdPmjKcPWk+irMn TTnOnjQfg+xpW1MBOU6pZgmym89pfqrywP8VEUQxMfjXnOV56d9c/d9y1h0PHdVI03H/xVn4TXbc fXESfm46auGzWy+OOmDf67jhqIfWiqOqaxBaV1T5RcdhVf6i4yC0Zl9kHBnQmnxpFlrjjqwu4/+l /fJ/8uHau7qUv/4Puc/c+l8r+Ws2ixl6YQ8zzlY117EKc+P4PLPF3GAendg9aT9uc+Y4DzmLjatO U1uac9I577zqnG+9xmaxedBnkplkq5j14/PH50/a2WvMI0eKI7fxHHvfmWZcZeZe2nCanExbGtxn nhntLemt7+3sdfUO9g66Dvde670NrcHe2+409/7eTnetu8VtdrvdgjsHrl1zD7lH3ePQpwakOJC7 DvJQ3CTUYpB3u4PuHOjJQXv+OOOYcky5LI5ZV09nxwt7HBcdC8Y6F+tY6uxweRzLMEPhhT3Hbcfn ja0vZLgkx6or7FhzJfCc3Bvu7d5BGOua+wGMMNhbhWfUR8G4t921vRNuoS+lb597qC+z7wCb5dhx LbTEXlphq1yrbCe76Lrl6nDdZReP217Y48x5YY9xyjnv2HVe7ezoTTcuGBd6s3rToeS5FnqLWmLM Oms3rmINPw99mPXODhaxd5yTrA5mYlTnstE72FfZe673Wl9Tn8WdBrp4cx6dMI/hvinQC+in7yKU hb4lKLl9a3233Bt9YfcDtxvrtM8C18PunL6zoKdrzXXHbW1p0DvHaXILbDroLMd98Pj8SxvMKC7Y iuzD5rrmupMFzoPMA4fB0XHS7tzPjBrLnCbHYbD4+mkjyzm3mMmT9k4DW88qx23MpHOFGXdYwBOq mEcgb+vIc1S3tbAlxlX4bAI+3WavgOeUOueZFUcPO+1IOM46hh1jMOYkrP+GcdUB2nSawdNutF5z zjROs1H2govqbe41uud67arV/b3R3pH/zt73ALWRnXl2CwkYmRBCiEMYjIkHC1nBQhYyCEnGGITM YCFjDSP0DyG11C3CCKmHICG1Wq2GYzmW87KUj+O8PkIIoTiO81JeF3E5LKE4zsuyhCWEsIQlDssS QghxeTnORYjDee91Ozvera2bu9qqq0ptuV49ie/169fv+/Pe9+Oj3wdd9FuLmYseRPeBptLoTFpO q2krTdCPGP3QHQx/wF4eRCeik0BifUBiUnCHB/y0CWQyCq5WAA33R0uiTdET+k50MWqm70bLQcsR XU83g3vn6SV6ld4AVkDT8XQibaC9YCTGLoLRmegKMWycIMZYi68mMfwAPyCHiF1ypm42fBqVA+vf j8gphf2e/V6kHrQSwBqmXCvAJu9RI+En1EPqMdj2gQWaHlCD1H1gf9Pgzm2qOLwHpPks/JwiGauO BuljoNEk+lkrv1VMv2qV0Uh0xxRPbwGdniPnolmNQWqBSmdsD1jeNplA7ZFz5JwpnnrB2F40NpoQ WWocZWyO2KCWQdlmLA3cmQqsNJkURSVAP/vIHWohshRNBhyNUU+pp0wf6mUUIrGa5+BJy61trcWt ilZNqxZYoa3V1drArklBa4C1w5HW+2A99DJtwALJVjK6w1grQ4NeKVFd61p0Auhot7UY9HvcugeK vtXIWmZnazewcJzMMsV/VUvmkzrSDNZRExkkFzEFJYwcM6sUrFN+OD3MJTZQObMP1ayBnehVWBOx hsURa0QeqYgYqGKwx8wS8xGDzwgssCMyH26jtMCWgD2F9aaxsIssCd+nkkiMEpJgByLX65qdT51P w8awjeGbGIvc+Wr6V9Mjt3EJY4Xh7nCnWW/WU3yLhJRQp+uagZTSqXMkBWaTRInrtiiZq6uOMKdH 4iOcSGIkjdKTKvKAUoBSjMnA/ng3MhCWkevkOlZMGcNk5LAhlbIB3SgoF9UQYdbbA+IRuUnuRHIi 6khVBInQkV2ynxwNFwP+5yICShMZIwaIMbveLP6HPRj0BfsvsKsHkSVm52VXbDmJAanZ62aBVS6h KWSXKT66w55e/XPun0MQ9y+4fwHB3O9xvwd8y19y/xL4lu9zv8+eXvVA/wZisqUzqDeNRb3pLOo9 y6LeTBb1fplFvVks6j3Pol4Bi3qFLOq9wKJeEYt6v8Ki3hwW9eayqFfCot5LLOrVsai3ikW9t1jU q2dR7wcs6q1mUa+BRb01LOo1sajXzKJeC4t6rSzqrWVRr439O4GDcwUgXYRFuhTnv3O+B/Wx75R8 g0Gx0LcZFAt9h0Gx0CSDYqE/ZVAsNM1G+RfZKP82G+XfZaP8P2ej/HtslP+XDIqF/o6N9R+wsf7/ wcb6D9lY//9kY/0v2Fj/EZfk0tCveIexCdAJi0G/yGLQVBaDfonFoGksBn2XxaDpLAY9y2LQTPYd jgL2HQ45+w5HIYNBYQX7JocSYNBlWMXG9BvYmP5HbEzfw8b0G9mYvpeN6fvYmD7OxvQ/ZmP6TWxM 38/G9ANsTP/fsjH9TgaVwr8fNxv3E3icjcgvsBH5H7AR+RU2Iv9DNiK/+s4h/xT8VwyChP+OjcIf sVH4X7FR+GM2Cv9rNgr/kkGQ8G8YBMl5j31f4QL7voKIfV/hK+z7CjkMguRcZBAkR8wgSM4EgyA5 /42Nev8UoJK70OQbbFKp+Wf1UxFazb1QPhRT0xtShUoAdTskA58doXOgjQ4JQ2JABc3tgGoKpYUA JqppQGcB5QolhLIAZQ0eA8oQfBUCq6JGFzwAVHnwIHjy/7SKPsFX8SnxIpaHNAiYmbbtH2rMyUfb JpmrPrjvnAkJQtJQkfdJyBtqDtGhu6Hh0JJ7KbTqiTX3o3pzKvokOEmI7ePmoeBMcCW4GTwIJWKT 3oVQfYiuDVrSQkuhDYKP6olzoTFw7VBvRZcdG8YHaCfRFnFZttDnxBqx505DRuwTVhvhIrQ3q0x7 uiDTA9vB9iPFN4nIOfSeHSL0xgeRYssWsYw+9wxZnpk99uqbRZgo8hgzR7ZD80Sv6fnNAcIVGbFU EVqrMcox9ZpGqrim7o+NH23bD6JW95K5JErbR53r0anofNUaukDeRpfNWPTQkRM91k1SRx8Lo/Go NuKqexytihpA7+aoNzocHYsYyduENnob1VqqXHJLGiOfEB2uds6Yh0JF4SYgn+bgIiMddDm0FG53 L2HVqD7cFe4jxOH+8NBH22Fz2FP1IkyFe8ITlqLwjKmBUn1sNBnDc1SJqcE+bt90lhDFVLW7Krxo tdmp8I7bSkncCOhnDudT9vCKu57lCXBTxdVNAo4o+4F7CbQBjoxTzvVwdXTKvELeNmc5mh057o7Q /Efb5lhmniTHOUPGh9L0ObeCZBGYZdHrObrqUb2riHxEiMn5UDO5Re5+fI58ZoY+NpLHt4LmavIu GK3f+4R8RVYRJDkQqiAfhJZQjd4a4dcm1/RQQbTT8QpdcAMpuovsCZYiq602g3A5Nm6ZI8WRJGwf L7JsuTeoA/euw2BeuSVxH5r3LcOR07ckpj1G8+5h9wPLFrUZrrbarHzzkNVocjE80ooqLl0czXHs um9b0qL0R9uv+TP1krfpbX2KI4d+0Qq1JremOhDMbt53HLZmWVZvEsEDUy+6wOia7qZH6AX6Jf3U uV61TbS5D4n0W4vYTPRu9BmRFNmLbqCd5ozQbGg+6sVz3HeJZaI3uG6OdU5ajoHlHwSPzLHWbWC9 YP2BFSAPIYyOQwOM/Ye2QrsElyhmdEwkYTOEkJABO8gMZRpXgychTqgjdDv0IPTI8Dj0mjaEqkLP wEizWD6hCCUG54I7tUHitLnfPWVOBXaTAlbXsT7NPh6qMK4aV11FoVchdYggFJZj46rjEF1GlwlN RAHsf5poI9rQvcgysReGiOLISORJOANrjzyvWqYSwEqxeTKwI6IhnBxOdQkirshDooFKJozmHSor UuzBIoORl8Qa1hRZi8gi25TExI9oiKegaKu6I8XEY7TT+Ozm4S0orAqXoMtGoBviiQk8KSKMvCAW iOdUBgVZcXOfucnNMdtNLj2zxnpRbTTF1EAUg3UliEo/NkblNfnoC/dStCN6G7Q9MBLRVbOKsc3o VtQbOox6dZPRnGiOWxBNC8VHidCd6J3QlJ4THWDpipA1OhvNwXOij6KvIi7qJJroEUV3Tactq8hp YO+ZUYQaxVTRY5p/q4dOok9H1eiCR2TOdzVHl6JF0Xqaa+p1HN4atZJWnHDZJ9xFLsGtno9eEtOR YvQF+sK+E47FMgib1eZrd9R7tZ6VyB42Zzk2l6OdvoMQWBeMDViOw11g91vCjsLBmvXwJHLa1OD2 ur1grS66m4Ob4R0r1/SQqWB9YpGH4fWINrxJeYi18A6lc64zkmGKOcvUbXlWm+AaqOmnxfQ5tC1s D49S5XR6WEcLw7owFh4PEWYI7BRH4QMykUwhBaT01iIpD6lJL0mTBNlB3gFPHSenyDFyidwgD8NB shmsyxyygkRIK7lKGoIrwC4zwbreD5+Qs4TYDEW4ZBqZGTKQ9cFFcjiURqqpPvez8IyxiGqi2qku qh/Vgr1imBp1P6ImkXPUDDUHVm0xtUItUjvuVcuWaZCiqCFigZqgxql9Um3vQe+5BL4DIDePx06t Y/vAItPdHVSPe8A9Zpa4p271eG200TljObbEk5m0htbSNrqBxulAtMhdT0/T9+knwAaOge726LXW WOtgawb9kH5sP6BdNEnfixa1JtC9HwuB1eQ412kZKM8dOeb9VhF6j9bTnfRg4zC9HBXQbWivZcuy FRGjj9FpdME1b95hrNicb20gtCYboTWk6+XEy3BC5F6kO3LfVX9Tjp2E8y3DYPd56i1GFDq7oz6y TdwjBhvlxAhxH1jADtppSaRSKZHvwKB3VeHqj56Hy2uTrTZMZSkitiOdNzvCWcQ0c40IEDhBYpNh kWcImyC6zanY+oevnMEIGSHNB+54dNDV7E68+Qo5h1G3eiJtVD56rorvHHfVW7dNTzAdVo5VY3a0 F+x6NnemqcEgdAssFbdE2KKnD+10S2+p3IlYe816TY/5oDbDnemWu4uwldoM+zjRiaVi+ZH7VXyz B6PMIsN0BI8EwpKbs+jLyII7B1sntMCLtkUaiCfEi0gvAXyqrz2y7e0Fmo2lUiPnQLsN6FkfMUa0 xHJjPfGQcHk84fbajHA1QAcx3L/n/j0EYASPC8G8d3jvgLa3Mey3Mey3MezfsRg21ANWzifovfjJ J/VTf/Oo3vUboJjqrQ82wTenet0DfvOuXvFXg7bFDxb85YB6YtkH1PQHU349xPEG/VVQjLfJX8X2 H/VLwLWhDwb9qYC6ZxoAVO8Hd/zn/o87xye/bcTUx7S/ebu5OOUfV3i4DtfO1hx5gjU6z4RnxrOI 6G+0N3IaExsFjdJGq8XaaK3r1YmMW5UjJr2nvHGqWqWT1OEeO7iHqtGZyxF9RW9j4q1Y3WijtbH+ dc9GqYdqpP1mf5N/PBAfSAkIAvKA2h/0N7FUZqAigASa/XP+mcCU31wzx8yhMdG7XaPTSTyLPgjR N3I8ZmYGJluj1ZdssZq2jVu+VF9W45RP5APP9+55X6rbfAm+DF+J39NyuiW95VzLaX9PYLVF6Kda xHV4ZS8z5rXpGp2vzzNaNlkW61tsFHgWX49Xc2TcqlnE1Y1TLW2NHNzb0u16gBOV3a5dvKMstkWD C/A0nYiRhW/Ty8dzPIstgUarcbWlt+Vey6CJNPUG4r3bLSP+cQvdOAZ4vu8vaTT4ZzxYZW9N+c0O P+ShPO2VvVV4o9Uz6pnwZ9Qseg4YvhpzGLn6yxubSzsalxi+jFtmXeOjxlnA+7hnXIv4Ezw9/qyv Lfkl/vwKDbi/y9Pj2fFs+nWeUX+J6YlOUqNrfumPvRVr3NKJLBWVIx6zP/VGu7+6bLRa5VnUIlqk ZrGu19BgXNJJbnZokQ8ZXZj9GKMPoBF5wBpY9dsDY/6+wO3AXX+fnwpsBKoCjwI5/pPAVuA48KqF 28Jn9Af0FR+w+rsCRf5kv8iv8vR59v12ME47aOOAmhao9y/6VxqBRG92MNWX6plotJrbfbE3sBvl Hw4zWgEakXkmTL0tClOS97kv3/vU+8KnatFXdgN9trcUt2g9o94930yZ2TdnaPCdtDTg8YyGqlXV qhayBW/pxOtx2hfri0X0QAfGFtfXiEZOi81jB9IZBxpt97XrzI1Tld34Hd+oedKz4zvymHGpZ/SD ey33A/EtD/1NLY8DiX5zwBswBAjA7x3/un/Tv+PfB/zOBuYDSy1JAWlgAHAEKP+Qv98/GhgOZPon A3SgI3AYeKZbDOz6PYCXicCDTyxb7T/wtwdS/Ee+ZPatW5gHg3UYwwPugxfLi4U4vHhePPvWbd// v5xRUDsoF6EOUMRQJyi5UBfUDcZmToZdZn16AfDpc5Ac+PV58DTGpytYn65kz4FdgbkwD7rK5p66 xvrWEta32tjcU3ZOEecq5OBc41yDnJxSTink4pRxNBDKeZ/zPuTmaDlaqJ7zIedD6KucGk4N1MB6 4Y9YL9zMnuvqYs91dbO5qv6QPd3Vw+aq+vecJ5wn0H/k/IjzI+gum/39j9hI3D02Evef2Lzv/ZwX nBfQ1zm/4vwKGmBjbd9gM1wNshmuvslmuBpiM1x9izmbBY2wea7+M5vn6vtsnqtlNs/VD9g8Vz9k 81ytsXmufsTmudpg81z9mM1ztcfb472AfsE74h1BR7xj3q+hX/FOeK+gX8fCsTB0Ah7Lhf5XLD82 AXrFelsY+FkpzGFPX3Fjr8ZeBUrXxGrg2NgbsVo4LlYHPO87bOTuM2zkLpGN3H2WjdwlAZ/7Lfhz 7OmrZCazFpzCZNaCv8Bk1oJPM5m14C8ymbXg1DhvnBf+Uhwe1wSnxfnjAvCZuGBcED4bF44Lw5lx rXFt8JcZzwu/BzzvLHwh7s/i/gy+FLcUtwRL434Q9wM4L+6HcT+EZXF/FbcGX2Y8MlzAeGRYznhk uJDxvLCC8bywkvG8sIrxvPAVxvPCRjY3l43NzVXH5uays7m5HGxuLoTNzeV85zfv/AbGmf+yAX/M nHCCm5ic6PDX+J3834f9/H/H/wO4hd/L74UJfh+/Dw7zv84fgEn+IP+bMMUf5g/DNP+/8P8r3Mr/ Y/4fw+38h/yH8O/xv83/U7iD/13+NPwH/Bn+E/gP+bv8XbiX/0v+L+H/cCrv1GW479S1U9fgPzp1 /dT78L1TN05p4a+f0p/Sw984ZTxlhAdP1Z6qhb95qu5UHTzEZg/7FvCCvdCDN76wMP6f1E/1394O vA/4Yxrvx4cY74z3gs8mfAS0efBOlnLhY4Cy4QT45ngN+CigqnAP+OZ4y/E2QJXgNhwHlAJnfLsM r8Kb/y/7xpszSj2x9WzeMw3A5pD8bf0XVHjYnHo9SS1WLhv0hdiNk9JZBXJNqMLKVqqel3pvnBir bpwoZT5dyaYqoWzUV63qKtkso8ypxRtqcemuQa8YViDqQNmK5k7Zyo0Tw/LrnqXe0l3Vis/sawJ+ yAx8z4QPA7UJFIYaBz+vg9rja8czfScqjJlDIaZ4ZdCXUaWzN/YViArzZTEzKFHdOFE/NVZpUko2 C9tLzKoubfzNDtCfr7eWSKr2VPs1c14N3gwsjMY7fOO4FL+Np+B3mBGZMfUcg16t0Z2USa4rNLfB iLOvx1OLSzavD5ZyVF34FD5bmlaaqVboc1Q9GqnRi89rN0o21WKfjpFF8YDaCHgexx8BaVjxJXwV 32A4wjfwLXzX137jRJVQsmm4zxRf+80U8NxBVYlPBKQjY6RqWNCkFGK+8irNNSHD1zUjI9drpOZY KVP3MnyBZ9kKZxi5yqc1A2UJvnyfyrXr2q2wqZpunNw4KVw3aG4Oa9WF7boTw33FWBll0AOUJ9Hc aURUm2WLqgRflq/kmvDGfgMYrXS2dKB0QLWilJXOAj1SqpLSsesLQBdmoAOMwQW+Od8KLvXZ8Xhf ELQcgc8mXA44SvNN+kbxItyAW3EEr2f1x9y3w9xr0NyoNjw2aEvTfHZWk2xpLPKN+vp8fUCqYlUJ UwvbGTtSJTcYlNuaAeUg3gy0koLfld8HTxgwp5bOMvpjPvExVY9qpRAD9gc0dF2BP7iuuJlSOlvm Kcs3yhkNMUXVpdvHZwtn1N0MilMgjB4Bj7P4bNXz4g3DgnwaSAgrxFRdqi51g/budTE+rKEZPZds alI0twGHZt8iy4cdlE3w8z6e4htiJdHv68crALLNAXx7fTMMRyxFMQXn4Bxfl+/Atw9aq1R2XO3z AI69eOJvLZux6T5fE7CGIfVTsDPp4D+B/wRsTN+Gvw12qe/A34E48Hfh70Ix8Cw8C3HhOXgO4sEL 8AIUCy/BS1AcvAKvQPHwGrwGvQNvwBsQPyY3Jhc6FfOjmB9BCTF/HfPX0GdifhzzYygx5icxP4E+ G/M3MX8DJcX8bczfQp+L+WnMT6HkmJ/F/Az6fMzPY34OpXD7uf3QF7gD3AHoNHeQOwh9kTvEHYJS ucPcYehL3BHuCJTGHeWOQu9yx7hjUDr3Pvc+dIb7kPsQyuCucdegs9x17jqUyd3gbkBf5j7lPoXO cTe5m9B73C3uFpTF/Rn3Z9B57s+5P4cE3F9wfwFlc59zn0NC7gH3ALrAPeQeQiLuMfcY+gr3FfcV lMPu4RfZPVzM7uG57B4u4Z3inYIu8T7D+wwk5X2W91koj/c53ucgGe/zvM9Dl3lf4H0Byud9kfdF qID3Jd6XIDnvXd67UCHvDO8MpOCd5Z2FlLwv874MqXjv8d6DrvDO885DRbxsXjZ0lSfiiaBiXg4v B7rGE/PEUAlPwpNApTwpTwqpeTKeDCrj5fPyIQ2vkFcIXU9YSFiAyhMWExah9xOWEpagioTlhGXo RsJKwgqkTVhNWAW48y1SfYtU3yLV3wGkCk/F9L7Be2Lb2/ovqJ+K6NEgtgXFoE3YLvYMUA3YJvh0 YfugzYatsJQBew6oKuwp+Oag5aBfDFqCLbH9FdgMoGTYKDYBqBzsHqAE2EPs8Vvf+K/WN76JqVpj kDf/10o0Aw9XTpeplMs39pXLuY8LrLXlqBjVmMSFwYq1shlJV8EjSddFCA3Ii+X3y2bQNrRTk3h5 u3JaRiuXlaeVy2U9oH9xYVAhLwyiNtTF9CxIK5spLSp45ExGB9EF5AmWikmQNUyCjqAjWAKWhYkw CVYNaOYv76PO0dx0Zg4Fd8XDyuXL27XlJeOo2CRGFpgZKLmSLgUYK7dTXlzYI3ehnW6OYrZyWlFV pstpu9mMnRj23JlugSvHLUX2XFbnurMLG3XLmRGZMW1FymWbHE261invdldVrNWWvx5PuSwvdtOF drSz4MHVJlTo7nDfdt+RF4sJ7MisUuIlyRcT0AAjC/VjN+ImastdA5Kuknb3sHvMsYWluucdHPcD VzO6LOlSTsuLKweZgi4XF5WpihML4l1bytNyW3FiqUCXLGkXE+hpWz2qQGXqNrWLkSvagOLiQ20O wxcoxrIZhRTMSVEIfiNwHbpe1WRcS0e1qF6dJOlyPXMdo+fQ9GvTaFLloMRzeVu57Npw7SrkKFnZ 6/IWpCELrl1Uo3xYLC89ri0vUIPScRFSPjSB3xgL4gsqStXOZOcOkDfQB7qMlWA65zrajfWjDzEK 63KtAr3MAJ2MY/kAAM1hm8x7NFgW0B+jrwQMA7UE5V+7hxpRLipEu9ERhwG97zBgsVgGZka30T0g heWL7czTFPNiQtLlTpGPFBjcabl8d47LCjRSVLjinnersSPbkjve1lHX6U50Vyi2CjrExOUGm7zo obz7okT+sqa9try0yt3s9jIa0iRqEmubNPKrTdfuu++66931qJjRo/JhbfnVptpNGa1LliskXWJC TNQ2oZ1yo3ugIEdhdRvc1gKrRS5pt9DuR0BTU+iIexZLBsWOlWMesPe1A0k8t3ehL8COOYFN2new A0xln0HvMxQ6jT5Gn2A9WB/6FGvCgti6o+LiHLaI3gM2vIYNMZIBls3Y9LZ9BstCXyqK2P+39PIt Dn2LQ9/i0N8FHApWR/cbT/fe2qdjKtuCfR6Ksc/bpu1LgHpk34E41m37CmibsI3ZZwC1an8KqBFb P/jmWOfsBKBWbd32WdD/tn0cUF022t4Pceoq7DZAkbYm+8gnu8KbMyrbvP03GaXeK2Iq52fXkwR8 +4pyULxbqJOlSV3ShisboKX/Ckc6kgXaBfzzXvFUwRbTI686r1+8K127npR7zr5yiWDamDukDUJa yhU2FwxomuteZq0UnRZPSXQ5T/N0+TvKQWXD+VcCviPTkeNQOyoc9Y7bjruOsUqtdtWx5XiGJDkO ETGiRcSOIiRQ+RwhkV7kHjKIcJERcI8A3FMF7nlUqXWsOp45XrG9Fa97Og4dVYgNeSwZksVnSwQv Lh3WdtnnlA3ZEsmofUcyKpkQCi6csy9mrQgWSpoUaVLFpZxsiSPe3pM9KSbyqtk5MbOpB88ac1SA Z2w5MpkZ6TzgKXuI1tEBnvMCeYkMOiFn7PWkSwN5i/lzrCyOpGviKgFfkCQckAxlrcjilYP2FakG XDnI65c0SV0fzuZtil9pkOvc2i6JObfNPsrMTzzFSFia5ACylsVLwNxkFdmLYCZFzFycIke9U+Kg neXOauQxmMnYb+ehrnyuO7mZBubhce7fFDhPXByk2LnuuONKdEiRgHPGoQYyATJ1djmHnHPOHecK kOiDQp2kXDiAyJC2gq3K5+JdIL105Jy0IecpmDlfys2jlIPZi4W6Qp19M3catOCSCWVDXqrYmtcu aLg14+BI12q78qDzmYrbwsTCpqxNWVrWiuK2YNveo3wBJLCb16XS5c8BjhZAUQDuFOfrs+YEAVD4 hfvi3YIU8a593T5ZulFA22cEfOUgsBgX6Idnqwo2BElqXLqW+zh/7rw0u8sR75ADOQwAnTNaNzis jmbABcHoSHfiWHLMO7aQ06wFFCNGBEfuM/qpfA5aukEdcdAOGnnoQBA+InQMgDsRx2xlJ2hLRzTg aj2QstpxDPoPA5l1Asrr2EBcSAPC1ZUg08gTZAHIO+A4BranB/N44NgFd6kddxxTYiujdemIIClr s/SZrEKQBCwfl+L2neyVW7HMSjnvPV9UYJUvFGwJZLmdwnrxriYxWyLdlm5LRqUjearctpImofV1 AfY3nrWSNyo8zF3Itl/ZKGmSjILZql8X5IXjNrLtTEaeOlOdGchzZQOyjKw5E8RV2SpZfF6XYO8C F6zBc3kSwVPhfC5flqKghYmvbU+8e56W8rP7s/ulLnWDukFwWpAkSJIMSV3CgcLN3HNZm5rErJX8 ubyurLm8frA2ZaomR4rysYAreJEbAJzFO3WueEemMwvBnfnADs1ODFhck+OBc9Q54exj7BBIh+tc R+45D5xHSLpz3DleqXXanUFw9YFz39njEABeaKCjaWTauQksdt2V4lQ5S5ztzn7npHPRQTgpaTdj BaXPLF7DY+la4YnyBWMv0nRhCviUCfjyhfwd+5AKK6mu3c/uz20r3cpbsffYR0E5so9Kjefl54vE UwK84l7WSQEB0NxWXrV492IysKUFTeJ5q33cPqG4I0vJA+tL2SAZsveVNIkRqUuQxFxT8mtmLnUI nmjuCOkL6UXdEp26IXc6d+GS4ZIhO1aYWZSUP15QIRMIE+u6S5/Z9+39lyqU0wWHuW25DzVLpa+E nNxp+4G0O2slayV7MluStZi370iUNFmXJUPiXZn8+pOCirz2LLBTZMeCnWkyb0KQZD8Bq300v70o XeLJ7ldOC5vrugVkgVqafl125a4gcLErT3KpAmgMrJBCnXVP6nq9BysHmf33/G2w0vqZnRfIbUS8 W/pMuiY8lDaAdVOhHNSsyuKRPTZP3/e43397+uTt6ZPfodMn/ySPZdo8Wz8VEUnGrsqhGMmwpQ18 cyT9FgJ89l1VgbYei/eqCFCdV4sB1XYhLa8TUIQFoB5J84UE8M2ReK4mAwqzqK9CgLLlDgPKKDzI 0/+j9fHmXElCfPIbrJYmijm5WC/KzC4SbeSmnpWdmXx/+4zZglsCol2Ly9ImmLPctzx+XyZOtyyk Lwu70/eyc7KtFSpLuuWcRVgEWbRn9i0N4mXRrmhWtAt6j1ieWBYsa5ZOcO3+FfxC1oUSsV4wkbUr iReTWWlW1eU+Ub2kQoJ8hS8ZljySzJ4pvzpmK7YZzwoFybYGwWKtIXe91irWi/W1zWLSKhE3iBvy ckT14l5wX/27jyQd5VWitKzdq2MWsU1Tu/TulGRMTNa8OnsuY/5sUl3+u1NCm1RVV104L5uW6i4n i6YARWVXpRuFCsG4WFF7WPPsQkJuQl1qXYbKkLVUJxIG6nRnMNn0ByuyadFUpbmuT6ioG6qzZy1J VZbts0JGPun8vMzc1ArV+9vil0A+gYv172tzRy+MXs6wBlXNFyDLgnj7fEN2Tm5qOedivRWzejJW L53Orba2C0eyO0ReW++7UyKDct12793Zs9yL84XqC6MZG2efK9e/wr/00nY/M9n2+IwoXWybtvbd 8Fr7L6UzPF2w573K2M1+JrRd4mftFs6LSYaj2grR1JkZqSoPESrO4tnqmmeC9bMLzCyZeWYTual5 0ivT2icXpy5Ova99f/tyho5WNWcXWRZye7Lp7BzhY8NRbU6tNI+ulZ/XippriwSidL5oKrtInM7o 3rppPapNqRWcfXg546zxCp6ZfCFfhGRkCiYuS3IPLm1f31RS/5u9c4+uosgafZ/u6u6QAURERMlL CHlBnkSe4WFEjIAIDAImJyfhISIiIiI+BjGDqJFBBhERERERERERGUBERAZfqAwiIjKIiMgwigwi H4PIh8mt/dsZZ765c+fz++OuddddrrPOLzu7q6ur67lrV/Xp/IS2h1rHJ67IW5xZ3HxtbHTu6qzN BQcLgrIWrRMy+hQuTz6aWdJ/WEGzrGHlPTKLEkuk5GOn5a4qbPpbxw/enHgyZ1K6K/dYUGrLbWtB XuqojOqC1QV9M2JZGzK+LChKbpHRqaw6www+0up0wb7c+fk2LQWHu5yovKAyJa0yszJjRnKLhCGp hyoGDuhTcawyrrJJxsKsDTmFqbYeJmxvHR/rnrUhbUVRm05TOi9KMGWzy+alpxTOqxiZtiKal3qo INXW+jvKctK7dnUyupcV5jazZ3UvG5C4vmxIco6UcdmkvivT3so+1XFYWU5OoZRx2fb0sWkjpf6n L85c0XxbWaey7p22d9qeu7Rshj1vofxvW02sbNXgzdnbWndKX1zWM3uUbVuby97NWpCxN2F79qjc ZrZ1bcwdkx69/EB+0/zqzN2XFyaWZm8r25tdld4rsdS2mNSkGttqRpTvKTtddjp5ecxcNCdnRubS 1AvyZuUtS86JdcofQEuZXn5vZlbZiaxRGZNyD+fFle8sOxobl11lc2VA+di09eVb7Hdl8vK8DZnF scLYpMyStNXR4vK1sfjk6tjoaGr6qCQ3/430aP6I3JmZqbbFTcqZlFiSs7DLuG7LcqbkVCf0bLU8 sTR9bF5K2o62o9I2Ze1M6pDUJnVbeo+C1LQzSSnpbkWR/RZnb0uY0XFLwcBWo21bq8yaXjEz85it mzMq5iduTVshbS2pX9aepAUVqWXdkxZ32n5RVtmM5hsqxsv/FSVlsYrbCvIqxiTNTYhV5OVMSm6R 3iGjU0Fe8pDEwP7XqKK0YupFczLrVyxN3pVZWrGi54GEIekd0g8lzKiYlnoo9VBCLKlD+gKbxhU2 F6uk38g9nLQlmhXNKp+bMCOvjc25kvLN0t/EbG5H69tP3+x701ZnJNj2eSZ5YXrXzIPyzTlg286R zqXR8dFp0ZnRyVljM+vnb0w2F03N3RpbFVue0SL1AvlG58TeiC2JLsqfF10ae9f2Z0kxW+ts79OB 77jMysw5mZMLplWsrlifl2L7iQMlbmxezqSMmLRR+S+xtFWfogkJ8dHV0U3RtxJLE6qzN5fFEkuj Z7K3Jfcsb5g9ofwC+0kprO6zt+P+1OnlbnlcYmnuzIwp0cOJpUlrowfLWnSdnL7Y9j0rouvLU7ru y52aEkS3Ji2L7o4ey61feDRpQ3TH4D2Z7WwP2zVm++bYgcF7Oq4t7xc7mrs+42jLrQVnKuq3XZzX MK9hbESXAa2bZk7NGZG/K7Y39mX6rAond32nFplLczfl7u7yRu4Zm2/bY7tiI/Izct8q/DJ/SO6x y+MrgpTGBXOStsROJFamrbcttbpiU+bSih0FJT0Xxk5X7LM97smizdlHKt3Eosz6mfUrG6afSt5l W8mU/HEVZ1IPDZ6etqPisG2DqysqK5KSja0fGyo2VbxV2TB5VcvdzQ9V7M5a0HFQ8sa0+VkFtoYd TLalmnEi8WTuYfs5lnsse0H5hmhWZlFmXvliO0akZg3LmRftGx04aHdOdeoFbYf1qsxtnPNGYv3k cbEWsUZ52/J2Zu2JZUhriiVEG0eb5e3Pb5G1OfdwwoDYxPKqnHcTi/IHlA/LOZrZLmluZlH+kGjj 3JltB+Wssx97rM+qwQv6rMo7Eq2MVl6WGg0y1nWuzDmQszf5QPKBzKXJe3P32ZQUdRnROqcwJ/dY +bLYlFh11sr8WEFqUkHx5vJD5fvLj5QfT7XmQ+v4lluzZuVP7HLC9vd9YgOipZkHO+5P6hGbUZCX dG/WsMyliStabs1dZPtXk1g/Z0D23Lx+eWPzFmRPyJ7brU2CSe9QPqt8Qc7GxMr8JeWnEnLy48u+ zK6KOtGsnOpoSebUtgvKa6JOLCdaPxaLjciZmNguq1d2VWazrA7ld+QejrYrHxVNSp5YfoetTbbU xF8S2ffz8yM/Pz/y8/Mj/889P/JfPKoNp/77+UMrp+CU46Webj7C/nVTjzePWh5J72F1h5r3Sy+w /+1LL7H/7W5ebP+6qdsH2tlE6rvNC+1fN3XzwDb2vw3N0wam2P9Wp52w/61o3iy98Y89xI+zh8gO by47Djo5vR2nwZH/5nv8n/4/9RPO+Vu4fxW2pu5bJzc0/3sYdMf1L994+22kfzne9B+O/Q++PyXd /zI9Cfbbwuld/7R8GjgNAvupb/82tv8F9tu4QTM+SQ1S7SfL/q3fIK9Bnj3SjqPyybPfogbFxFDS oLhB3wYD7addg1L7Dez/7eynEspflVJhSYMSe47EP9LGMtJ+BhJvsf3YM23Z9v55H0LdPoTT5rTT ht0I2ew6yGHXQS67DvLYdZDProMCdh20ZddBIbsOLmLXQTt2HbRn10EHdh10ZNdBJ3YddGbXQRG7 Drqw66Aruw66seugO7sOLmbXQTG7Di5h10EPdh1cyq6Dnuw6uIxdByXsOricXQe9fi7F/y9KMeJO Nzw1GFlr7SgnbsZ//dYrst9i+y2p0636u/6fw/6UL/Gs+m/CyfGFNmzff9LPq/uKvOQf4ln19/SQ 3v/h9yelfclPSPO/u+cZ/zp9PynPiv/h/432+4YzOozyGRQuC9PsJyUcZf9bGQ4L19rP2HCD/V8+ R/gct980q7/DhhkWTifMhnBzuCWcUBfLtnCnlTdz/jAbtle4x372Q/mr0iEY/fFTZT/ydzMxymcZ PPUPPG5jG2v/1ugnztR94vVDum24uEZx4rm8+uf3G/+L9xt/b753cnjLcS5vOc7jLcf5vOW4gLcc t+Utx4W85fgi3nLcjrcct+ctxx14y3FH3nLcibccd+Ytx0W85bgLbznuyluOu/GW4+685fhi3nJc zFuOL+Etxz14y/GlvOW4J285voy3HJfwluPLectxL95y3Ju3HF/BW4778pbjK3nLcT/ectyftxwP 4C3HQ3jL8QjecnwNbzkeyVuOr+Utx6N4y/F1P9eMn2vG/6FmRCJZkSnMWt51cm392KZfd5L9u//v /3uBfkUvf3/U1f97mMihuvO2/ZuvxHmk7rv/X4f/8VrVdd8pf5f/duzH41N+TE+uO7DuU2o/lfYz Eo5xx7u32c9Ad7I71Z1mpUp7/LY63UB3JuFGop9jv/PtZw6fkfYz2Z4hxyfbNtSw7rda9/34W60e v9VqzO/MW04cv9KawK+0pvArrS35ldZW/EprJr/P2prfZ23D77Nm8/usOf/X4rVzUJn9OU7th/AA PAJ3w23wJPzU1oQkwk/RsyKTYAwOhN3hCjhT6PaFebAH+sVwHdwPt8J7CZOAfAJuRjMReR6pbQKT YAYs4uh4OAoehrtgDTEMg3GwE2T+7e6BVXA2nAYPCr0sGIVn5N650ymacieePJHfo3NqFsEBsCtM gS5cC8dB4qxpCon5h6PI9ZFP2bKtZI/x/bAazpI79UYh18DfswtqHLxL6H4J/wy/kvBWY3txqfdW foezroIDie1S5D4cPYI8A3kLJH7vJuQ/wa/hN/AMRy+At/J8KrXIuwEuhHGEnEcK/4r8DCEj8C/4 HDbCPfBVuAy+CV+EL8BtxEk8/kd1tCXoHxY56MXR3xCz7tB+AhKD9zx8ibO+hQfhL9G/DonT+wNc T2qPIZ+F/AWyh6y5tAHOhg/DT+FSpdRbdwdyZ2ehZZFS6qfbE/kmmE1KGpNy7tFkcq030J8HD6Eh J72L4Z1wpc32iDeVMOSkfzl6aoXZIkfdo2hWwP8gzEgYj+YhQu5HvhHSrl1Ceu/DA2hOIZ9fxx32 LHIjwr3b9iyczlFic8ln9z+Jn5L1KFmf+ubdDLtC6pV3LSRXfejdQwyUr9cTmdK381aJU/XHkVsg b4WPkJJZyKvgY4RpDfM035DPQb6bK45AdrnKu3ANGso9uBA5AZbAmZA679bCzx3bp3kvE3MacdIW bE8rR/WKZysjg2xI6rydiUv8XNen7ll7Rhiib4qe/PQHEv4zuBeNxvAeNPAKzqUE/fFoqFHBueg1 5XfARXCt0x/ebcO3RX4RbhKaCcgx2EgZ8S3PlvC2dUuYerAxbAK3EnKJMC5RGTluNS3RZ3NuEXIr eDH0YQo8D8bDS5Rc93WRbc2Uq3SCnWFP9KuEweNCWxuFT8M1cAMhuyHPh8+jyYWaHu7Ftvf+tC9L fwr0iDmK/ku4Eb6G/jbkT+sod7ePsx6D36J/Cq7mWqOQv0bOQSa13u8gabb9BnTrWc1z6J8j5g+Q j8A/w6nwE1JCbnuvEHM68vnEcxT5HfQduPdZaLpwNA/NbGLQOtAULkVDSoyB36PPhB+i0RK8BR5H w11Ya1bki4RhyNGzudYT8GE0lJpXDlvDNvAc5xMbw3fEcwqSNtNfaUeDiKFWmI5wEZxIyHzkoXAY 6b8XksKAnA8GEHIhYTIgORNcytWpFd5y9B/BeXAbZ72EvNIps7wL+TCkhphfEM+NcByaZznrK+Kk fnpbOOoik7ce8fvvEV57j221862+mfYbkTbSJ9fstPI0NNgD5rfIq7Qnl6M+fYIZX7NJwshZZqDY JJ6OceucLZaXCU2JWCOuWhfra/ZZZqFZKmf5jwjdBcTPuOkuQMMI4q5D3ix2mqWVg2Vcnf7Z+4H0 LCQMo7blHKt53DltWYqmKtKO2KzG/R0prBK6T3H0WWK4F3kRYZbDRc5YG/JKrrJdKdf1Pqi9zB6l z3ef5rpqC52A25wRMqaI7eo9VzNX+g1yRkfhOYRfRd5OFNvMvEPObyTP34Rv03+O5VqPc12sX6+m prnlQe79aqGtgZL/8yQem2axry7EBpvGFWdqqXHF+8WG9GYI3VvEdnWxNzwd633Rm1GSJ7Y0F5HC RZSOjC/7SNVQwk/muleJ/emuqJlK/yD6D2qkv92M/E7NK9KfS62wOWBtTsMo726lBJeQniVipfv9 uPoAHWXIk1WknPT71ZpXYlGYk6QBa8eQP97nyFoH1AZ4AA13ZCaRh1ibPjUk0JH3QTgHXgepdd5t kPz0KE3vY4jNZlJhAbHNhe24Iyw9o+OgWh35yLdArBGDpWewlAwWi/c9MQyCObAYvVo7JwlZD17P 0UZaRhx9rW4MlaPJkKMeFriHFWGwLmzPIGeptfwKXA7Vio4Rpj1hsGT8dPQfoqe++eSPPxaNWjWE N7QUQ8syWKoetrohJ41aPp05twpiU5lfEZJy8SrQk28+uWrU8sGuM+SJUfuhOdT+J5HwalMtgaTZ pKDnimYf7I8Gy8TT1E6GGr/e+2k4HI4hJFaracm5GgPpNFiJPiXiYV179Io+Fpeh1XuaHmqOwb61 8zfpB8g9Ty09csy7D9LzeNyLp/bzYEiJe7QIO58SnsLepua4lKz7JCRml5rvcneu1l4sbbMdau19 C73+oo/OyJhBGHowj9g88t9Qr8RvwsgoZN7kMV9wtaU3gFiJXqHbRMjRdVj+r8NvaLO0FMPMxWje /o6zmOt58wizDj31xMuA3dBgq1vLQfKZOZ21yhzaps1VV610rUtcxaMO2JmznLUQmbHAK0NDD+/R ir2OaLCrXS0X6ow3AVJLDbLLbNHofGRyXZmKpju8hjA6L34b61qvwizSqOVMGzd6FeZoRme4zJqN Wstaw7UHmM/9ljBGY7GYIcgPwfvgzVhlauG8TZhfM5pjg/nPoK+A18H7ITanh5XiYSfYMVrYFd5F nNg8Ng+Fe+EB4myBBYX9ZuueUFPyGfI0+CgarC+vB6n6EzI2sK9W4kpICo3acmqlPACxkE0/5Ecg 9o+1IoS93BtoyyL/Hq6Av+EstUur4YOwGGpOYn15mn61qAuQsXJdtQb1uiPgC/AkbA6x+ryrYClU Ky4Zkifel2Ilety10XkKtq7hutZ26k+JS8jdcBeaKuSZkHmEUXsSW9RgwXrrIda1wZo195CrtAif +uwyg/NuR1Y/A/O7kDlXSLt26aM8teIYC4z2OZuwiFpxFm3HZ9bsKrEPXUaxgBoe6oy+EtKXWstZ 9FU1d4h9RXhm3+7jovFHMbLT0j16aY/Za4BnycdT5NGmPB1V1f9Dn+zSM5jdUOfgu+BOjjLiu/O1 HxC/lmH8cmnFrnoVuCMXz4yLveqSJyZLwnsv1zaymvGcu00Yas6UiexuJzw+HFftinGQUdXVERBb N8B7YGejIpNvgY6beDz8XyOrV4qex8cOMWvE9jMDuPqtpCel5l2xE2pzbPzXi8ZnxPfp5wMsH5++ 0dWcp0x97HaDlyZgrPTP1pIl5DA0fSkjHe/oUY3aRZch9+Z+1QbWe8RL4GNXGLwxPrnt0+9540ht P8Jjz7jfEMMn6C+EuXAoHAxLCPMo8byMzKjkMha7k7FjqZ9mM2WBbRBi44VYO2Ez8grbz6cWGfXP XEv808RPa607y4Ay8j/Xesu17oIPwfvhJHhnXekPsHwFzSyte8jquyAPPbxk7pbawMY8S2sRVD/e PKc9I51lgC/Fzr4d+kMJQ9v0sTwDaEYLI9/V3ATl3o9wF3mcdZPchf+s+Htd/C2GVuZjc7oaG9am oW4b0uOTe55aUFjLXk+s+q+pS9RPr5r7wiJ1R3HvHYWRjdj8zDjcXDhac4zYsKZ8csDn7nx8aAZv WIB1arB4PcYyQ92zc22Hmalo1OpWu442G6pnT+tqlcwKXUZzF9vbxZL0sYdD7DEPX27wZ2kj7jRa yo6aL63+akJin7iM0R612lcPs3q3iqDaHttrX6PfFlntPXzUAW0qwEPoY434areofzVFysKolV5F SCwHH/+YT9r8hhBLNaQfiEcTYoGHjPi+1mTqhk/9CbEKjFo+amPgWw6wXoJKrkiPZ1Ywm+6CTL0K qC2+zm60b+RaPl5Eg4/Xjol7bUgsfxfPrUvpuPSoLh5sF8vTrCQ99HUheRgSQ0gv7WtZX0RIYjP4 Pw05b7Tn1N6V2WVA/AGzg4B5vY/1GKgfdTnWI7Xa09p4RNLpnhTaOa/wjKzsWItRZA+2516Ix98O qf8+nuGAnAmw0n3mJuZKZ5nVaL+HpeoPJg8p3wBrOaA/9NUO/KruvmwYV1cZ8B4bvWutgdqjqs1M 6Rud42g7Zfwy2J9GZ0bMBwO1AxnLAq1XxB8wOvjUK19nbb+ITLBHaQUBJRVg/wfUgYCRNNDxujuy Wq3UW6PpJwdCrPcQC9NPQa81ijHL2uelVm4vNJvhdqGdr4m8Edar4zFmoKXUcOEW9IuF9XylrH+Z TPRtYUfYCjaD/YXWsiplDBI+CJ+uk+1VzFDCfMxVSJvfG16CfqYwXCK043gpNbkUb4yEKUSeBVcS 51fo23Hun9DsRT4Bj6ApJR9uhQ7xo7H2hvBrSHrCG5A/JU6uGzwBD6GfCh+A8wnTD/lz+FDduSOw zUR+FW6Fz5CeXUpr+0TMNPSvEM97yH+Ex+CvuO7ryOPg1ZD021l5KTW2lDms5AY56X2BvBNSOmEb SPzWEiulv5Vze8J30LREHgRXoaHUbI0VjiaGGuInVdaOFb4GD8Kj8CNi+I6UfwgpBdvLiX4gsfWF w2Rl1raFUjwkpcy1hdfDbvB7SInYFi1p4NywD3E2QZ+LJh9moR+B/l00xGmoOeZR9MvhAfgw4d9A vo8ww5CJ39+PhjCmEk1rSP7750JqeDgGkjPWDiylPyxl1Ba9h2Y2+fMcHr/nZO3bsBLnzcMyPyma ANs4oL17WFDeFI4+qpQw3lhk9WasZdxPxVbBb+Mu5egfGeXHcFTDbCJMb/qEBkrR+4wv3p8IE8+5 +Dp89YeUonmTo02Q9yhrR8u8CXkd/EBJCv9KzOrP1PnvUxxdxNFFHNXR8ATpfID4v0G+Gz4CZ8KH 4bfwK+J5Bvl+5AeRe0F8m24MToIr5IruuJoSmQVovnGt/hzVmZF62NSjoqu6beGThL8C6qpfLufe guZsyU/vFvJhMpqb4Ra4D31r9ZMjH+fcc7W8yIF8ZGwSwyq/0RJX7436czagZ5ZnWiIbqBb7xcQ/ FQ6C+FK8QeRzFppxeJ7HkQ9H0YyAYwmj5XsevBwOhtfDoXAAXAx/IN+4X7cHHEZ6tnP0Oa71HHK1 kqvcRJin0dwOKV+Pcvcoce98WJ84qY0e9dM9iNwUGTvE3aoyd7RVruiu0HyGWktbUzqttRSYf+ms sxf6xdjhaqnOJfxCeA+kXpkOyF1hMSzRGTQxYDl7z0j8hhm66S5693DtBVb/NmGeJR716L6I5kVi eAn5Jc1b5EFCo97ppWgWQJ1fjCOeIcj30W9gS3jMwX08UV4/YutHbs/m3L3k0iz0z5O2IfBajmLn eGotX8nV9Y5WIX9NmJWcu5IrfoWGuYx3P7LOEFcivwF17j+bEjnNubp3grUG717C3EsKF2iuUjrF 6JkDuswjvI6qgXfCnvAValeAXLdGj7xD75eUb0ZeCCfAXXAjxJMcYIHHYbXG0Y7i8CcE9I2Besvx Ivqt1NaS1IbUDfd59y6h7GUyD9o5k9gzDt6DQzKrlTuyc0/xhMyAzL497D33Zc69X851n6nt4Mga jejnUS4v27FavJ2H0AuflL1S7oLaauqVcD9nPUn4SbLLyHtAQprPIw2xkRpLPM50q+kn1zJruCK+ Tfd9zj2qFL03S3ZVufe7aY6sW22WfoDdFwW1lVY/W3ZJuQPcVfSTh+gnJVWP21mpeA8OMZr/3srz ZdeTO43Voodkz5X7XO0a4t8lNTDyvfS3sg/K3CK0YU5ILYoskaugmVb7hvRmInuldZqVjnibZzI3 l6tXyp4xU4zFXiXWvrm+totYXOTGbKdAzpI1QXd2bbFcV2gKITtkzFzkfuyNqWbV8v3aVMsvhDYG e+/ep+xras0q2/MiG8Ns5VpinvbDbHrI8dJTyczd/Q+uvl3OdZ+Hz8CH4KNwNuuM08jbo7KCZmvI cTR7udM+MlLj8b7f6YlGyr1aaGuypdlTOwhbUUqWlQV35g89hNSlmWjWcNYa7mUN8T+C5hHW7LoR 22/xnPynzKbd16ktr9euQJ4I9ziyF+uo1OdaSzvLKyDMKCvvlhiCNqTnE0mPu4C7e5B51j3kVQ61 a7JogmtE9kq47jHnNhlfyNWnyOGvZPucnZNKnk8nhU9JDpubaydLKdO++pP+33KVp+CLlP5vNd/I sSrmLMvq6sBqSl+8atOJ+QrutIoZ5dOkcJCkyiTgW1B/zijZNWdri5w1LdLMkX1Wckc9SfkAwk+Q +mlnHFu4isT2NvXnaVKyk/Dv187i3kdQu0itxOmVUeuukZhtTQuoG1Kfy+Rc/zFJie1F3yDmLYwF ssow6Adpj4NqpFyqIi24+g7SI+W7mlHmc2pUkbQFe8WNkk4n23IJPpMJ9MPLZDejbYNnObIaa+nd VtsRTTPyMJu7ljWaCPJr8B2n1pGVBYmNkNb2zuasRKvJhHFC7xLK9DG5uufDU6RtWu0l0kZqW9GT nMPd5coqA/IsYnsS+T7kR5HXwiVOS0f2J1xvY4iPdLZnfVPzgyOz7GwZoQg/u46P2aOdI+25F5tm 8wfna6mrdfeViN5q3OW1v7DnRoU2r+S+vtU70qNwlnOVDZPGVe5V1raFj0htl7R5E5zzLYdzj30I 84bzVxtbKB4MW/e6SFvmKlGOFnCV5yK3OjK6yXW5urumjnLuXbXvkFobv/8nuVNvhKZf7s57Qq5l 5+ZybhHes4eQI+TV/ZI/3lkRybE1aN6hV3wycqmUUW2mZR5MENqySLdcVXuuPesOSrAp6TxQ+x3W RRf6nwhX/yv3fo2M4HW5kSwyJTtcapE3vOZ5R9YysunVb2DeJyHvkXyzGknPm7SgP2gdiPQm/XLX d3O/2TIS+RdIi/BZfwzfE024TjQhtk2ITe63Z0dEe7EffKzckFE1wPdu5mAjzeEoq64+fqqAETYe z0897Kt6HDVPEP4JbJt+aNhTZ65TYp+zNmqw232scf9z5lBvCePwdIX4YeKwFtz9hLkXO2E9Z7HC 6H+GZcI6SIj1HnwIT4s+4B7jdD/ejUo5GpeJ1cFsKy7Cde8kTmwwf6aSMKzIh/dxVL2C2NjmGPLj 6HvDxtirzNr8RCWzTt2pqHetq8a6+kPumWrSryuquvfgFUJijQcXkoc7ueLbpFa9vswRQtbWQ90z M5+cYX4UXomsc7clkHS6WOOuzhaZE7mniPkz+JbK9KLMelzmKa7OB+/iqO7zjCfMrehHyuzP1T0V uuKfRsgDpKQbMnNYo/NcZhzhfL07YtCVNbyLQZrWUuJRrzJrZ3HUojhWiwJdSVFvHruhAt1V8reV X9FwVkBpBuolJpfiWIOOY30n0PXxiaTqffKEvPJ+S/0ZjfwmpXMdJfsCISuoLUXodW9DBeU1TjQh qz8hNdn0owbqOvUznPUyVJlUBboepHMN7Gp/HfGol/JdNO/BV2kXuiLZUe+d+JlfxzXjinOg7qxI 5ChrHIF6XNnRGt6EXv3eun/mas7ax1Veh1MhFr6vOZYCO5M21kd8yivUPbfr0escnxLxa8gr5keB 7rRhfmeizFC+YK6xk7rN/jSj9aQLPcw55PwXcBfEO2Fosz56w8zaNEaj9fM3aJhVhcy4w2QYkIaL mKUytzX4UswMJWlgNh08T2zMiw3ejOAwV6fteMu5yhF4Ek0S97KFmNnhZgqJQef4tfAjJfOjj6hF o7l3+ij3VnKeuY95r47jLDnL7CMNcch9iOd7qPWQ1me2SJx+I8r013UzMhnRzqHsfkH8f4EfkzYX +QTcT/z4QDz8V4Z5ffAr5MGwq7YO5A8g/XPYHJn+xFr+kofsWzP10NSjHFknqqerWm0JozM+Vlq9 k8QwVP1m6mGjvFiNddWLVUg/MwsyF/bbcRZr0B4rUwF5KEsr+Jwd7GdJ4Q2E34TmU1L1Kb0xKx3B IeJhHcfonjdts59C2ppts1Ky0zh3mrYs7oveKdA9aayaGYeSdUin+gl1bZ12GupIR1sLda/La5TU QeL8jvTrHFnLRdvyQNI/DObANKj72Zhl+7oLTu+U8gp1hZrVlqAJ+lz0rHKGrJT5+CL8d5UcJWZb agGeWwfPrcSA58FnTmRYrzEPE7ISfTdInfHJf/9clYkTD2qodYlVzlBXlxgBQ3yD9eiT65EnIfGH +GFC1n1CHWtCakJH6gYjl9/eOUv6OuYFc0SOj5O9l9b2GCFWh2isdbFF7AGuyMp4HKuuIXvv41jT 8e/UkV3HdB3Ndfwl/nXwXfg+fJuYtwqDC9HshJ/BXUI7Op8lozOsgCeELnp3C5orkR8kttHIhLfz U+YR8HE4Fz4l9B6ADppTXHEtfAu+jn4q3ITmG+Tr4TPwLvQbuG48mluJcxL8AM1I+Bp8FX1/aOBv ODcNXgfPIs4DHF3M3XVD8yY8SDz/iZ4cCA6jf4jwv4TFkHywVpCQ3DDE421E1qMvE1s2eu7CJQes 5XAWloOEIQ2GvPXISTsrPwtLQGRN1QukXL1znaknuhfiM1kx9HVlUFvHqzq26riJvgfn6lo5PYA/ VUfGurFPjtZwlVmwGq4inTeREtJs67+EbAy563rUk3q18K+EGQaHQE1zCrKWYIhM3TA+1F1AJ9kz eZJr9ZJ2EehTNo8SJp6jjN2++jy1di2ApNN7CS7iKh9xFnXefQ5NA46SQvcR+CKa85G/QtbaSL1y 58GZ6J9HHgcXQlqruxdyRW8PPMp19yE/CbWs9d4bcpSaadZwVNuOnnsOpOZ7d0Ny2zsbcnVvIuFV n4zMVdwxxKk1k3bkaV29AlKmXi5hbkGm7Lz1kL7X5LDuXEnevkNI3ed5TMdB5BnoL+Ys2rhXCmm/ ATXfbwbLhHGfwD9ztDd67j1cjdwK+ffIzZFfqqsVF4v1gkdlvsj12FNRL1FqRRxrLnEPiQ8qjp0D luJHwkr0PpazQmZMAbsgQvZcRRjTI6yhRPTJBXZVRRhnQ/bMhDx1FbJnw0yR+AN2oQS6i1Wf1KNO mvaSqrARsu5j4Y48+jTvPe7ChRE4r+7usrH8JTdug7dTdpS1S3txH0ZP7+TeCC+F5LNbCb+F2l89 BmlTxhNG6Hki5HyE/tCW3Vk82yjcDulPPFpuhN4mwigQYVxwkyBtPKLtKB+OgpkwnTDU8+AeNBpy Ofpy9AMp2ZbwEHrqoas1k3v3OOquRJ4Az3Bdcsk7j6NNiKEdcdKz+dRJf5uO1FD39rMDxPuevoKU ePRj3n3Ew2joq0yd9FZqyqn5OnNnl1SoPgfdv8dOY5990aHOx1mfNTor0d3y2ABBFXpCBroXi97D Zwwy2hJ3cHdV6BkNI6QhoOUaSiSOETCO/qFeG47SRwUaG63ezs4kPK0soM+0c3Oh7h5nJcjFTnB1 bzN7hFx9spJdVS69qKvPRereMN3lrs8eqv+E2bGraxlqTemuNq357HHydKe0PturK1C6mqxPrzyA Vwofl+2Zhc+iMcgLYc86j5lwC0dbIePR8lU/CJbBGBwIr4CjYRG8FOLD9PAHetnwU/hn+AXEe+Y3 Ua8jJLXeJ+p7RF4L98JC+ALsDNvDsaT5TngxPIqe9m7HDtGcQl6JfCF8EK5GfzfEB2jHfeFX8Ddw M3wGPgzbwCeIIR15BXwZ3oX+KeTbIanyLofqgcTP6bVVPyQkV83H5Em6+hUJswR+CMfAeRyNh13Q nOSs7sRTi6YR5E69DvBVwnMta6kKb0R/PfwSHodvQ7y13k6o/sPPOasrsubnX9BwrqFkTW/0f0Te A3fBmyFeXKNxzkA+D+KPtS03m9FHjk6HN0HyxPs93ArfJCR3avt50Whpvg4pNZ/dVj77r0J9EvwS 9rXqyi/PyrlY9T69SsCcItTnHYqYu81jZ+YZ5rk6p1bfmu6yZrdqZD/+T9by4lgXNvp0MDvcDDMU o0+66ZP4H5MG3TvNjmJ3Nvu0t0o8ds4+TuaAXJHn7u2M/g6xD9mbynMN/k61vkQTMEMM9AkR9jC4 l6G/hb2jETQNIb6RyA/E80e4nDDTkV/jXvABRg4Rvh36YnaoNq3brS1zzy/Zy8oTScF2iP/W132M zOUD9kKbF/BX4DU1ycRD/nvNWQd5kpUd5lMuftrId8zRdDT3kHlGxqhXVueVeINdtQHwpQR4gQL2 8vnsezQ8O+/jT/DwJQb6rI3uimdmZ3w8oowUPjv3Qt0NiJ3j6p5hnX2rF24IeaWepRnIfbkXPEUm RHMpfBt9A3gRvALqvRcSZos8n+hOkLKO4DuN4NuMsL8i1L2v7F30vuUsru51Iw8rZV3J9gPxjjw3 Z+nrc5ePE7OW+x2U0WPI0zj3Ks5lT7i5HX257rFH04Uwcci0CIPe9jMF9KWWnu5lLdc6T3mx29zd Dck3M1h3MjNzZ4zztK25df5biX8CMd/NWcOR7+dZxcsIU4B+JPpW1EP9zYEnOPccnnXdDNXHq08j /oX75YkDjxru4xWxMUjMVUJbi6RdsEIRYJ2aPK6SxFX0CS/8GN4YWqKOzjzXEMGzGtmKl4Yx2qVu uPq84a9I8z1Sq/0W+DHoE7yJ9AwBq/a614uYTRLh9bktfVZ3i6zRe9nEr083qF9O9/b/UdLv6/MF OlssI57OpFM9EnnoH+F+byM89TbC0yjes+SYzlWxsuKZh4a0CMO+o0D8ro7+xklkdFyJ4w2/ffwY p8m146+53pk4ZuiEsc4SqW2/HFCc4rRznNpa5xynvhM45zspTmOnta0j7ZwuzmWO7CR0nL5OpTPS GeOMtzMDDdvACZ0LnAut1MZp67R3ujolzlXyXLVzpTPUuda5wbnZud3hR0UI39CJc5o7LRyxDgqd Dk4353JnkBN1XKefM4xfSp3g3OE0dbzL+/UrcXoMuPKKFCc6cEDvFGc6MYjNWs9JcFo65zo5Tken u9PD6eUMdsodz5GneYY71zk3Orc4vyJ0PSfRSbWx5Tqd7Myit5PhTEJ/rtPI3nWS08o5z8lzLnI6 O8XOpU4fZ4gTs2nNdAZYS3e0M86Z6NxZd9WznV84yU6a08zJd4qcS5yezhXO1U6F4ztZzi+da5zr nZucW53Jzl3DC24e7p4RegbWh01gAkwdPnTMBK8NbAe7w15wIIwNH3rzNd4oOBZOgHfAKnjv8OE3 jPOmw4VwNdwC98JjQmNGjL3xBtMUJsAWMAPmwELYaeT4ocNNd9gHDoEj4Dg4CVaPue7aoWY2nA8X w+Vjxt5yg1kN18NN8C24Fe6Au8fcOHyM2QcPwiPwuD043pyCNULfwHjYCDaFCf+Lve+A06LI9q1T VV3V1d1fDqQhjWQQhjTknAYYSRKGnHMQhhxEQFSSiIiIiDigIquIioDICioiIiIiImJCRUVQZJFl EVHxnqpplZl1r+x179v33m+nf3Pqq+76uqv+dWJ3fX1uwMJKNbScoZUNrWFoXUMbG9ryhuxBY6xM QzsZmjVW7+9j6CBDRxg61tBJhs4wdM54nBFrnqGLDV1m6EpDcwxdN374mCHWBkM3GbrN0J2G7jZ0 3/jRA8daBw19z9DPDD1j6EVNBR0/Pq2q8AyNG5piaClDKxlaA2k1Ud/QpoZmGNrO0M6G9kBaXfQz dJihYw2dYugsQ+eNnzh2vFhi6HJDVxm61tD1hm6cgAiIzYZuN/QFQ/cYut/QQ4bqNfgU5aPQP1Ey 1Byp5Jr/0Sf9DrPfozZKs4XaTOInhRLv/h/aJ3Ff3j1AgldJdVQbRn0T/Rd+pqgFS/83JZACV02p +R4lxoIby6L/NQ1cNU1eNS3xdzRx1bTMVdDY71KG9i3FvHv/6j8VwU/FDE76ff1XXwIp/7uUosWp +E+UQIpfBY1fFa2D1nkuWUYeIpvJbnKYfEbOQypUg6bQCQZANsyBpbAWNsEuOATH4RylNEpTaTXa lHaiA2g2nUOX0rX0OfolK8jKsdosg2WxYWwKm8dWsPVsG9vLjrKT7CK3eUFejtfmGTyLmOiL2Lm8 xk7nrXOSr14hX73aFXVszNOI/gFPbl0QYs3IW5fbr2iPdXXM1DlKZhJntEzu3tCl3DLM/TLolwXz fju6MW89lpG3NwXy9TZlcd560cb56p3z1YflPX/RGfnqi/Ner+ij+b6fD81iKfnqC/LVL+atF8/I V1+R93qly11RR71Rek/eehkv7/fLdMpbvzY1X71UvnqZvPXKwtQp6txoLgKVa/vlC781j1UG+eUY v5zil3N/q3XaLr/c75dH/PJ43lFXLZZ3FqoOytvLatvy1fflrVdfla++Ol89J1990xU8rOub89WP 5Gt/NG89PR8XpjfPO0vpQ/Ie7/9QvvrafPWt+er5xtt/e97zDyqR9/hgrt+RiUgOJSfRmz9tbI3O XUJMnhGMNflEY4GiRKhVcom6Ty6WC+Qi3CNgI2zEU+l33wLqoU2EmjfgMvNmWW7eLGvlnp1VYtey yqyKyZzwmnkrIdU9oN/qXtDduLcy1pMYH2STVWQP+Zhcgjj2xMZvx9VDhKr71MNIV6l1SO/HMYTR qymBelznf6gvNxIGr2LPnjDlEvkklq9j/SlTLpEPEIq1HKRL5BqkS3HEmm8Lk1S5jjAc0WL5iCmX yPVYLsL6n0y55IqWj/otH/NbbvBbPu639Psr7zJXu9tc7R5ztZ+P3GuO3GeO3H/lEbXajPEBM8Yc M8afj6wxR9aaIw+aIxR57iV4CbHXbxYG82Zhat4szMz7bbl5v62l7lUrUSZyfQctozX0jGPsSHFe FhJ9t0nn6wZeieM+MVwMx+9PkVMI/887jf/zTuN/8E7jX7mpsOGma41eWSRa/odn/sMz/5BnAI4a rsmNXyqb/Bx/mFcMZ7iGMzzDGQHDGUHDGSHDGWHDGRHDGVHDGTHDGXHDGQnDGUnDGQUMZxQ0nFHI cEZh/gh/BHlF80eK4Y+ihj+KGf4obvijhOGPkoY/Ug1/XGP4o5Thj9KGP8oY/ihr+KOc4Y/yhj8q GP6oaPijkuGPaw1/VDb8UcXwR5rhj6qGP6oZ/qhu+KOG4Y+ahj/SDX/UMvxR2/BHHcMfdQ1/1DP8 Ud/wRwPDHw0NfzQy/NHY8EcTwx9NDX80M/zR3MxrCzOvLc28tjLzmmHmtbWZV51l5Vm0Ffqe8Vzc biK34jaLzMNtNllAFuORjeQJcpvJcDbf2JoFZC9uC02Gs0Umw9nt5BT5ktwBHCxyJzwAD5K7YD08 RlaY/C2rTP6W+03+ltUmf8sDJn9Ljsnfssbkb1lr8rc8aPK3PGTytzxs8resoym0PnmENqSNyF7a hDYh+2gz2oy8RlvQlmQ/bU1bkwM0k2aSN2gX2oUcpN1oN/ImvYPuIofobrobBH2HvgOSfk4/B5t+ Q78BRc/T8+DQb+m34Jo8ZJ7ODwMBnR8Ggjo/DIR0fhgI6/wwENH5YSCq88NATOeHgbjODwMJdoon IYne1QRozqfy6dCCz+KzIEPnjYHWOm8MtNF5Y6CtzhsDmTpvDFyn88ZAO503BtrrvDHQQeeNgY46 bwx04nv5Xrie7+P7oDPfz/dDF36AH4Cu/CA/CN10VhnI0llloLvOKgM9dFYZ6KmzykAvnVUGeuus MtBHZ5WBvjqrDPTTWWWgv84qAwN0VhkYqLPKwCCdVQYG66wyMMQCC2CoxSwGwyxhCRhu2ZYNI3S2 GRips83AKJ1tBkbrbDMwRmebgRt0thkYq7PNwDidbQaydbYZGK+zzcAEnW0GJupsMzBJZ5uByTrb DEzR2WZgqs42A9N0thmYrrPNwAydbQZu1NlmYKbONgM36WwzMEtnm4HZVj3rPMyxLlgXaH3rovUd bWD9YF2mjQQIoE0FF5w2E47waHOd0Y22ElVFNZoh6ol6tI1oJBrRtqKlaEkzRVuRSa8T7URH2l48 KB6k14t14hHaWbwp3qRdxVviLdpNvC3eplnipDhJu4uvxFe0hxwjx9CecqzMpr3kRDmJ9tVeFu0v p8vpdICcLefQgfJpuYsOli/Ll+lEeUAeoJPkm/JNOlm+Jd+iU+QReYROlV/Y/ek0NVCtoH9TG9U3 rKL6Xn3PbnCUo9hYJ+bE2DinknMty3bmOfPZBGehczub5CxzlrGpznJnOZvm3O+sZtOdHGcNu9F5 yHmI3eT8yXmMzXIedx5nNzubnE1srrPF+TO7xdnh7GSLnBec3Wyxc8I5we5yvnK+Ysvc6m5Ndrfb xG3CVrit3NbsXretm8lWuZ3cTmy1m+VmsQfc3m5vluP2dfuyNd6fvRfZWp3th/1JZ/thj+psP+wx ne2HbdDZftjjOtsP2+i9633BngjUC9RjO7XF0OtfSIZvMar4fkc6/nf6ZQ+QrfhfKl8b7Zs85O+h hFtEP0CzqIWxh4V/hFrSktiWkliu9jJ64iYj9zlaLslhI5fUyCVD3vkGhJ5h2KFnGHbqGYbn9QzD C3qG4UWcvRdhl54feNPMT6aeHzpHj57u0SOjr+uR0Q/wql2MtiRGW4LRltRoS2a0pW20pWO0pWu0 pWe0ZcBoy6DRlmGjLaNGW8aNtixktFxRo+WKGy1Xwmi5kkbLXWO0XCmj5UobLVdG6zdSVus3Uk7r N1Je6zdSQes3UlHrN1LJ5Em/VusltEnnrPNok1CC0A6hBKEdQgkiNbUEkdpagkgdLUGkrpYg0kBL EGmoJYg01hJEmmgJIk21BJFmWoJICy1BpLWWIPQ7UEZIppYR9DtQRtDX0JFIJy0j5HotI6Sz3CV3 ka5aRkg3LSMkS8sI6a5lhPTQMkJ6aokgvbREkN5aIkgfLRGkr5YI0l9LBBmoJYIM0RJBhmqJIMO0 RJARWiLIKC0RZLSWCDJWSwQZpyWCZGuJIFO1RJDpWiLILC0RZLaWCDJHSwS5RUsEuVVLBJmvJYIs 1BJBFmmJILdriTDznBuJ/ewNpel4jL+i3wrLX+WvYjz2Gn+NUP46x3iOv8HfMPHYv4NXf5EnNtb0 tCr24w5zj4aQ8uj5K5SwKsiTVUltEiJ1SUNSgDQmrUgK+gbIb6Qdbvo5YS+M0/vgVoP0I4NJTTIU fcJ6ZCQZj9+YiH5DK3I/eRjlej3ZQHqSJ8kz2O5ZsoMMI8+Tl8lo8irZRyaQ/bhNIgdwm0zeJIfJ FHKEfEhmkI9wm0s+ISfILeQkbgvJadwWkTPkAnoXF4GS5VACyqG3UBGqkEehKlQlT0B1qEuehPrQ mGyDptCa7IBMaEdehg7QgaAVhT7kVegH/cjbMACGkiMwHEaSD2A0TCQfwWSYTU7S2rQ2+Suth/Nx nnanA8kFOoPOBaAr6Ar0EJ6gT4BLN9Mt4NFn6DMQpM/S7RCiO+lOiND9dD9E6acUvQJ6kp6COP2K fgVJ+jU9AwXoOXoOCjFgAIVZQVYQirCirBiksBKsBBRjqewaKM7KsrJQEjnAglQueQAa8RCvDi15 TV4PRvIGvD9k84F8ONzDR/JsWG0NtEbDOusGayw8ZWVb4+Fpa5I1CbZY06xbYas1z5oHL1mLrEWw 21psLYWXrRzradhnbbG+gGMiIOI0IpKiIC0kCosiNEUUFcVpMVFSVKYlRZpIo1VEDVGDpol0UZdW FZ1EJ5ouOouutJbIEgNpXTFYDKEtxTBxC1rV28RaOkQcER/TOeK4+JTeLj4XJ+gd4pQ4Re8UX4vv 6FLxvfiePiB+Ej/RHAnSomtkAVmBrpOVZAbdLtvIgfQdOV/Op9/IZ+V2ek4ekx/R8/IL+T29IH+0 izPXLmlnscp2D/t2NsS+wz7LVtrnVIL9oAqo7ryE6qlG8oFqtLqRT1A3qTv4LepOtYIvV6+qV/lq dVC9yR9Qb6m3+Br1tnqHr1Xvqvf5w+pDdZyvV5+pz/hGx3M8/oQTdxL8SaeAU4Bvcgo5RfjTTlGn ON/qlHTK8Gedck45/rzT0enIX3CynO78Raen05O/5PR2+vLdTn9nIH/FGeyM4PucUc4ofhClK4FR 0VMmKtqC8dA29Ho5RkU7MAZCmcXo52X0eh2MivYRD6OiAySIUdEhtAdvo9cbxajoPbQHOt9N0uS7 KWDi6EImji5s7r8VYW+xkxjH3Me/ItX511ZdMhcjwU3kEPr7h8n35jcRFp4vldZgLXkWSnJd0hSl WedWHUBGkGwyDbXQArKUrCRryaNkE9lOdqF0HiLvkeNomc6RS6AXVHjuNsLcp93N7rOm3OJuN+VW 98+mfMbdgeVm/LTTlJvd5025xX3BlFvdF035jPsSlluw3W5TbnZfNuUWd48pt7qvmPIZ91Ust2K7 fabc7L5myi3uflNudV835TPuG1g+g+0OmnKz+6Ypt7iHTLnVfcuUz7jPEYpHdyHd4u5FutU9gPSZ P4DI22bkT7tHfGTe8ZE56iPzro/Mez4y7/uIfOAj8qGPyEc+Ih/7iHziI3LcR+RTH5HPfURO+Ih8 4SNy0kfklI/IVz4ip31EvvYROeMj8hcfkcM4/qfdYwaRzwwiX/5BRL7xETnnI/JXH5HzPiJ/8xH5 1kfkos8r3/nIXPKR+d5H5gcfmR99ZC77iPyUi4gHuYh4NBcRj+Ui4vFcRDwrFxFP5iLi2bmIeCoX Ec/JRcRzfUTOGkQuaE7xiEbEE38MES+Qi4gXzEXEC+Ui4oVzEfEiuYh4sVxEvHguIl4iFxEvmYuI VyAXEa9QLiJe4VxEvCK5vOKl5CLjFfWRKeYjU9xHpoSPTEkfkWt8REr5iJT2ESnjI1I2FxHP04h4 UYNIQc0pXuofRKS8j0gFH5GKPiKVfESu9RGp4iOS5iNS1Uekmo9IdR+Rmj4i6T4itXxEavuI1PER qecjUt9HpIGPSEOfVxr5yDT2kWniI9PUR6aZj0w5g0hlg0gNg0hdzSn6SYjut3kSkkXKwxfwJXwN l+B7uAw/UYbhiqQODdAgjdAoTdAkXcBqs2FsOBvBRrJRbDQbw25gY9k4ls3GswlsIpvEJrMpbCqb xqZbU7wpeN4InNB54+AUnCIAp+E02pSLgNIDP8CPGBLhH5GUU05sKqggiuJGHOpSj7g0RMMkQGP6 lwt0Pp1PIqwWq0WirDMbSmLWZGsyKetN9iajb0dJYeKwPewVtpe9yvax19h+9jo7wN7Qo8T+TTej 1G1WsvvYKnY/W80eYDlsDVvLHvy7Nv/9ebT3XPAK77maeYJETIs9JveSbpFyRYvqVxyjhFKzqAJ7 8pB5AtbGPMGs8etTHraOMFQQq3TJHsLyYVNfrUusr9ZPvkiQPeLvfcTfC4Riv181qzxCbAW7ly1k i9jtbDG7gy1hd7Kl7C62jN3NlrN7dFRqMCZmTJQ9yh4jHnuKPYW+NEWfOIU1Yk1YM9aCZbA27DrW nvVhfVk/1p8NYAPZIDaYDWFDf2ve9VhYQ50hijVmjfXaY9YUz9+cNcdetmKtCGetWWtisUyWSQRr x9oRifPZm9jIWeNw/LlXb4jfborfaoWtM7FVZ9aFdWXdWBbrznqwnqwX6/1bnGiu3ki//x57r3/9 1Iw1w6u3YC3w6hksA6/ehrXBq1/HrsOrt2ft8ep9kJtsg8OvV2+EV2+GV8/Aq1/3m1f/DTx0FIX9 boJXb45XpNj3NnjFdngVgb2djpF17vmxjW6hj+ujVytT5vwNzeiamnG1MiPKNGPRMoHnt4rRRai1 JNigwAEXPAhAEEIQhghEIQZxSEASCkBBKASFoQikQFEoBsUxPikJqXANlILSUAbKQjkoDxUwXqkE 10JlqAJpGLVUw5ilBtSEdKgFtaEO1IV6GL80gIbQCBpDE4ximkFzaAEtoRVkQGtoA20xprkO2kF7 jGo6QieMajpDF+gK3SALukMP6Am9oDf0gb4Y6fTHOGcgDILBMASGwjCMd0bASBiFEc8YuAHGwjjI hvEwASbCJIx/psBUmAbTYQbcCDPhJpgFs2EO3Axz4XE4C9/AefgbHUQH0yF0KB1Gh9MRdCQdRUfT MfQGOpaOo9l0PJ1AJ9JJdDKdQqfSaXQ6Rk830pn0JjqLzqZz6M10Ll1IL9Lv6CX6Pf2B/kgv05/Q YAOjjDHOLCaYZDZTzGEu81iABVmIhVmERVmMxVmCJVkBjJ4KscKsCEvRERQrjhFUSR0/sVKsNCuD MVQ5Vp5VYBV5C96St+IZvDVvw9vyTH4db8fb8w68I+/Er+edeRfelXfjWbw778F78l68N+/D+/J+ vD8fgFHWID6YD+FD+TA+nI/AeGsUH83H8Bv4WD6OZ/NJfIbYKJ4QT4qnxCbxtNgstoit4hmxTTwr tos/i+fEDrFTPC9eEC+KXeIlsVu8LPaIV8Re8arYJ14T+8Xr4oB4QxzE7RBuh3E7It4RR8W74j3x vvhAfCiOiY/Ex+ITHU+Jz3Q8Jb7A7ZT4ErfTGFOdEX8RZ8U34pz4qzgv/iYuiG/FRfGduISR1g/i R3FZ/CQJRlpUMsmlJYWU0pZKOtKVngzIoAzJsIzIKMZhBWUhWVgWkSmyqCwmi8sSsqRMldfIUrK0 LCPLynKyvKwgK2Ksdq2sLKvINFlVVpPVZQ1ZU6bLWrK2rCPrynqyvmwgG8pGsrFsIpvKZrK5bCFb ylYyQ7bGCK+tzJTXyXayvewgO8pO8nrZWXaRXWU3mSW7yx6yp+wle8s+cpAcLIfIoXKYHC5HyJFy lBwtYzIuEzIp+8p+sr8cIAfKo/Jd+Z58X34gP9SxovxYfiKPy0/lZ/JzecJ+3/7A/tA+Zn9kf2x/ Yh+3P7U/s0/YX9gn7VP2l/ZX9mn7a/uM/Rf7rH3J/t7+wf7Rvmz/pIgCNJdMcWUpoaSylVKOclVA BVVIhVVERVVMxVVCFVclVEmVqq5RpVRpVUZVUBXVtaqyqqLSVFVVTVVXNVRNla5qqwaqoWqkGqsm qqlqrlqolqqVylCtVRvVVmWq61Q71V51VJ3U9aqz6qK6qm4qS3V30p1aTm2njlPXqefUdxo4DZ1G TmOnidPUaeY0d1o4LZ1WTobT2mnjtHUyneucdk57pwPGpZ2c653OThenq9NNx6dOD4xPe2F02sfp 6/TD+HSAM9AZhBHqEGeoM8wZ7oxwRmKkOtoZ49zgjHXGOdnOeGeCM9GZ5Ex2pjhTvW+9i9533iXv e+8H70fvsvdTgAQgwAI8YAUa6Og29x4WbIAN5CY4A38hs+Ac/JXMMXe1dP7YBeRhc29rnbm39Z65 t2XzqXwqKHNvy9F3DuFFsUrkwMvmTtY+HfXDu7ZlF4czdnk7iypzP6uO9673Kb3R+9z7gs4z97MW oo2+FW13FL2DMiQDfdEZeg2R/blZh4GflPfLypAwSZIUVRbrDyj0b2SOKo90jar0S9ta+Gkhxsoe nq8gKUZKqTp6j0LvTi5T9ZAuV/WRrlDNfvlOB/MJ/Qccbwo6I6k0Vf9yh5ZCr6QSRY+WVqFV0Deo TqvjmQF9ZvHz2Ukl9HQo2g30qtGuuIZilKA/Y6lrEb8W0f4FOYUbgTWwRmf2g4exxaPwGOFXcdbW /nla/xNnpdYw+tTfWb5/h937N1m9/5esHf3uf9feiTfFW+JtcVJ8JV1j9zahxXvWWKKd0kZ7o63c y2jhtG3LtWyHrtKmnfodW/b3lkyiDfvVev1sGf5vs2K/WqpBaHvVldYMfYenjNegPQbtL+wQz8nB uf6CHIrewh6xV3raV5AB8Tpy4TDkvtGa4362eXRKXnunBqpBarAaooaqYWq4GqFGqolqkpqspqip apqarmaoG9Vtap6arxaohWqRul0tVnf8ppX8/A/YSe8qLGVZVU6VN/ay0m9azFpoM+uouqqeqp/H djb7h9azw7/Ifua1nh3+FfZTbJVDfteGNiQ3E/2OsUVkD0Yce8k+0ozsJ4dJS3KEnCTtyVdgkQHG wt5IG9CGZCZtTFuQWbQV7UBupZ1oZ7KEdqW9yV20L+1P7qMD6UCy2sT3D9CX6LckhxfgzcnbfCKf CMzqY/UBbvWz+oFlDbAGgLAmWhNB6ugfbOucdQHt8kXrIgStS9aPELJ+EhRiggsJBYQScSgikqIY lBUlRBqkiWqiLjQRuEEb0Vy0hLYiQ7SBdmjT+0NHMVAMh8FiJFr2UeJBsR7WikfFBlgvx8hx8Jgc LyfCE3KynAKb5DQ5GzbLm+U8eE7uki/BLvmy3Au75T55GPbq54DwlvwregWH7QLoFXxod7Cz4IQ9 wJ4Mf7Gn28upZa+0/0xL2s/b79Bm6pxTk/ZyZjozaY7b3G1O13gnvXN0rXfeu0AfD9QP1KdPmnsE FCO5oFnttpC84u9pnWfPXtKfz+Zz+M18Lr+F38pv4/P4fL6AL+SL+O18Mb+DL+F38qX8Lr6M382X 83v4Cn4vXwm3wK1wG8yD+bAAFsIiuB0Wwx2wBO6EpXAXLIO7YTncAyvgXlgJ98EquB9Ws/lsAZvB bmQz2U1sFpvN5rCb2Vx2yx/adyu7jc0z9ze4+W3FzWQVKWzuVNTACHc6STd3KvqYOxX9sF1dUvh/ 0nd9P8acO/deTeEr7tXo56IUPaJR+oknrUFropdUh6JPpe0lekZoK4mQJ+WXxJan5Vni2sKWJGwr G/0wO92uRZJ2Hbs+KWg3spuRFNRYx0hJ1FefkVJaI5Hy9mUFpKLWIqQKapF0UlXrDlITdUczUuvv +lPT9KcKnazvTWF/0k1/6qCnVh89Vo69mkks7NVsYqMFn0uU6Ztj+hYwfYuavsXtoB3GXkXtJCli +lnC9DPVbmW3JmXstnZ77JvubWXT26qmt+mmt7VRd1qkPmpOjzQyPW9het4KtVtr0hZ1WwfSzn9W m4n/H5uep5uxXDD+Hvllj/6E/ix6Z9Ff9lH0vCqRn393ovdRUhDHWsvHnpuxChzrTUSaGXDNWAPy WfksCWI8dYyE0As/R8LyvPweUbdwlKXsgnZxHEF5HFlDu6OdRQajBfmCjEZbcZZMsy/haOag/k+Q u1Hr1yH34zx0INtQN3cnB9A+jSRH0CbdSI6hHbqDnPC95vrYp0F47ZLa9ydNdTRHOupn2eR6+321 ghy46nb63h/7X2r961wMMIjm8lWHK+ai1q9zQTqjTv95H0U9XuGKuail1+PLH2xOiF3CLkeU3R2v o++UsdyemD6UNFdP83v5M21ndFSKkWfP+OoPoa+OHru+f4lXKExKYBxUCXKwxVzQ92EX6FZkITyi V/TCn5Derr9BFhsdNw+9/l9X2PQx/auN+z2zhoWQL3EDbQ0IFf1Ff8LEGrGGcDlOjiOWnCgnouTO lrOJdO537ie2k+PkEOVscbYQx9nh7CAYfZCK/tqYBeaaO9DGCWPjwmjjDpIYOY5bQeSGE6QQWGjp CvOKvBIpYlanFDWrU0qgJbpESlo/WpdJqnCFS0qJoAiS0qKIKELKiOKiOCkryopypJyoKCqSCvr5 NaloVqpUMmtUrjVrVCqbNSpp4nrRhdQQg8RwUgttUzZpIOaIOaQFRqCrSEuzgqWVWcGSYdartDHr Vdo6i5zbSabzJ+dR0s6sIengPONsIx2dF53d5HqzeqSbW92tTrLcVm4r0t2sGOlhVon0Mogy2oi2 pF3MPDdEK05oC7TiQDuj/dY3sNcjx/0gf5SX5U82scGmNrM5ckhJO9W+xi5ll7bL2GXtcsgtPeye di+7t93H7mv3s/vb39jn7L/a5+2/2Rfsb+2L9ncqqQqogqqQKqyKqBRVVBVTPVRP1Uv1Vn1UX9VP 9VcD1Cg1Wo1RN6ixapzKVuPVBDVT3aRmqdlqjrpZzVW3qFvVEnWnWqruUsvU3Wq5ugclgaI+RDuM vIt2GHkX7TDqw5Mo/0XQ90tgzNwRpf1a9EdHknT0QW9E/XYbSntGrnXFuH+G4bxZMMffM43feMWe 38dJf2c6n3nFd8IYWb/Cb5LzxQg59ap+CYHnEA1FqyvWua8ibeEp2ALPwg7YBXtgHxyAQ3AE3mNV 2DvsXfY++5B9xD5hn7LP2Rd8FV/Nc/ha/hBfx9fzR/kGvokf4Uf5e/wDfox/zD/nX/BT/Aw/y8/x i/wSv2y5VsAKWRErZiWsAlYhq4hV1CpulbSusUpbZa0KViWrspVmVbNqWOlWHW+ft9874B30DnmH /7Ou+v+TddVBwlG9MUtY9u+sYUR+5nv5Pr6fHzArSH5vJRmUPcvfVOvVRrVZbVcvqD1qvzqkjqqP 1Ql1Wp1TF9VlhzuOE3aSToqT6pRzKjs1MDJqjFFQJsY8WRjdDMJIZixGLTOcOc48Z7GzzFmJ2nyd swF13TZnp7Pb2eccdI44HzjHnZPOGee8c8klqIo9N+oWdIu5pdwKbpqb7tZ3m7oZbju3s9vD7ecO cUe52e4Ud6Y7113gLnGXu6vcte56d6O72d3uvuDucQ+4h9333I/dE+5p95x70b3scc/xwl7SS/FS vXJeZa+GV9dr7LX0Mr1OXpbXxxvkjfDGepO8Gd4cb5632FvmrfRyvHXeBm+Tt83b6e1G6TnoHfE+ 8I6j138Gff5LGG+JgBeIBgoGigVKBSoE0gLpGAU0DWQE2gU6B3oE+gWGBEYFsgNTAjMDcwMLAksC ywOrAmsDjwaeDGwNPBfYFdgbOBA4HHgv8HHgROB04FzgYuBykAedYDiYDKYEU4PlgpWDNYJ1g42D LYOZwU7BrGCf4KDgiODY4KTgjOCc4Lzg4uCy4MpgTnBdcENwU3BbcGdwd3Bf8GDwSPCD4PHgyeCZ 4PngpRAJiZAXioYKhoqFSoUqhNJC6aH6oaahjFC7UOdQj1C/0JDQqFB2aEpoZmhuaEFoSWh5aFVo bWh9aGNoc2h76IXQntD+0KHQ0dCx0GehL0NnQxdCP4Rp2A4Hw/Fw4XCJcJlwpXC1cO1ww3DzcJtw h3DXcK/wgPCw8JjwhPC08KzwreFF4aXhFeHV4XXhDeFN4W3hneE94f3hQ+Gj4WPhz8Jfhs+GL4Yv R3jEiYQjyUhKJDVSLpIWSY/UjzSNZETaRTpHekT6RYZERkWyI1MiMyNzIwsiSyLLI6siayPrIxsj WyPPRXZF9kYORI5EPogcj5yMnImcj1yKoiGJBqPxaOFoiWiZaKVotWjtaONoy2hmtFM0K9onOig6 Ijo2Oik6IzonOi+6OLosujKaE10X3RDdFN0W3RndE90fPRQ9Gj0WPRE9HT0XvRi9HOMxJxaOFYwV i5WKVYilxdJj9WNNYxmxDrGusV6xAbFhsTGxCbFpsVmxW2OLYktjK2KrYw/FHo09Gdsaey62K7Yv dij2Xux47MvYudjF2OU4jzvxcDwZT4mnxsvFK8drxOvGG8dbxjPjneJZ8T7xQfER8bHxKfFZ8Vvj i+PL4ivjOfF18Q3xTfFt8Z3x3fF98YPxo/GP4yfip+Pn4hfjlxM84STCiWQiJVEqUSGRlkhP1E80 T7RJdEh0TfRKDEgMS4xJTEhMS8xJLEgsTaxM5CTWJTYkNiW2J15I7EnsTxxOfJD4LPFl4mziQuKH JE3ayWAymSyWLJWskExLpifrJ5smM5Ltkp2TPZL9kkOSo5LZyWnJOckFyaXJlcm1yfXJjf/V3reA 5ZS1fz/7eZ4OOkml53w+JeSpEMKQHMaIyDQhBoVqoiSFSIXKoRTpJKHxYjA0hBwnpyLJYUwSksMY jHE+M3xr/Z7tHbzmer/v//3/7/t91/Xa1/Vb977Xve51r7XXXvveT+57O5c573aucK50rnE+41zv 3Oh83fm2833np86vBVyBpcBO4CQQC5QCvcBN0FHQVeAr6C/wFwQKggVjBWGCSYJYwQxBimCBIEuQ KygSlAjWCzYLygS7BRWCSkGN4KygQdAkuCG4I3gseCnkCM2FNkIHoVAoF2qFrkIPYRehj7C/0F8Y KAwWjhVGCKOFccKZwrnCRcIlwnxhsXCNcIOwVLhDuF9YKawRnhHWCxuF14W3hfeFT4WvRVyRpchO 5CQSi5QivaiNyEPUSdRd5CsaIBoqChaFiiJFsaIZoiRRqmiRaIkoX1QsWiPaICoV7RDtFR0UHRXV is6KGkRNohuiO6KHopdirthSbC92FkvFarGL2E3cXtxF3EPcRzxAPEQ8XDxWHCaeJI4VzxAniVPF i8RLxPniYvFa8SbxVnG5eL+4UlwjPiOuFzeKr4tvi++Ln4pfS/gSG4mTRCpRS1wkbpL2kq4SH0k/ yUBJoGSUJFQSIYmWxElmSlIk6ZIsSb6kWLJGskFSKtkh2Ss5KDkqqZWclTRImiQ3JHckDyXPJW+k fKmV1F7qLJVK1VIXqZu0vbSLtIe0j3SAdIg0SDpKOl46SRonTZSmSjOludJi6RrpBmmpdId0r/Sg 9Ki0VnpW2iBtkt6Q3pE+lD6XvpHxZVYye5mzTCpTy1xkbrL2si6yHrJ+Mn9ZkGy0LEwWLZsmS5Kl yhbJlsjyZcWyNbINslLZDtle2UHZUVmt7KysQdYkuyG7I3soey57I+fLreT2cme5VK6Wu8jd5O3l XeQ95H3kA+RD5EHyUfJQeYQ8Wh4nnylPkafLM+U58kL5Kvl6eam8XF4hPyo/Ja+XN8lvyO/IH8qf y98o+Aorhb3CWSFVqBUuCjdFe0UXRQ9FH8UAxRBFkGKUIlQRqYhVzFTMVSxS5CiKFGsUmxRlir2K g4qjilrFWUWDoklxQ3FH8VDxXPFGyVdaKe2VzkqpUq10Ubop2yu7KHso+ygHKIcog5SjlKHKCGW0 Mk45U5miTFdmKnOUhcpVyrXKTcqtynLlfuVhZbXylLJOeVF5VXlTeVf5WPlSxVGZq2xUDiqhSq7S qlxVRlVHVVeVj6qfaqBqqGq4arRqvCpSFaOapkpUzVUtUGWpclVFqhLVetVmVZlqr+qwqkZ1VnVR dV11R/VY9VrNV9uoHdRCtVytVbuqjeqO6q5qH3U/9UD1UPVw9Wh1mDpaPU2dpE5XZ6nz1avUa9Wb 1FvV5er96sPqavUpdZ36ovqq+qb6rvqx+qWGozHX2GgcNEKNXKPVuGqMmo6arhofTT+NvyZIM1oT ponWTNMkadI1mZocTaFmlWatZpNmq6Zcs19zWFOtOaWp01zUXNXc1NzVPNa81nK1llo7rZNWrFVq 9do2Wg9tJ213ra+2v9ZfG6gN1o7VhmknaWO1M7RJ2lTtIu0Sbb62WLtGu0Fbqt2h3as9qD2qrdWe 1TZom7Q3tHe0j7WvdXydjc5JJ9VpdW10HrpOuu46X11/nb8uUBesG6uL0MXoZuhSdAt0S3SFuhLd et1mXZlut65CV6mr0Z3R1euadDd193XP9Ry9pd5eL9TL9Vq9q96o76jvqvfR99MP1AfqR+nH6yfp 4/SJ+lR9pj5HX6hfpV+r36Tfqi/X79cf1lfrT+nr9Bf1V/U39Xf1j/UvDfSl0sbgYBAa5AatwdVg NHQ0dDX4GPoZBhqGGoYbRhvGGyINMYZphkTDXMMCQ5Yh11BkKDGsN2w2lBl2GyoMlYYawxlDvaHR cN1wm3p9zA/A7cBdwIPASmA1sBZ4hviCBCHrAjRncRdwH7ABkeOUtoRuS8hYQsaS5VcCq4G1QNrK CjJW4FixnMsErcG3gTYbaLNhOQeBlcBqYC2QtrWFjB00NEer5qBbgG4BS1pAQwvwHaDfAbUOaOuA Wgfod4B+B+h3YOoIjoRkSxb3AakeZ3CcocEZfGfwBaAFoIXoSwhJISSF6EuIvoToS4i+hGTWKdIe xWglRisxWokhLwVfCr4UfCn4MnBk6FeGOZnDlALLgOXAA8AjwGPAE8DT5GoThOw64DwWy4F7gecJ pkFrGmrTUJuG2jRoTYPWNGhNg/x8yMwHZ76Jw6e/Bi2A7VXQVgVtVZCsgo1V0FYFbVW0rXl31GZg RjMx1kzQWWibBRuy0DYL/GxozkZtNtpmozYbmrOhORtWZZP3VC6nEZI5LO4FUj3LwFkGDcvAXwZ+ LjAPveRBJg8yeeglD73koZc89JJH5pgi7asArQrQqgCtCiC/HPzl4C8Hfzn4ReAUofciOoeMOZUk WAYsBx4AHgEeA54AkmtLEbKuQEsWy4F7gVRrM9BW0G0FGSvIWLH8I8BjwBPA8/jltxx4AmjikLlh bMG3gzY7aLNjOQeAR4DHgCeAtG1zyNhDQwu0wh3LOIJ2hCWO0OAIvhP0O6HWCW2dUOsE/U7Q7wT9 TnTuma8hKWBxL/Ay/sdCGbAcuBdI+SLQItBi9CWGpBiSYvQlRl9i9CVGX2J6tQnSHqVoJUUrKVpJ IS8HXw6+HHw5+ApwFOhXQeeEq6V3OLcd0JObSrAb0AfoC+xrQqqB0OkE/cAJMCH4AeAHgRMKDANG ACNNCMkY0PEmBCcBdB7NuMJdQu8/bg7diQhSq3YA88ApQG0JJI/z3AhW0hFxj9LxEjzy7v7mHgfn BGrrqCSPA/lX7NorfbfqeAogh3J4XFrLs6aSHD7vJvAc8DzwAvAS8DKeYrtYqSvAa8BfgL+ivhb1 lixSXZbYoS2h0RIaLaHREhotWY02kLUB7cDiOeB54AXgJSBt52Bqx8eTlOAPFGkLQh8ETXUIWaR8 O0jaQdKO5RwETWWkLJ7DU4BaPAecObw6YD0QzwLeRWAj9vlyVqoJeBV4HXgD9SdQn8ZiHfbyA6Dr gQ3Ai0CqMY3VWAXZhaCzWawD1gMbgBeBtF22qR2/Pb2iBEsp0haEPgCa6shjkfK7QrIrJLuynAOg qcxyFuuwc2I/pByCdcB6YAPwIrARe2M5K9UEvAq8DryBeswHY8ViHVblAdD1wAbgRSDVaMVqtIMs rhXjxGIdsB7YALwIpO2c2PkYi1GOxSjHYpRjMcqx0CFmkfIjIBkByQiWcwA0lZGzWIe9hV5BPvwD G6ADUEiQR30R4oeYyu1s+Y7/A+4RUz2faYC/4gK0ggY7imaTKcdsODhWrNcFb5NfAlxL7x7QlqBt QNuAdgDtALol6JaghaCFoK2hmfSP+8hkDfHZWE/NxDXZJjX5sfw9BM3gCZlhXZjxDxN0g20WJs8V fAvwLfA8t+BX4P6uxqhpCX+WcCkeIiPMgKfWjPVYq2EZpa2hyxq+mDX/AMZ2iOiwwYzSWQJCyg49 Nic0j/ip1eA1N/HQkz1k7aHXHrUtQLcw0ZBsAUvpDGxny0qUJssdWMsdWaStW5oQvRKE7S2hyxk1 zqghNDTScp+pRK8CyAhMNFoJYKuQvxt4CFiBNXOQXUPVmA0RdiYRWoqhBSuYIwEtYb1aSsvgE8pQ K0Mfc+DzVAGzgXn0Lw/UvyJPW1NZxpbv+KXYw46RJ4appHvxOnhi86Ehg64kcynl0P/vAd9yL2pN niS8Zv5qIP3rZRroNNBVoKtAZ4POBp0DOgd0Hug80AuwaucQG+huZ7KZ+KGs92ninsfZcpM/jlU7 FzMwFzPwPaxKBScVnFSs1FTMNfG3MV5awiPHNUmjV8O8A/zOdDqzvFOY3/noYwF0LcC8L8BKXYir V4X1WoUZpbNEV04GZDPQbybWRya7cjJNPPS3GC0WY6YXo0UW6CwTDcks2EvHXsaWR1CWsnNisn8J i7R1jgnRK0GmCjNMdS1DzTLUEJ8c80jOGPoczEVdLnrOhXQubMzDOs3DSPNgSx5rSx7WCpeTjx0y Hy0LoKUAdCHoQtZDp3QRfPMi1BahjwWmniBTAE9/OXAO/xnB23T2+UkMnjzw6+yATkAx/pYmNq0O 6l3SmcH5O34pnkKmenPTeiGe/DF42nvhLdNVfJ1yzE+AY8N6y3hLoOuRIP17vRVoK9B2oO1AO4F2 Ai0ALQAtBi0GbQvN5nS2qXcNa5xMa5mUJq7JNrnp/YOuZcYCXj12WgY7LWOEbc1MbxzgNwO/GXzs ZvTa0LcMjNrKtC6IxRVAcvUsOPCwrdk3jWOwjNK20GULH9qWj3cMuqLpmwZ02JsQUvboke6nPIp0 bTEtTDz05ABZB+iFZ0fmktKOJhqSjrDUybSKUB5BWcrOTBlsawlNLdFaYEL0KmCOQRf2UvKuQWuE qBGaVjTlQUKEOpGJhrQINorpiiZ4CFiBtWKyRWxa0YwEXooELaXQAo+RkYGWsW8h5/GeQd8/FKhV oA9bU0+QkeJtRg40x4quopLcdngnML2XvP+uILVYCMwB5gLzgRnAQmARsBi4GJhNke4uBGvB2Ur/ V4rFVqLPVOawZS5b5rNlBlsWsmURWxLtFq+pNQRzgLnAfGAGsBBYBKTWKGG9EtYrYb0SdithtxJ2 K2GxEharIa+GvBryaoxWjVZqtFKjlRr61WirZtvSEarZEarZEarZEarZEarZEarZEarZEapNI7SE xZaw2BIWE8wHZgALgUVAaoEWFmthsRYWa2GxFhZrYbEWFmtZ+cXAbLyLVgPp9XGFHlfocYUeV2hw hQZXaHBFW1e0bYPadiwWAouAxcDFwGysqWog7cUTvXiiF0/04glrPaHHE3o8occTejyhxxN6PDG/ nuz8erLz68nOryc7v57s/Hqy8+vJzq8nO7/DML/DML/DML/DML/DML/DML/DML/DYEE3iwXApcBl wDzgImABcDlwBTATmAVcQpHuHQRPgEPH0A1ZFWi5lC2XsWUeWy5iywK2XM6WK9gyky2z2HIJKblc H9jqA1t9YKsPrPSBlT6w0gf2+cA+X8j7Qt4X8r4Ymy9a+aKVL1r5Ymy+aOvLtiVjs8ykGgguBS4D 5gEXAQuAy4ErgJnALCCdnb6woS9s6Asb+sKGvrChL2zoCxv6woa+NFsrwVXA1cBMYBYQOjHjfTHj ftDvB/1+0O8HzX7Q7AfNftDgBw2DID8IMgGgA9A2AG0DYFsAW1sAXA5cAVwJXAVcDcwEZgGpbQGw LQC2BUF/EPQHQX8Q9AdBfxD0B0F/EPQHQVsQtAVBWxCufxC7noLY9RTErqcgdj0FsespiF1PQex6 CmLXUxC7noLY9RTErqdQ2BcK+0JhXyjsC4V9obAvFPaFwr5Q2BcK+0JhXyhGG4rRhkJ3KGtrKGtr KGtrKGtrKGtrKGtrKGtrKGzlWj7AinuAFfcAK+4BVtwDrLgHWHEPsOIewKYwjCEMYwjDGMJgfRis D4P1YbA7DHZHQD4C8hGQj8CYI9AqAq0i0CoC+iPQNoJtuwRI7Y1gxxnBjjOCHWcEO84IdpwR7Dgj 2HFGmMbZzJnaQXApcBkwD7gIWABcDqR2RMLuSNgdCbsjYXck7I6E3ZGwO5KVXwlcRfqMZI7A8kiM JRJjiTRxcP0icf1i0EMMeohBDzHQHQPdMdAdAw0x0BAL+VjIxIOOR9t4tI2HdfFsbQFwOXAFMBOY BaSWxMOSeFiSAG0J0JYAbQnQlgBtCdCWAG0J0JYAbQnQlgBtCZjrBPYaJbDXKIG9RgnsNUpgr1EC e40S2GuUwF6j4bhGw3GNhuMaDcc1Go5rNBzXaDiu0XDY8c4HWsiWOWyZy5b5bJnBloVsWcSWxeg1 kj7BCOYAc4H5wAxgIbAIaPJRTH7JQrbMYctctsxnywy2LGTLIrY09ZqIXhPRayJ6TUSvieg1Eb0m otdE9sltelovZMsctsxly3y2zGDLQrYsYktTr1noNQu9ZqHXLPSahV6z0GsWes1Cr8vwS/ViE8KX zaF0s7OglwFz2d+3q4GUXgE8ANwELEFtCUvXEVwLegPwGH7ZPmRCeMlHKW0lBA1/nVvN/ip+DEjp 08AnwCZgHWrrWPpngg2gG4FvoP+5CcH5A70Em2qBb9nf0o8BKY2/GvFcgS2B1qi1ZmnSC685aEe8 4f4nY9t/Mrb9J2Pb/1TGNksOY8okw/1nOW7eZaCxInd1J27Se5FOlOPNnfNnrBFzlXOXK+UquWoi 4Up4ntxQbhg3ghvJjSHv7gkW5RaXaAz5pw6LRx8eRMuHh/ofD0vBhweNSf/k4frR0YZGrH9weP7j Yen/4UHG8heH5c0PDzLmD4+ITx3NbD88yCx9eCTh+PM85qMjlhzxf3EkfOpoNvijI+SjY+pHR9qH B+f/xQgrhtPIkXC6cnw4/chTgH6D8M/vDyaS/XoBJ4uTyynilJBdfzOnjLObU8GpJDv8GU499XyQ xeD/FNX/JfT8r+BfxFHJOTa8U/wksxfmY81LLGIs4ixSrIqtVlvtsNrP+e+MbTLFc9mQQs7oOfR7 uxymmH6VEzFZm5gt9Cva9K9BzFZmG6FpBkges4PZiSiOXYTezewhNM0GyWP2MxWEpjkhecwhhn4/ hWaG5DFVzFF8D6Sa0MeZGkLTLJE85iRzitA0VySP+Yk5S7+JTnweHnOO5uVH3kgec4G5QL8rz1wk 9CXmEqEbmSZCX+HOI7sbzSTJ46Zx0whN80nyuPN59JvBNKskj2fknaHfV6a/iJInXCH9pjv/Nw6P f4d/h9A0zyTPzNtiPocx+eMW22yIncg5ybP52bYbB9/ywQxxOVvZL8rQ/O9cNo5lO5sPs5zQNBe8 KaaFQUZ4LiJbGOSF57JfRKHZ4bmIcmGQI970dRQGmeK5iHhhkC+ei7gXBlnjuYh+YZA7nsvOA82i ycM3KUwzYBo7gwgZhteOep6Ik2FoFnhC02gZhuaCJzSNmWFoRnhC08gZhuaFJzSNn2FodnhC0yga huaIJzSNpWFopnhC04gahuaLJzSNq2Fo1nhC36QzjBgbhmaK53ARacPQfPGEpvE2DM0aT2gadcPQ 3PGEprE3DM0gT2gagcPQPPKEXs9fT5DG4TA0mzyhaTQOQ3PKE/p7finpi0bmMDS/POFs45M1xj/N J1cNsToMzSlP+DRih6GZ5QlN43YYml+e0DR6h6FZ5glNY3gYmmue0DSSh6EZ5wl9hX+NaKNRPQzN Pk84NLaHoTnoCU0jfBiaiZ7Qt7GiaLQPQ7PSEw6N+WFobnpC08gfhmaoJ/Qj/lMiSaOAGJqtnnBo LBBDc9YT+hX/NamlcUEMzV/P4SI6iKHZ6glNY4QYmrOe0DRSiKGZ6wlN44UYmr+e0DRqiKFZ7AlN Y4cYmsue0DSCiKEZ7QlN44gYmtee0DSaiKHZ7QlNY4oYmuOeZgszkxNaYaYgNI0vYmi+e0LTKCOG Zr0nNI01Ymjue0LTiCOGZsAntIuZC7mnaPQRQ7PhEw6NQWJoTnxC00gkhmbGJzSNR2JofnxC06gk hmbJJzSNTWJornxC0wglhmbMJ7SXmRfRTKOVGJo9n3C60PsXXwxh8MUQBl8MYfDFEAZfDGHwxRAG Xwxh8MUQBl8MYfDFEAZfDGHwxRDGYivdARAHxdC88BwuoqEYmh2e0DQmiqE54glNI6MYmime0DQ+ iqH54glNo6QYmjWeQ1P5cRDxyn4bURBKSidwOYJgY4ogyLyZa2q/1Ge2jAV3VYrgc8LqzWUYd2tj M3Oz1nY8rtiMYxxjbtXanOEzKV5ccv8EGAcb27zHkZbIk6TkwUiPQZyx5CUoijwWx5EXnHHkdYgc RtV7yvhOT4a2M8/fEtNlXEqwf4qkKGpR5WmrVSkO7sYU/mhjCm/AKh6X4XKt3Da2uOj/NnjF8Yp3 rWXElGj31sZW5rwv+daO6l5R0dNjwieExSpdQlop3Tt39lL6hYfERE2JGh+r7BUVE+3mLjdKTcIt P6yJihkTGx41yV1lVNB6nqPwz/ohUVGxyp5TY8OiYsJjpxvlAlujl7GTB/nn6W70GC6wdfcgpx0I k/wbbpyOuSJKzB25Xwa4Oxpb0BNLR6uvxkwJC580IZZ0Y2+0o0wLR4sh40InRk0KfWeY1V8ZpjGq TIaJ368PHacMCJ8wiWhV+vfqaUxh1Ebbv19AhjHj8FKY5hzCt+KmMAxn5/RZdSO39e68vv0m94YX ug6fx1e8UhRX9Z5873Sfm2cXHfpmwJCxjwu4h/zqP49sp+0+7sdazU7rfjtnT73Ue9+GxXb+R3St H6761VajON1T+3JswUlR778t7a8oOLGtnfpQ/7Yzo863lHsv6mzf+dK+Vo/He7dlPN6+MfRbuz2S SSt6tXtryOyUF8GrkufOyyx9WJ7z7clOa/3nCQxpAy8Zn3K6Pa580S15f+rvkZ3XubV/Wua2xWrW 2Oxp44vyp9imbnl4+JFy1yCHjJDjbc579Bbd3dM/19s/QFg7fvD0Dd+nHQ3svjLFP32S2Q8dDiRo 9w0Z361gYE3rRM9Jc/uany4+1T+VOymVs6Yi7XIAl0cW/rfJL43Jz4yOZDplOr6N0crckixdMzML 8lhOLqFchp9caEzOS7IfcSr6XnhMsWZwotNWv8y3x1fH/OvXW0pzzgHOwq5d01uc7v405M7lHsbm 1EZHhnnLNzOSN+i3Rhll2PGd+U41sto4TvSILQ8aDg8sHOzr9q1vyH2jNa1uzueT2yj1vVuHR1dE wsbNif31D2v3DowtCTLEuk7dlvrHxgE50zh+t6p/E14MP2JXMvMRt1dldVrN84Cagyv3BUbdD/H9 zpdzN/do4c/ScuuVItuccw3y71vNuvf72imbFjd2zuyWH7G308Qz6Vs0f1y+VRfeLDt935srnD3t Hz2b+cLewc3st1a5S32+cZm8s9PiJgvbYyPDTuxL6vnN+PV7du7JbF/9kGc/c8aTM00+lxPeXLmy 6c3Tyz/bbouuW3Jt0I5OJTPbnu12ob31WC/uyuQIzfynwSGLS4fv6Xxu9KIv54o9n3jnr0qxKfl6 4bY2O1f/7fjGBuWOH42ieUonW9e9Qx73bBplvLbEJTztQPTVR+s21ib5xMTZkT1mBtljxrJ7zBhz QzL2Qsv37yMzss/8G+9quuF0IjuNh4e7R/sOHeiGYzS601NPempMnvM/YpstFg5Zuny/Qf5D3onz /kL8n+49+2LK5v8qXTmvKrZ8dDCvY7eiPwpmFLbqoy5dlxbw+90+XapGmFl/tX5ntVnNTwPi+0bP 2/bL8csTfv32j1jD0gkrzy3g+Rornx3bfayLzDLQd5DA0vZFmShsg1b6yuyrebeODLRQea37rbZN ux0+J1Rm6+pu/OTyVZVkRm2rjhYnir+s2fNA/dt6zRrbVgdfnTo0vHtIt6o2n1snTJ93P/3e5H29 hl/7dpvtoy9f6ZquKn/6tXBUzt8827rM/kryZYSNh++98ZFR9zsV3eN+X7j6Ur6FvV1XYfjV6QP7 ODXtWnRq6sSiTZyitj5PBpcPfzyt95xbbjNb7xl5QjTG5fucXlZHInzebvfYvKaVutH55k/s3vPc mPzk03vPn3ex5vQU1wH7Xv2iejlZXtDytODF4bULcPlkzeldT25kiyTsGzINX2h0Tvr0be9LBRT8 bkZvY+dVXqs6pHqGxcZGd2nXLiQm0m3iu2voFhI1sV30N+GU2y46Jip0akjslHa9AsjCcyMsY793 FjIMv6uxi7HTu3MjN7UNqzA+Pv5TCsfFvKcp9qMbCrtPr1YnQ/ZFXpsy8VDBuYk26d6V/abM0NW2 ueqVsKL9yn2a2v2X64Ont/jGcbCSCdkV88zyWuWswa7OLmdP/7rc9aTQ9ozj5OxWdwL3vag7Yttu y7i2E/16twqMmTvoszMRsp5jv5senHm/Kn7Bca6L24qqota/7HJtdulO3tVfZmSMsk8PWH1p9KD4 /Mmj14/onP3TRgeF2a1Dvb/76eDgXVvKL742n8t5HPvthbc1slUaM4vrhg4H87JEG1JGG26+mtta fpp/PPNkiu259X69ekw903gp/t6C4G+ap4UuLtu9c/fGCUNVvTf0D/t16KiFTsETpt3JCubZZ1uu 0Crzbl7mtIj+7sXWmOidm68eXOnMJbvPCrL7zDPtPvYR1gWDKji6jS0u9FYEzZhQ8vEe9O/xdToa O7t3NLob27f3oltPZ3L6b/B1hoZPHDcldszE6P9dX+ei16RXW4769J8sPFrbr3tAxcuNTrvbeOxx GDTk6Jzfu3ue/9x9icuO7NAmhf/c3Qe/OD3b7Pm9qfsXVq3/eXN49PhphvE3d+y8N2/Xibsb/nBY Yz1M3ardyR7nA/mSuO0TQyf2H3rh0oPGH1fOqUq6PHsA1yvnSUWxZaA8rO+J8xVxwe1m7dDxywJH REhD3ibN7Hr3Z77Or3N8rMXIg8H1qV5tph6zuy3v3Gxm3JsVkZNmNN3pvjiveLLd166DhGNHexSf mTOwtTo4rPfCxnZz7f23vtguzoi8q1vu+Py4/bl5do9T4qZ0rFw2o6RmtPkds9JUz53Pc0bM7Tk3 aF7OpFJFm341UUW9miJuztZnfmPab1IYFzIj2k/tOJb/f3g79ubN2DeLlgx1YTjvbZRRNwd+lrer /cYvUhfvLbq9ybtnr8pTRtHfGzhx+TZyK04AZyp5C+nF6fmhJ/QPbtQnNqgcvxbuB2f672mRuXqM BWO3KLp3xr0pQ/d91sys7dvywQHzpL93zt75baB146Id3pLTrzatO7bzh8EqSZRleOI3vBJ1n98j yybOVJf3+Wnuo4zm+y0WdDzwW+Kt6JG9Vy45U1N7KbPiyo+uJ2beObbZ4+e0XcdDDnc8LVT9GNfo XbhNMqVYlV5fVuYwdNHjooPj+he66ItGL2juXeU4blq/PSe/n9NlUOnYoEbjrVudZdfmP2zonPzC UbUoNCnEnJ/7sJDbq11Cn/Tdb7nnx73o39jAi126zWySTc2Kiy5jZvZ7IChqoerElaZtMj+S61H+ S4/KgG77vpvfeHO8V8ZjdW5RTWn80MFd6mJ8t2qekg1qA9mglvzdPcppC/eo2b/PPfqHjQDukdHL owPZmjzcsUd5mk7d6akxedu/wj0yGHWmU/mkXuHRYeNilL4BvZW9AwZ28erZyaNtx06derbt3Kez h7vOqDGNSfrhmNoG0EEpA8bFxIWHjPun29uyZCulj3DwjPPLfl/+x8W006/sFjve3uDl4hD3xs9/ Y1ye69K+Td8FhnN/yUn0m3dh9uR7UzkX9vSKfBW1afL91qdnLqnNEaxYfWT3i2eJl8ZcaWuUF+nb xn12o09u5ub6+V71NfcenRxx6HVY08PQxctvHnJ48e3+ua/rFtaaddvHxPkbeM/n7nROzRi9f2Sr Nl1P/u2P/OEdZIOcKzrVy8d81q3jtkCnlvHLvO1fckqXXh3ptdGwJ6RNP6fkL69F3v6u9bKMdLvE bzl/i9da5LtG88pdtVmFjUdK1F/8OGCYefzQmF6l3UMvLZ1rGbTjza20z5t13Lbtued3iQNKps/2 GNbKrnj7k6auxZ/d6eP9vjv154bgsiz9R673bw05u2f1af7y+OPEFW9Pf+ApfXLH+L/xlGKnRIeM +W/xlN5piv30Zv2B/2de8andinN30+urZ9LHV7e6NnzXCU5KoiD4iHaYw571z745l/Ym4/j2OIVE /fTZleqyXT0Zsdf3/bxyo1/WeK5zWVRuvSPW0WXntqlXXJtdXTjocv5neTvbOyTftr8ku7g79ORA f+8BC/4QXdJt/jk37fYXh3+5/6KnYCTz21fps+Jm/BL1Jk25aWnRosIfvxavamnUNpUkjsmWtWp1 6POsLr3mzL/b+POcS4PadPD+tWdPZgPHxvph3eeSWp+MhNJHbTNGtrqyP2N2dsu4stGvnAwbohxC fFyCuizwXtjj+s4jNUu+kvYJ/Gbx8SV+gWac6ufGHr0HXhal73tif/+S+LKLvGzww/gm/bU9zZId Lsq7nOrtnsIvIDvWMi7DGJPT/o2vbB+8SP75U9eq5MP06cRetmY8d5v3f0cj/f55Zu1uZ3y/tiXZ Nf7ekO9OlnrAgS2HFBMnWZ7pnR19kj/76YGW1dXG0Pea2LgHGoeuck1y4fhxwjkhnBhOFH6KG8+J 5Sg5QznTOdHkbALhjyFUGGf6an2S9i/Xaez06KgJMWOiw6a3+2hf4qcwnMKIupjU8G5tZukUR547 rWj/w9Kkk4YR85jZP655Lhw2tcOGnoFnKufN2ph//4hAM7e274gSh+odV9N2F88WTfyu2LZi6nyr MXOm/3CldWzFsqbe2vWvrh8+v/31pQ25Pr91mxKvPWa90bqfd9OU7stvbk6qqk8Iykxpazlj2cjQ hZ2kt7r0Gbu+dMSsewZngVoYX/FDWMCjFUszGtR5jS9vWRweYd8mMGJwvHTTlR5//PQ8qlud4WqK dXLHiqUOrvtk9/d0XTrH62FyC/PXk7MC7Hjr9jR/smf8zXynr7yqU7Pv2yuDfvd+VPdlWe3q9JDL oTGubsO9p16zyVT99mznjP6vT2zrl5LzqNeO6S3WrU7hKowpXMmf18jcPYVrQ1iW//LF+PED8oPH tgW7GFeNNArfX4nWf/7sy5A+/15j5t6cPF7pk9ToTp6pHuR5+vFCnJZ15kJGgK31nm1Fqa0Dvl4Q 4rs/+KPdiS6RReF9zp6qlFlEXrdP7W6Vwjv145obu18McY/mzlfcywo/1sPpgP+z24++2GIeXi46 GbDGp3s8M++0asgqG7+nbp6i8u8DctuO8mmZEDj5hl20c3eHgIrzA+ZE7GyfLnu9qYfby4wL3rHf D/46wPfAiARnkZpxNf+i8ZgoxOr0tXYt/gg6v2mm5SW7uHW+PPvB/t/F7O7m80Or1ittUyOsXa1/ sitenXekh9ezJ4nj90efn1T8cHvJVz/7Hl0eNnjIamFJdtfxaknt3tXy3mHb3DZ63zx586l6/o41 LvXSjhOuy58EfhW84O2AifkpXbXnLrzq/0V7ebLF709n1odPNpvVb3Ji//vNT43xSVLoJvwvpWdR Qw0KZW5kc3RyZWFtDQplbmRvYmoNCjUzIDAgb2JqDQpbIDIyNiAzMjYgNDAxIDAgMCAwIDAgMjIx IDMwMyAzMDMgMCAwIDI1MCAzMDYgMjUyIDAgMCAwIDAgNTA3IDAgMCAwIDAgMCAwIDI2OCAyNjgg MCAwIDAgNDYzIDAgNTc5IDAgNTMzIDYxNSA0ODggNDU5IDYzMSA2MjMgMjUyIDMxOSAwIDQyMCA4 NTUgNjQ2IDY2MiA1MTcgMCA1NDMgNDU5IDQ4NyA2NDIgMCA4OTAgNTE5IDAgMCAzMDcgMCAzMDcg MCAwIDAgNDc5IDUyNSA0MjMgNTI1IDQ5OCAzMDUgNDcxIDUyNSAyMzAgMjM5IDQ1NSAyMzAgNzk5 IDUyNSA1MjcgNTI1IDUyNSAzNDkgMzkxIDMzNSA1MjUgNDUyIDcxNSA0MzMgNDUzIDM5NV0gDQpl bmRvYmoNCjU0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDkxMTEyL0xlbmd0 aDEgMTkyOTQwPj4NCnN0cmVhbQ0KeJzsewlYVEfWdtW9vdEL3U13szXQDQ2NCIKKCy6Rls0FURFa QUVBcEtiNLjvZE8wZtMsZjX7YhKbNkaMWUxi9t3Jnsk2yWScmeiYyTITFfjee08XosnkSf7v+//5 5vkpePt961TdunXOrap7iB3GGWMufGjY5JKqcWOOr/wunUnvpjPmvrS0qKR6wKo9zzH2wc3olFNa NKF4Y1S/IYwdLGFMXzOmpLTsT89+e4JJBwcxJh8ZM3lS1cKmEeczduRFxm82j6kKFj33yRddTGp9 m7ExsyZV5Q388cv3DzHG38dd6xsXNSzZdscfdjLWpx4TGNu4Ypk3dNOBg4zVor82ad6S+Yt++KHC zFjOfYxFJc5vWLqEJTEf7o/7Mdv8s1fPe2sZ+4yxWUcZG/nwgrkNTV9ldJ6B8WeifcgCGCwP6Qei vhX19AWLlq36/L7EUsakAsb8/rPmNp+jG/2jh7G9mJPRefbixoZPPj6Yx9hN2xlLKVvUsGpJar/0 23F9O673ntOwaK5/ReV3jD17grHo2CWLly7rcrOLMR+n0r6kee6Ss3ZKnYwNPoDb2ZgSW+2t7Wvy 9zbMto78niUYmFL2/XXdqwo/l3bDmuPHOjZFfa1/FNUoJjEquE7HOhk/YNx+/Nix7VFfqyP1KPI3 isWaxuqZVjVIzMby2FzG7FfhvmoXTTa/Cq0G7TZtPoZMIZbfZBdLzMAkq1aSJI0saT5nUleAPdil zgClosrrZQG4Y6M56G+V/F7Gb1MH3aONVjzF6NEnZ8PfwNO7XXkuv71oSljDz9q/Zg+e4vGhU+v/ qsgPsQe1ZjbjJ+OdOHm9pPl1Y6l9NzP9KePX/fy1uvdw374/36adwBp/7f2Uokk7OY6m5rQ4PMTG /Nw18lfMeso909gDv+We+hR2xk/mkcn6/5Yxesv/f0V+h838rddoBrFt8hw2/Vf2rT/lfsdZ3a+5 TjqXZfzWef2/LPIBNvjX9FNiJTR/l130W+7B/9L1Tvf97jxlnG0/11/XxLb1vN9P5lLw655Zd//I WMozlF4+dVw5lVX+mjGkh1nqb7nnf6dgnlt/bV/5Fpambf/pM5RXsiz5Npb2E3sWq/3vzq+39Jbe 0lt6y39OkW7iRqHl3b/8/uZdrK+UzsYC+yQtu/7//uwwv6Ws9Df1X8QuAtZIy9hTwG/KB35N4QfY Jnkw2/Q/PW5vOVnwt/v8f/ccektv6S29pbf0lt7SW3pLb+ktvaW39Jbe0lt6S2/pLb2lt/zHFzmC JPoWGx+JGpTch2m4F4Y+zMs0TPlqnIWlsSyWy/LZCFbIRrPxbDILsho2g9WxNWw7e8hr6+pSx7Tg mkyWg57D1Z7FbAKbwqapPRu6e/Ku7yNTeByI7nq2e0oZcjpjXY3Sc1/MiXy3Lh3zyAHnqrUcjFvE xqq67KQn8nj5evk6eYO8UQ7KzXKNPE2eymJYPHzzq/PJw3WjWAkrZeWYzXQ2izWxBWwZW80lbuU2 nshTeB8+mU/ndXwhP5sv5sv5Cr6eX8Y38cv5VfxGvpvv50/z5/kL/FWm41+r9/3m9O//oS5Fvi0o sV8u/OTMu91QPVCV6kW3/W+nPDbFN1IVTPl+KPuJp6yHr6zbW6b4q17XApwXmcb/if//u4v8Pzpa 7174xbUQGNM0e1bdzBnTa2uC1VVTKidPmlgxoXz8uLFjykpLiotGBwpHnTFyxPBhBUOHDM7L7ZfT x5+R7kvzxDvtNqvFZIwy6HVajSxxllPqK6v3hvz1IY3fN3ZsP6Xua4ChoYehPuSFqezUPiFvvdrN e2rPAHrOO61ngHoGuntym3ckG9kvx1vq84ZeK/F52/n0yhrozSW+Wm/osKorVK3xqxULKqmpuMJb Gr+gxBvi9d7SUNmKBa2l9SUYr81kLPYVzzX2y2FtRhOkCSrUx7ekjfcZxVUh9Skd3iYxg0W5bUjO KG1oCk2urCktcaem1qo2VqyOFdIVh/TqWN6FypzZJm9bzv7Wy9ttbE59trnJ19QwsyYkN+CiVrm0 tfWSkD07lOUrCWWt+TIeLs8N5fhKSkPZPgxWPqX7BjykzbD5vK3fM0zed/jrUy0NEYsuw/Y9U6Ti YneY0C40w9wwQ/iXmqrMZVN7gM1BJdRSWUN1L5vjDrNAXnZtSKpXWvaLFldQaWkRLd2X1/tSlUdV Wh/5XbEgPtQyx9svB9FXfzPwi3ZvSPbXz2lcoHDD3FZfSQnFrbomFCiBCDREfC1t65+H/g31cGKh EobKmlCeb0nI6SuiDjB4lWewsKpGvSRyWchZHGL1jZGrQnmlJcq8vKWt9SU0QWUsX2XNXpbf9Vnb IK97Vz4bxGqVeYRii/FQ/KWtNU3zQp56dxPW5zxvjTs1FKhF+Gp9NXNrlafks4WyPsPtUtU7qlfB t9N6i86K5/oMg7dGcsu1ytOCwVuGD1/RSDTY8LjUqvJEi0Z6a7ibiW64S6SHok4ZBxU5o3is0iQr lxaPdafWplL5hSm5I3PSZoQMPcaywdA9J7rPv5wa9VYmlOUtnVvSY4KnDKqNTDAy2s/PU1JiEbkx rjAoj3OsaJIzsHNhkzCMalKeYrw3xCZ7a3xzfbU+rKHA5BrFNyXW6vMtr/KVV06vUZ92ZJVUn1Kj 9gKqhVgqmkVFKsYaLMt2i8eq1seo9e7q2NOax4lmb6vBV17VqgzuiwzIvNhBcFrnH9ewqSBmELZm GU43X1mDz2vzlrU2tHe1zGltCwRal5TWLxiujOEb19Tqq6oZ6VbnOqVmvXuNcqsYVs7Lq4v65eDs KWrz8Usr2wL80qrpNXttjHkvra4JS1wqri+qbUtHW81evPYCqlVSrIpRqXiVijLSFFQMan/33gBj LWqrRjWo9cZ2zlSbQdg4a2yXyGYTNgk2DdkCqk0peEjxCxBiHLel3ibl8ayrXdBaX6tsLhaLR4lf HuK+USwk+Ua1cUlnDhl9c4tCJl+RYi9U7IVk1yl2PRYGj+UIjnImtdb7cE5hQdUwN6elKCtDetu7 uqprUl9zH65NxVKbCUyvCUVl4+zXZoxHvzEK6mEeE2ppbFDmwYI1yrX6jHGNtVi2YkB0GReKwghR kRHQo0y9RlmOuKgRzwYPUL2+BZVQS22oNlu5ac3CWnU520JsrG84HjuNqfUrN8qrbY3xDVT3JraC MeMShaIwN1ZVQxY3qrhZLQVJb8bMG31oaqz3Itoa1liFpU5nqdFNlrk4EjX+uSqM7kgjU9ySM0wW YygqFwPiV9GmXGVLajP0tbU0ebV2SaQD7m0LmTAjf49QRi5AdNA0TpkLfi/BVJWuTyvDVLazKb5V OFmUSasj6dEcsmSMa8DhT9ebYPEViIsNyhlhioxxgKx6xXMz4i5nVLd33etbndqj9MvxKS8HZWEy 914sbFbberohNCO7X47hdKtFNbe2Giw/fwHFy2DpZsXoLcVbg7FwlOxtly58JCqej4e4QIjzhThP iBYhNgqxQYj1QqwTYq0Qa4RYLcQqIVYKsUKI5UIsE2KpEOcKsUSIxUKcI8QiIc4W4iwhzhRioRAL hJgvxDwh5grRJESjEHOEaBCiXojZQswSok6ImULMEGK6ELVC1AgxTYipQgSFqBaiSogpQlQKMVmI SUJMFKJCiAlClAsxXohxQowVYowQZUKUClEiRLEQRUKMFiIgRKEQo4Q4Q4iRQowQYrgQw4QoEGKo EEOEGCzEICHyhRgoxAAh+guRJ0SuEP2EyBEiW4i+QmQJ0UeITCH8QmQIkS6ET4g0IVKF8ArhESJF iGQhkoRwC5EoRIIQ8ULECRErhEsIpxAOIWKEsAthE8IqRLQQFiHMQpiEMAoRJYRBCL0QOiG0QmiE kIWQhOBCsIjgXUJ0CtEhxAkhjgtxTIgfhfinEP8Q4gchvhfiOyG+FeLvQnwjxFEh/ibEESEOC/G1 EH8V4i9C/FmIQ0L8SYivhPijEF8K8YUQfxDicyE+E+JTIT4R4mMhfi/ER0J8KMQHQrwvxHtCvCvE O0K8LcTvhDgoxFtCvCnEG0K8LsRrQrwqxCtCvCzES0K8KMQLQjwvxHNCHBDiWSGeEeJpIfYL8ZQQ TwrxhBCPC7FPiMeE2CtEuxB7hHhUiN1CPCLELiHCQrQJERJipxAPC/GQEA8KsUOIB4S4X4j7hLhX iHuEuFuIu4S4U4g7hLhdiO1C3CbErULcIsTNQtwkxI1CbBPiBiGuF+I6Ia4VYqsQW4S4RoirhbhK iCuFuEKIzUJcLsQmIVqFuEyIS4W4RIiLhbhICJH2cJH2cJH2cJH2cJH2cJH2cJH2cJH2cJH2cJH2 cJH2cJH2cJH2cJH2cJH2cJH2cJH2cJH28GYhRP7DRf7DRf7DRf7DRf7DRf7DRf7DRf7DRf7DRf7D Rf7DRf7DRf7DRf7DRf7DRf7DRf7DRf7DRf7DRf7DRf7DRf7DRf7DRf7DRf7DRf7DRf7DRf7DRf7D Rf7DRf7DRf7DRdrDRdrDRdrDRbbDRbbDRbbDRbbDRbbDRbbDRbbDRbbDRbbDi3cpAllzOGWUBzlz OMUFOp9q54VThoNaqLaRaEM4xQxaT7V1RGuJ1hCtDiePBq0KJxeDVhKtIFpObcuotpSomYznhpOL QEuIFhOdQ10WEZ1NdFY4qRR0JtFCogVE84nmhZNKQHOp1kTUSDSHqIGonmg20Sy6ro5qM4lmEE0n qiWqIZpGNJUoSFRNVEU0haiSaDLRJKKJRBVEE4jKicaH3eNA44jGht3jQWOIysLuclBp2D0BVEJU TFREbaPpugBRIV03iugMopHUcwTRcLp8GFEB0VCiIUSDabBBRPk0ykCiAUT9abA8oly6rh9RDlE2 UV+iLKI+RJk0tJ8og8ZMJ/IRpdHQqUReus5DlEKUTJRE5CZKDCdOBCUQxYcTJ4HiiGLJ6CJyktFB FENkpzYbkZWM0UQWIjO1mYiMRFHUZiDSE+nCCZNB2nBCJUhDJJNRohonYirxLqJOtQvvoNoJouNE x6jtR6r9k+gfRD8QfR+OrwZ9F46vAn1Ltb8TfUN0lNr+RrUjRIeJvqa2vxL9hYx/JjpE9Ceir6jL H6n2JdW+oNofiD4n+ozaPiX6hIwfE/2e6COiD6nLB1R7n+i9cNw00LvhuKmgd4jeJuPviA4SvUX0 JnV5g+h1Mr5G9CrRK0QvU5eXiF4k4wtEzxM9R3SA6Fnq+QzVnibaT/QUtT1J9AQZHyfaR/QY0V6i duq5h2qPEu0meoRoVzi2EBQOx84AtRGFiHYSPUz0ENGDRDuIHgjH4rzm99Mo9xHdS233EN1NdBfR nUR3EN1OtJ3oNhrsVhrlFqKbqe0mohuJthHdQBdcT7XriK4l2kptW2iUa4iuprariK4kuoJoM9Hl 1HMT1VqJLiO6lOgSoovDrgbQRWHXHNCFRBeEXfNA5xOdF3YFQS1hFw5jvjHsGgLaQLSeLl9H160l WhN2NYFW0+WriFYSrSBaTrSMaCkN3UyXn0u0JOxqBC2mwc6hnouIziY6i+hMooV03QKi+TSzeXT5 XKIm6tlINIeogaieaDbRLHK6jmY2k2gGOT2dhq6lG9UQTaPpTqUbBWmUaqIqoilElWFnADQ57FTu MCnsVJb3xLDzAlBF2NkPNIG6lBONDzuRF/BxVBtLNIaMZWHnBlBp2HkJqCTs3AgqDjtbQEXhmDLQ aKIAUSHRqHAM3u/8DKqNDNtrQSOIhoftytIYRlQQto8BDQ3ba0BDwvbpoMHUNogoP2zPAQ2kngPC dsWx/mG7sjfziHLp8n50hxyibBqsL1EWDdaHKJPIT5QRtitRSify0ZhpNGYqDealUTxEKXRdMlES kZsokSghbKsDxYdts0BxYdtsUCyRi8hJ5CCKoQvsdIGNjFaiaCILkZl6mqinkYxRRAYiPZGOemqp p4aMMpFExIlYoMs6x6Og09ro6bA2eU5AHweOAT/C9k/Y/gH8AHwPfAf7t8Df0fYN6keBvwFHgMOw fw38FW1/Qf3PwCHgT8BX0fM9f4xe4PkS+AL4A/A5bJ+BPwU+AT5G/ffgj4APgQ+A9y1ned6zDPC8 C37HcrbnbYvf8zvgIPRblmzPm8AbwOtofw22Vy2LPK9Avwz9EvSLljM9L1gWep63LPA8Z5nvOYBr n8V4zwBPA4Gu/fh8CngSeMJ8rudxc7Nnn3mp5zHzMs9eoB3YA/ujwG60PYK2XbCFgTYgBOw0rfY8 bFrjeci0zvOgab1nh2mD5wHgfuA+4F7gHuBuUz/PXeA7gTtwze3g7aazPLdB3wp9C3Az9E0Y60aM tQ1j3QDb9cB1wLXAVmALcA2uuxrjXWWc6LnSOMlzhXG+Z7Pxbs/lxns9F8kZngvlAs8FvMBzfrAl eN6OluDG4Prghh3rg6b13LTevb58/dr1O9Z/tD4QozOuC64Jrt2xJrg6uDK4asfK4GPSxWyedFFg ZHDFjuVBzXLn8mXL5e+W8x3Lecly3n85l9hy23Lvctm8LNgcXLqjOciaJze3NIeaNSNCzZ81S6yZ G9u79u9qdqeUgQPrmi22snODi4NLdiwOnjNvUfBMTHBhwfzggh3zg/MKmoJzdzQFGwvmBBsK6oOz C+qCs3bUBWcWTA/O2DE9WFtQE5yG/lMLqoPBHdXBqoLK4JQdlcFJBRODE2GvKCgPTthRHhxfMDY4 bsfY4JiCsmApnGdJtiRvkmxTJjAxCTNhbl7U3x1wf+Y+6tYwd8i93y3HWBM9iVKWNYEXT0rgixM2 JlyZIFvj34iXAvFZOWXWuDfiPo37W5zGEYjLyi1jsbZYb6zsUnyLraguU7mwhHjAYNXXilifv8zq 4laXxyWVelyc2T+zH7XLrqdsb9gkq5VbrV1WKWBFd2u0J1pSPrqi5UD0gKFlVovHIikfXRY5NmCB RRkx0zy5usxq8pikYKFpkkkKmAqLywKmfv3LmMy9nDNuA8kGZRbc5SnDvt4Vy7Uc7/O26qrs7PJ2 A5tSHjJMnhHil4YyqpTPQOX0kO7SEAtOn1HTxvkVtW1cKq4OOZV/sVXrF23ezIqSy0PJVTWh7cm1 5aEWiIAiuiBYclssK6rNnrV0+dLs7GWz8DFr6bJs9Rc1vlypZStG5XfpMtSVn+VqnWX/YqFuoNlL UZYJ47Jfvup/e+H/7gn855c2pnzJYHSXdCFrki4AzgfOA1qAjcAGYD2wDlgLrAFWA6uAlcAKYDmw DFgKnAssARYD5wCLgLOBs4AzgYXAAmA+MA+YCzQBjcAcoAGoB2YDs4A6YCYwA5gO1AI1wDRgKhAE qoEqYApQCUwGJgETgQpgAlAOjAfGAWOBMUAZUAqUAMVAETAaCACFwCjgDGAkMAIYDgwDCoChwBBg MDAIyAcGAgOA/kAekAv0A3KAbKAvkAX0ATIBP5ABpAM+IA1IBbyAB0gBkoEkwA0kAglAPBAHxAIu wAk4gBjADtgAKxANWAAzYAKMQBRgAPSADtACmtFd+JQBCeAAY00cNt4JdAAngOPAMeBH4J/AP4Af gO+B74Bvgb8D3wBHgb8BR4DDwNfAX4G/AH8GDgF/Ar4C/gh8CXwB/AH4HPgM+BT4BPgY+D3wEfAh 8AHwPvAe8C7wDvA28DvgIPAW8CbwBvA68BrwKvAK8DLwEvAi8ALwPPAccAB4FngGeBrYDzwFPAk8 ATwO7AMeA/YC7cAe4FFgN/AIsAsIA21ACNgJPAw8BDwI7AAeAO4H7gPuBe4B7gbuAu4E7gBuB7YD twG3ArcANwM3ATcC24AbgOuB64Brga3AFuAa4GrgKuBK4ApgM3A5sAloBS4DLgUuAS4GLmJNo1s4 9j/H/ufY/xz7n2P/c+x/jv3Psf859j/H/ufY/xz7n2P/c+x/jv3Psf859j/H/ufNAM4AjjOA4wzg OAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOA4wzgOAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgD OM4AjjOA4wzgOAM4zgCOM4DjDOA4Azj2P8f+59j/HHufY+9z7H2Ovc+x9zn2Psfe59j7HHufY+// u8/h//BS+++ewH94iZ89izH9rYx1bjnl++WT2ZlsKWvBz8VsM9vCnmIfsTnsAqhtbDu7h93PQuxp 9hJ777/3NfZTS+dq7SJmlvcwHXMw1nWs63DnPUC7NrqHZQtqDo33pKXL1nXkNNuRzi1dts52XQwz qtdapIOwfss7uo7h/Yp61xClLl0CbVWv+EZ/a+fOzntPi0Elm85msJmsjtWzBvivfCN9ISJzFjub LWLnqLVz0DYfn/NQm41eOEtUfbLXYrYEaGbL2HK2Aj9LoJdGakrbuWp9OVuJn1VsNVvD1rJ1bH3k c6VqWYeWNWp9FbCBbcSTOY+dryrBZLmAXcguwlO7hF3KLvvF2mXdqpVtYpfjOV/BrvyXevMptavw czW7ButhK7uWXcduwLq4id18mvV61X4ju5XdhjWjtF0Ly22qUlofZ8+z3exhtpM9qsayEVGjiIi4 zFNjuAQxWAcPL+gxY4rfyu5obYDvim+tEU9XwX5+jytWROKo9LwAPWkUeg7KKOtPi8RV8IH0SY+o dq3q/0lrz6j8klXE4+YekblJrSnqdOu/0texW7ADb8enElVF3QFN6jZV97Tf2t13u1q/k93F7saz uFdVgslyD/S97D7s7QfYDvYgfk7qnor4YfaQ+uRCrI2F2S72CJ7ko2wPa1ftv9T2c/ZdEXu427KX Pcb2YYU8yfbjpHkGP8LyBGxPRawHVBvVn2HPoq70otrz7AWcUC+zV9ir7A32HGqvq58vovYmO8h+ x97jFqi32J/x2cHe1H7JotloxrSPIc43s1n40eJUWiofxCkiMz0bxirYRDbjcWbB6z6WDee7d7tK Sgz99E/iVS4xL5IBA+O8OGDVSJY9iYmFvj2DdZtl+7h23u+RQv1mpLmFHZ90vJ7X8cnhmGF5h3ne x59/8rntm9ftw/LyP3/78wH9uT3VrsIZLen1Tp0vLVcanOkfkp8/cJQ0eJDflxYtqbZBQ4aOkvMH pkiyU1hGSUqdywdPTJcndeikDb7CqfnalESr06LTSknxMf1GZtiqZmSMzE3Wy3qdrDXo+wwtSis/ uzTtQ7092RWbHGMwxCTHupLt+o6PtNHH/q6NPl6sOfv4Vlk3YmZhunyD0SBpdLr2lPiEviNSx021 Omwak8NmjzXoY+zmPiUzOy52JSljJLlcNFZHBcLi6zqm2aB1sjTmZ7fsZeldhx4x2/gEX3tE+Nu7 jj5igjAJYYQIJCoqw6Z8WtRPs/oZ6MMzlOYcE69I9/kzvjObzPFpyT6jhcdqzMxsM0s7fU/53vDJ PrPPHJM8JSaoDbLCwsKYYcPy8urq7HHD7JD2fNvhgfZ8RDy7jl6FLDs7IzZWp4Y8U06Vo2Vfmt8/ ZCinOMfpfXKqZrmB2zI8ngxHlGZxx1dnykaHLyk5w8oNPKyxJGSmePsmRmvW8k/5M2fEuqM1st4c xUd0vhRlidJoo92xmrAp2iDLBqtpc8da5f+2a+g6qjFrU7Cy5uxKYiOyEZNdNl4BPrrLqvLXuywq H9llVvnQLjie/ST+7otm8TyPpTI/zwk7qjT7eF82mPXnuW1RU7HM3j6sgOd9rjpne/fAgP4Zzmhd j6Wic0WWjrKoXM4USVljiqsas6Q1OAOz147b8MqVFVXXvbWx4MzpZW6DVtYYTIbogZPOnTR1c9PQ wY1XzahYWjnIqjfq5D22+JhoZ1amu/qub265/cTOmS5vX3e0IzHGmeSIyszLLL346XVrn9g42p/n 19lTsCoeZExzJfZVDPOwlYHkwlTuiIfnDhvcdjjhsyMGDjvi4a1jH/7CZSyRYpMYiY3KFpV/UGKT GIlN4j78LRqF2JjD0ZXudu5v01azwsOF3bF4m2hA/zpll/lS0/yD7YOG5KfCc/0gRMNnVwKhuXLq 3Ufv6TwSl5UVxzPuO3RL5e5Bix+4eGfbugeah0k33nf87imeTM35mZ5pdx7atnD3heNP2Ee1PK08 U3gmr4NnOWxFW2Jm5IlmRmadGZl1ZmTWmZFZZ7ZL9kBUlMPr8GLyie3cELC0+Pl+P3/Tz/1+XYLy jwaWykxQm478wQlSd24z3MpTl7aN3BqoPudT3VIfdKr9NCmv0xgtho4tiofSPIPFoNXio1PHwwYs V00U9ESJGyxGzZgYd4yBvDXEuJ0xbruh88woW5IjJtGm7xxgsLtVv7uOydXwO5PNbNM7In47In47 In47In47In474PduSzJLSdbDtV0OR4KunffZlVaZoGzayCmZd8A+rNs7/hNnxAko3JWr4Zi+E9HT Y/KqDhic3sT4NKcBrpap1gOOJHgxVm9zuxxue1THH/UWvVaLD83DipfJikczuo5oVmm9rJDdEUhO SrLGKys0Xlmh8Tb4Em80KwpexCtPz8KeyuTezEBmfaacaY34b434b43sZGtkJ1sj/luVbyznDeKD 4tu58ZG0tGF5o/ZxI947Rp4VHlblbOc5bXlTleeN3WyncNRF1nFd3QFSMEficspuHjLUrqwCZber 0UKgND32v0azSmMw680Fsy6YftYDKwpL19w/d+TawZ1v2+2aKJxbN5liY4wxw2fOaRpw3dd3Tq27 //BV48+fW5po1MxyJDsM/lz/xNYnF6/bf2FJcjJfnZaOMBoMtqSYTkeiPzkt3lz34NGtNx4LNST6 shLTaH1oJuM9kMfaHykcwH3mSIjMkRCZI0vEHFki5kiIzEpwk+LSTUr0TUr0TUr0TUr0Tcr5YGqX bIE4FnDxChZwKB82O/7+DqCdxSn/IR0NCj+Ktri+U9IR04B1v5m/aebmU98Q2FCHC3keYquENbLk Tm6suozupdZz1dGp6YJNSM1kgzM1PtHrNHTsgkpQVp7BmRafkOo0SBXqWoRKRPSx5MwGaVTHM0Jr PhSq45ikEzqyv3gN4udik/cUxk2K2xkns0gIWSSELBJCFgkhi4SQPYYz0di1fw8iYbRNUd2Fm90H YcZPnOE1Yt5RrtS4hJ6zPTlDZVb6riP8S8yqD6vZiz+lfv10kjEdO69IjvZNidrHB+JPt3i8u7SR dxc2fff0IitbJ1IcNRc6OdMvk0oWT0kamptm0mslGW8oQ4Iv15PW32sjFxxRvKyiZfqAKKvdbLYn xMQiv7HGWO25laPlWxV/lF0QObfL4UkiG7uXucgTV8QTV8QTV8QTV8QTl/I9ehZlneJq59mRg5nn vSZm3uMk7l4kygFVjtM1quNAXJZYFPxNJUUod7odUThnHxYBPn57lD0p8ux12ThbR7IHA7b6UUtG SZb+/ePy8oy58fGJ7b/yxajso5T0AWazUdlJRmUnGZWdZFR2klHZSUblwbCu/YEE5SmlD6k0xcdZ 8uIH5Oo8fSo9QbFRCmOQROXD0bfFHkE61a3sw87Iy89Xcqse68rHlXwKmRX3nXJeq6kVz1eSLDU+ umyD05MQl+owSJ35ssmV7HSlOE1S5xiOXZMQ73Xoc9wLvP3T46P4Si2/2JTo8Scssrod5pPLc/7x rXqjXtYgLUHyuq3bfk/fdHNiH/eJafI9KX0TTFGOZFfkVNqgtbMz2EW7Mq1WZySYKlsjbFH5qBJM ZySYTjWYKcbc3IFKMAfGW5UPdBxoMysKXQYqXWwspWCKMdeaqUlQ3mnKClHDpwTvJ7HLy48sGYqU 35/pi411/Uy8UuS4fH+PVaXZYHElWoYmZvp8rs4F3tFJkiQZHJ74eE+MISdxSnKmJ9nOhycPGTgg nuOV7vAkxHpjDGOcyNZNyQMzpc+GrR8x9rrxJ77tfgk+0CfNGJfl6XhxUGN9Xd6kHZOkJ5HLIivA VlH+/8iuw5pD2lRs2ky2LpDoVGLgVBaUU0ndnErq5oynMOUHorysP2vBX1ApkeCmRFZqSuSlmBJ5 KaZEgpuyD+mtkSXgFWit8ik7Szv11BSu7rSzofvPHzWD65HPag6N3/LJ1mve2VQyfusnW698e3Pp 7swZNyxZcsPsLP/065vPvXFWH+m6W060zZ52zw/btx3bOXvq3d/ef84TmyZWX75vfvP+TRXVVz6u ZKvIbV7A/ktiWWxVW7ou4ogu4ogusuV0kS2niziiU5ZAnD1ZCU+yEp5km9nCJyR70ZasfCGU2TPw 3t+l05nhpmmXq9LcI+2hBWI7NfPxnZ7uaHokrfILgZUPrdoS5UhNUE6Vvonc1bdi4aIJWbtHTKvL ue2mifPL0uUtDTefM7Izt3tf4FHr4wpnrp426cxB0R0/9hnTyMhjjQkeD2El7OpAii3XPtSAWQ9V vBiqejFU8Wqo8pSH4invyQqgmlVoV0IBZY+Exh4JjT0SGnskNHbli6JJuTZkuo8uCfBAIO4MRGB3 amVc5JBR89vDw8QjHyjOGiS7kV2i/qGWK/8kJLFxKbKSGuqxTRyxsXyQP9PvF2m9SedMT0lMdZo0 K139RlWPWCqChTTfMWB0YvnSiZm+opnDvIP69XEuizZ0dpRMTijMv/q+ksYiDw4ZvC6isMUHDJpW 6Ov4oDuISBq1sqVg6uLi0fMnDXdGZ4+cOKDzi/Rk+aIJC+P0us4JqSMm47T5L/a+Pb6p48535hy9 JUtHkvWWpSPLlizLsvw2lsGWwfiBbTAQsCGxg7ENOMEPbBniAEmapNmyJFv63Bu2n3u77bbpa5sQ IEDS3dr3Uty0kKVtAmmapGmbNI+WZJO2eaNzfzPnSJaxabv97D/3c83E3zManTPzm9/85je/329G Oc3CFbYf5k0revUMagAH2AAubYPEogaJdQ2SrmmQWNVwmimKh8vi5mzcXhaHNTOvLK9M57KTZ11E gbs4jgA84iLD4XqcKSVa/LiLLrnTxx3SNVu8PmYg5pGu+AkcRNVgaAbiWiNfjavjWh1uN5JTChqS qzZWG63LwSo/2eCShzZaT+OQNA9hCK4Yic8RDvdwVzgiqnP2kkn84poJKpu3eFekF/NrnVAF279q 3z/3NIx21dq0sDCr9OWde9Ys61mVV7ZhaGTXhvLaoc/cEO7qWG5WyBhWoVVqo409sarOCmfZxltG btlYjm+98R/6y6x8rj3fa80xKXML/J7qzvLqtbWl5XU37Fm3/s7NEYPDa9Ya7WYT+KZuf05Oycr8 qrXLy8pXbNwDY2SAuX4ZJD8XDZ6yx4mdbyRcO0EMmb964pOF1ChMnySSrzARlyZHmttlYHi9TZnz gzB3Npx2aOZMy5Q6o6bCZeqIfT5ljUFOctTYe6mbRv2Yj/5nWhC3q4xus1kMvxDL4VugqafAqgmj B+M52yKYJ7OWJ7OYJ6LDk7WfJ1JDfgkYN2Za0SBpyCp12Cp12Cp12Cp12Cp12Po4wxELk9ja5LhQ XA1VaAIbuA2uObmhprWkwcNzItKDF9rS2deaebKp1Xednrz1kTsaRVfOrCraONnaNrk+TFnjAyvv xb1n7lpZN/XYPtafYsfH72y9b0ukqPvuLtaWabWuAHvqJeDKcrTzeGA5LjstvB9fRYQ+H4ZHRTIF UZzP0ZJ8nGsnmVAutvMkEynFkRIcycMRP67eULjBX6JlM90IWN3roVfwjwSXpJSftn/YVC4QqKrK sH8yclarQim/R8a5Qx5v2K2XJd9mPmT1zhDvK3Ib2OS3FNgY4L15ZiWD/Rhns+rsfI/bl61mcYjB OazC7M/x+DksD+iNZM026tmffBxN5WXftjn1Mlal1350VhbTGogBbNB+dE5Wq4G8XO+0EQ6VwCx4 l3prJfGcUBSHinHAjgM2HLTiAoRDG/xaY84G41xwDbqMe+i/uTAaxukoWkZv013E7MtZclMol8+z aGXJl5IvyHWWPI8vYJBn4b7kwzolB5M3YNUosBVnyzXm3Bxv0CjTJR+pszoNcjD11Qx79SqYJKzc 4LQyG5l6q8sgY5UwYdz4ZVUWlOtd1qs/IOvZTaB569kfoXIUR4/EecNK78roSlartlXoQIwryFyo INOggiNqteI0fi+uR8GgAWEdIrMFxSStHJMswpgk+eRK1XjsNKOKZxttP0AVXAVTO12BEfj1FcUN haexK264mItzc2U5bxSvWfG8rkOGoqkYDnXre/b09qTMm7Ph3p4aKZ5TBotdL9jRhKFg8VUq5iJ4 5ZWSrSOVyOg8UYqK1Ercf7aec7ucXn3tZ9Y3T6yP1CW+MXTAWrq2ZkVfa6lOBeac0rVy846Kvk/d EPiXBxoHVnq3dDaMrrDrdGCP6LbWN+U37WhoH1uT31TRWenK8eeoOIfBkeP055iLNt1xw1lbpD7U tHFlI3D3QeDuM/I9qJDY0Sdhomt8VZKGqJI0RpXEL/KZ8qvqNH4/7rKEibEY5kmUk/A/TPRTmKPB T0YTVyOLpqrSJ5OXnMbyxwJrXE1cew1kj8k7qEYBFtpq0rb0HM/SOiVoWahcxMmWMhWVRquVGk/P lPcf6Qm3NjUFVSaXBYxjhdLM2x1gKRe0tbQUbD/cVfBdS8XmOF8XXx1sPLCqrrvagV+dfOLeJmMg FhoB/SKTgX6RL1OJTqXq6iuhZX5u7T2PTK6+e2CFqXBlWfLBjV3L+/fD/NoKHOPZJ1ElOnTMTVdn 0XF+SXKYXztBXLBFwodvzg8bCm+I4URGG8+K6rHe8ao3rslq8eadxswJ8xr2d6Vk7VJntZQWncaK Y+oO4l+Hr1BIh5LOpgOH1wSIFeLSrMgMD7M8I1c6lrd1R/u+OFjZsOfBLeH1jZV2tYIxZRmCyzfF 9t3pi/csr9lcH9YRR+wrRocxy5GfY4rvPz75ye/fXss5c+16s90U9PoKfKe+23VPdzgv7FeZc8g8 3QZ8+ZJ8GAVQDToc99bXYq2rhszOGrJS1RBLp4ZIRw0Rlpon8AcIoajItajErKjErKg0Y6MSs6JE oDRmX5O2JuiS6QvJsWr7GpjqsuP6Dnk7WZypONVfEymm8pR2ZTOnIJiaaaliA4FMx6Oa/ZLS6M4m GyLND97Yf39XQdn2z9y87p64MttLZEr99VUHG+tBgkCiGnwr4k1BR0qA9nVs7rjn2PbEE/c2r17F aFM+2dXVIDvbD8Qb7x4EWVpVSrjVA9x6ELRaGFWg78YLo1X1VaNVrJnMJjNPwq5mXxGxC4sIt4oI G4uofgNZ+OBkY/hfwgzZajhJZluFTBI+mSRj9LOWXkUFJyP88/mKZu+SHZEx0zJ8UYZlMnf0+cAa +xvb9GN6Rq9+w00FrCczPi1OyhfCorBBsbToK/y+DLGyzBc+xhKsogxVsg8GHVcf9TSNrY8PtEZ1 Sq2CZViltmrznvjoQ+Ox5Xu+3H/LF7ZFvs5O7VtxU10uuL5BX9ttm4stTotS7zBlmQ06rcNurrv9 9O2JM59Y3TjxT93muz9f3D5YTda5fOFD5j75bWAJDDxq5cgEpBPPJWktV0pbuSR15pKEyUV+QFZS mH9auBg3kXhjvuZKVbMzcKWkhW/nWqgHU0Y81vDZ8rfFOVZ+9poorUXstyLTg/FLEdvyVJSWuU8m VymUFk/IlV/B65+EVU9uMjypAtVk582qOzmOqJo7/S3Da/wr83QqWAvNNr1crVXby9fHtiuNTnMe //HvVFqik7Qq1sLnmZ1GZU/v320OZRl0Zhf5fxNWJj/HHmJ/iOrQWnQzuhi3mCLNZJY1q6DLzTxn xu3N5fVgJREW1EvzC64vPUa+qleug2w8y2DC7etcMkMJW65UEunhKL+m41mQiZQrXS5leURGeByv IEzuJk108xw81l2YH9fCNd9QomSXrXlOt/E1i2XbMvb15S2F/MqfL1tz48/5ddK2R70YCL8kqv5w +QXCXBt4HcTvMEIhdyEM/4VTQLgOPLZaxaUgEFSAPrPaJC8xJXPVsLxWVFEUZzY4krgikF5O6xgz OJJBPSt9Yg+ZDZ/wu8t67lpb3e8y2RqqfrdqbENxxa1f3zP84PYizlfKl0bL8r15FTd9oj3U7MWc 0ZhMDvaUNEdtgzeWtkRtG29e/zofsqvv3ds2WOdiE35vXld07W0bi3KspmKPv5jRML4VW2rrxjaV 5se3VPjqlpU7HO1FK7YF8ntWdtx+Q0St8iXfvmknv6y1YMsOb3XL1d5YPaNyREIFloZVOSV1RL4f BDvuy7Ayl6GpE/UVuHBu40US7IwdGWmHBpZlm0cMr9NAO42xU7WhJd9pxMi6p9ABzrviVGRNXpOj napP6rSnI7fiYlwzP7xMVxPlIsFz0Ti0sF9WmcQ1117cWlJ3oBE+0rBfailuPtK6dX+7z5GSZ8bQ 0duY173p6uFUSeb629a6YsehPqIpPyl8iNfLo8iCfOj+U/X+df5RP2uVbLl53oyZXl+6xusRvZwn mD3IjSzXCwZLLLUAmx7TeOPwJPkp1QkH10r5c+lKWNKG0sqyeOzdTJZdIowghbjuWgaYi2pjYfKX ZgF7byqKjUtihaEa+IMeC88kP4cHoMd5qATdd3xdGdk3p8YCXN8hdOenFDvZUCcdyCe/Kg/rkHRf Rthe7Fc6fg+6L65xOFBZMeljMfTxeIG3NRtW0mNyOkuhp8by8pQ9K/YW+iqfFwywzvfw5nV7vSc+ 0MxH7GoZZpVqpcJv80U9+pTSIzwoDNfWFhoG9t8QVmmyjKYsshcpz460tLLfXsgOcR4cgHlQgb4Q 19VX4VApLo2bcAeYRxdp50ql5a+U9F5Hr3T5K32CCaJcpJN4cP1dKpgaTmskgghLxClizdXKC1rd TcbU9AA3CUfB2ALrnq4JZS+lpCAtBkG8yOSQ3ENYKpQYW63sAZU51+ny2w2K5L3Xyge+QWVy5Nod uRZ1liH5OB7J0tKwFbhFavxOMmvhNPn4p3ivJkvNwqKq1tm55OPJfKNF0h24DnhmQXG64zRKd5wW 39KZkxH8/gkN10R7LAnA4jtMCyTbsZA0iQr5RbBxOtEbcZeJbLfSUwEB6p0HqWs+tgE3LdxZFqNp GTvQb6T1m8djJXFnT5m490F3QegGCFVzGpDvU50k/tFZt3CjXqx2wYb+E/h9ULIcVjzatgaMb0U8 q2FNXVNkWWuk3ZEx/plh7BoppmmsSW12EW1Jf1Lz51Tm9XSoRXKwJWGRXxRVqVmVXdRYXDOxmswe m8+stBatKq5JpDWrwuS2WXM4ZfunW5dtaSzhIuvbmvO69rZ653Ssv+YaHbuwhL0XDBOWVWtV+zat c0YbCkobC82gfNtTaxCMYBn6fNwgjiABaTm6dpSuc06AOIseLcelViW6EZyxB4zfPyUtTGRZimsi awodea0p1hOrYW5PkZvH7b9iebL8peUpzcR/7PgLy9M8RgGDtpHViXiDLwKHyH7KN+Lu+hAuMOGQ EQeycECHAyocUOJCGt1ZZA/lpUX3UIix7olqsCZjc4afvznzOKMhceJTBtQxBsPkIL8lNazxg+co udfEQ5RYFk1vufSk/v2lvRf2xdjEv46Pfm2kqmbiOxNwrf6uq+6Wda1DjT5X/S3rWm5p5PErI2fu a1t5x4lxuK6B64HWu7fXVNx8d8eau/tqKnrvJrGF5OfZZ4A3JLZwF4kt+Ko0kpRoJCnRpLSPRuq9 hhoxFjGsQAMMNFouRhgWjSu0cuuuG1dYLKywiIxcP6zw2d6CxoZ4XoawZFtcJmWovWN9ZPvfk7BC OQ0rNAUbb19Vt6XaiV/f+717mrncCn+yLqULZa+DzLAk6jVVWBeytN/78OTqTwwsN4dWlSaPbuxe PnCA+s/ArS9J3Lov7gJ2ebVhMmHCGl0qxEKVXJj4zoWoXBSbckmcyiUtWS6JWbnE0HLqO1vyW7Ur wl4ZV0x8Z+eaZcR35jrImr+47zyPZ5VGMfKZkhdb5fV9ZzWZZt5sZWhNS2uQsKis/zM3FzStbi4k xwuz3UblAv85eSLFKXwhVOM3pHxoY35taDjFuuSfRCdaDMiAE021E/MQjQz2nxirxAGDJFRzR3Qk 4TJIUmcgwmXKCJITKUNOkLn8uDq8JmCw8K0WonWouqcLfjhtC2c6gIspGipECuYhRqFWqWw5eRZH SWXMf62ayW+I1eRk+fJydDIWs9utHqNarVZlF7dXX31koaK5p6oxaGBVGo1aT09qrReuME9Bj1vR U3FdtK2+bV3bnW0Pt8kzNqLelTagqFA0kPCU+ZoNKroxhZ+Pe8XdKLoPRURM2owiLjLROa7H8bv0 SIGGmEW6ODWV4GMA6qvXPaxjdMUvVGt+Z+w0bjOOGVlx0+kXZMdpjfU1cTKmt5ukzaYesn2Qsdk0 Z0v/VzebmKfKe+9eW9K1usSqkZHNpHD95mWFjWWuYLxz0/p4MLRh/4a8lljIomTBOtIo1LlVrdHC eMhSEN+waWM8iPWrd8N42xzZeV4z2J8u3mXyV+UHKgq8ueG6zcsr+1qLdCYLpzNYOaODU1odVrO/ xB2sLOBzC5ffQMbCJ7zFDMv+FcXQTSdCyOiPSDyPSGMRkcYiIk3IiCSVESKEOltW5Iq/JSfriq2l lFjfSlFtXyBiVy5Fry6cFUN7ssUDDPPDENZUOIYZVnF8qNjWNBDPucNgIjtOB1OG2qskdmwyvFrd bMtzZ6vkarnsxpxcTq9W5LdNrGX0YoThUurAwCUxBpHU9Nys1qjlejvp9+dJnI/9HtgEn417wRLQ BokEBYkEBclGc5AqqSBHTS78wWPiTPNKXPFKXIHr+3Rukgxhizc1Wb2SjHqJr6I2R1qDWrmjFQwz +Vywj8zPlL5Ki9Siwb5rNqaqqufCfl9SmnIsthyjouOLdOlXZos+ii3aUlK3f7Uy2wsz16ROWwT7 Nq1dvvPQdiY3NTuv/nHdzavyuzcxk6kSwp9csJn2A3+K0G/OIL8AqxkxdL10byrfiz1ixoOtUj8t 0jV7zvylV1N6v134z3g12awHq8KIgxwukOPcAihYkYvzcrGPZOt9OM+HeVrK4zweBw14rw/7SJBL bbS0+HiYtfDptbgaRNFHIozkExkJH6lfBw/6Clp9WmerVlSAdMsvTE5X91DLISz+R3eKRL6T3bEw Pe+ePiKUsUSYbdVm6aD7fsywTPKCLMtZ4PEUOPSy5FMyOTnMYsvxm9WypIz9iNGYfS6bx6hk/5dM rdEpP/4mOW8tU+k1bJfOpGbBJ2QA1FedOh3zW7VOxTIqLeF2JfgY9wK3V6MXz6BmUE8roGvLSPAr tAxXk2t+MQ74cIDHAS8OeHAgBwfduECGQyyO1eLaGK6N4OXkzQ0W3MFJ4QNyjWtAXDkeauAMUjG5 xnVkISHFhoZWeh9hZj23jhvl7uRkXNxkbeHKW/NbY0eKcBH5rohoTc5sbdlZtK+IWQ2ltnY1YfIz hJM9Z+vrLwAnRX5HRX2IqJWWttdERivSfGaDyoy9yEVYnpGV3yuTJ99js2wFHm+hQ8f+G8M8zGY5 Qx5vED4lP5DLwLuwuXNNKvbnDDPLqE0g9l6TirnM4EuM2uxz2nPIsCizDXODwjygVl+dmBsiQ7ZS rYURAk/1qlOthhHKAsVLjkLaU58YlYaMVwhmRxuMVxTddwaVAmOMJL5P9EYx0Ri1xdgO8vgY2c+z Y5ukG6ypIitWE2ktJH4reWY5wsv8uEqLtTxxL8ioaLWlJaFWssfZaky7EDX1RhMWw9eIMJYIryi/ 4XxrduqnA+wie55m89ye5yqVOej1+C1a2bOXZVpLrjsn34jV2J58T4XNQT7Hn62RXbgo0xi9rpx8 E6NOflCkN+vk4J0r8WDyn+DCynVmPT6FH9Kbs2SsQqNMHsPrFOTMmzbbkOwl2gOswAPAnzy04Qxy QV8rycx34ZAL26nzbMcBfZWeCaqxkyzJMSd2LCOMc2Bvq0NjbtW0ydahNslpJbvZYXHSksnrY8Wu VpsDAZCcivQutplGdazZSqb8NkVpmZM3MooDao5Nfl/F5Xk8udlqOcbs+wpjLu/OMyqSJzmjXJet xzUyk4a9yWLXy1mVIetqMXPJrJXDOmGCnmwBo/YyewqFUe0ZxEFPrOTsUYCeQIrC9xXqRjWjzjeC 03Lc0WIIUucFCCfB9zKwFS6A3pFcPHIQk0Z68bxj0fSoECZZ5rJCpVddvWRxEXnEDyTv5MzkpCYj 0xp1SlKWnMRfV2WpFU1ml1Hp9uXqrVYHx9ziyzfBZ4XeauT1dpuTu/pFJQeWFoM1wrv4eXkvsqAQ 0p+U57s6uCZg6gtPZZxcYwPpANg1P+X5NyX5KY3bpDRilcXvdvktKr3aUeD1hmA+2ENeb4FDjSdT Vi/7uM6kkyt0Rt1HNb6wS6t1hX2+iEOrdURo/PNdtgsoqUAtKBDX5+V51dnH5fISdWOMrJH4WEkT MR1eIL9FovF1kcL0j5AolZI9tWDX+VpPkO0q23pHh9IftHhMKgVWm9wma8NNNU4+3rcy1hUPaZSw GCqya9b3Vdx6dKAkeRZ64+GhN9A73gO9Y3/Z/altVfK3DQYy/TGsr2ZlqPGmspqbVwccHrvCmGO1 O8xep2nFrvs/rr22txgVJl/EE+gl5EKaR7U2N+KeviAeGlMqRY1XbU5zeUKhtxkPybPMDrPRpsGy T2rteU5Hnk37aW9FccTxlFKjokoIm+9y8ZxCwfHEz2pJ/hI/wH4BPPYo8h3Ly36CWYcC8MX+kxpv uERuQNEL0ChYF0//6tzCY4rGxUl5gIwuX0BGt4Ano6vIshk/Jc8yOUyUtHt0tjyHHUhjeb6I9LmI z42Qa+RqByX2vEqjlBE/BxvTxDLoCeE9idYgch1D2aeZ/ac0Hr+jXW5oQfUX6i8QY7FscSrnCeQC +q79vJCuAp9YAIMDi64zQrT3PwI9IzA6WmQ7Ro5UTT9Gjk6pWVCzQEp4hgxVRix4JFq3vJj8DTdH i1fDH6ljNT7BFDMrkAHpTyCl9ooMkSOT0l6PT3yWzulikzHZa4J/+Cswc+X4g6DHGwh4FEYn1PLJ 5EP4D/LDyI9y4xaWLB0scVpYql5Yi1f7SVQfBe6IR9kUYCWbbOnTLcUs1SbiAonfurnn5hvlWJ/j MDnNOrZqwzK3t2ZDOVZzbqvNzTHy7U8mt1y6nNz6Y51RK2cUKvmOnzz7wp49z//8pztlCgWocY70 63ag6FWgyIfKzyCTaNOZJJ+AXE8Sykz0GJ+Wep0iheGy9Gk7ZWr9qTJVVjBBSbvYrCb8qnvZ+ipW Z3aanDlZWH5Tb2+vjOHcNovbqGJ2TjKOPS88+5MdcpWCkYPC+xF+6PIl/NCTak4D1ClkF5LrgL7v J6cZl3wf8oI+c/zQ4JwljI9eSfE9ZSv70i4FdSZcBr2AdFaTVmuy6jBSwPQ36L/6VXJNfuxzgbbM VoSJTlVwNiPv/nC5wkBPIW1NTuPHpNa4HzoMswqpNbl4TFpyZeacGhpZfkxrsukEPbi8WuVXvype BZ3NpP0w2wVOms9oMyjkZ9280cYplEaXmbR0mN2Ba+SToKnVj8q5ZpDETBWdinDhXKXBbjI59Eqb xuKz2X0WNWbvS8cd/oMG2tUkbs2QGpmjtEaq+12BZlJt/YWyRSueX2K1MPcAK0wmu0Fh02STlrLV OPl388pKAtc2TXLJ0vllHAe92wne1mflPtSN5WfQVrCX3AamY9tWXKoCg6eUiHwpFflScjK59DRT Gdes3RhYu9YO9n6c2PsBuCVAzNA4lAbirN6l4lIePn3SxdNNcdHScp1mIiepaUVPskBbSE+MX7hb L8mynpizZpj3+lqyYVIbpwt6LSbnT6Vzw9NxDSmsNdYarVWnsTauad1Y9Aeel7eSw6ja9GHU6JUa Ln0eFUzcqHi+UIoQ0I1hEmQ31XCp3Yjw3E9KqjLiBOLBe0mQFqx0CumUAqO0eFj2s3WJb93asKc7 ZlApWH2WunLjaOPKgcbc8Mapjv0qg1ap0OrVe1YOtQadFesrY33tZRpiucG8N8c2jca3furGCF+3 tXbVaGcEj2/59I5qS45Xr8/OseS5+Xw+t25TWXV3PFfJOS1mh0GZG99SXdBa5fUX+OUGl9VgM+rN eX578Q2TzSuG1tdoGWVl5630/1rwz2LC0T+TvjOXGIeUvrBISrJfSyXZapqOLJr+JCb5qoz0n4rD c0nJXicdIEkVlNIHc0m9TUq/WzxpDqTTy0tpftJ+7npJV6Q7vTBlrZPSfy5M+on/3mTYtkh6mSSu 5zrpZZKMd9A0M5dMXzGXz0szi6fsbkhvW24Rk7VkkfSdvyXZli+a/mD/cSo5bnRMp5LTu5SW0v+n aYCmX8xPLp1ru+tbrvN/Q3pr8eRe5v6U+/vuP/61KScnp///reTpWkpLaSktpaW0lJbSUlpKS2kp LaWltJSW0lJaSktpKS2lpbSU/tZE95ExQhoOYfxtBUIqGYNkyCS8DRikGEM2wDbhdcABYRvgLuEl wITwCJLho8J5wGnhOcBZ4TKSsR3C9wA3IQNgN9IBjkM9JqjtTcAYlJigNpIfQBpkYjcJ7yE7kgm/ BowJbwAOQFt2qP8dwCnhV8gO9zwJ2C1cRG648w1Ak/AaYJBiG9DjRr3C75EbM8KLgJzwMqAT6nRj j/ALwAJhGvAgzR+m5UfJs0A51Iln6FOzJA/UvoIC0MoDgCagM0ApDwBtnwNso/le4TeAU0BJAFp8 EpC0GIAWfw/ogfoD0BYpOUxLjggvoAD0ogKwW6hHQejju4AJ6HsQaPgN4AzUFsTnoNdBoOTXwCkZ PBWDVn6PYvDsK4Dd0HodUPUGYFD4CWAMOQDbhJ8BDgi3AO4SngZMCH+P6qDXrwMehdGpg1YeBZwR TgPOCsdQHYyREbVBK68DxqD+NqjhScAE1N8G7U6jNqDnj4Dngdo2oOEiYDfQ1gVPDQHGhATgAPSi C+5/AXUBN54G5IRnAJ3A1S7gxmXAAhj3LuAJyR+m5Udg1LrwUVo+SxDqZwC7kx8Bjgv/B22l/N8K Pb0C2AZ82AqcfwVwgOYT5Fuo/3nAg8IlwGnht4Azwi8BZwmCBGpQL1D7NmAM6OyFZ98BTNCSKeEP qBeeeh1wRngLcFZ4FfVC6++BdMpA2geAhkuAQeEHgDHh+4BtwjnAXuDJACQ3GoBek3fJcAJ5I4xT IO+i8QjkbTCdAnkPzaRA3nazl+JBWn6I5g/TO++n+SMCeVPNSZqfFsi7emYE8iafcwJ5f8+sQN7c c14YRwPApWLAzcI/AHYJtwN2C5WA40DDLqD5Z4Ax4Vm0C+58GbAb+JOA8q8CEslJQF8IxoRvALbR POlLgnIjAX05A8iBtCSgL6cBPcJJwE7hR4CTwlnAvRQPAoUJ6AvJH6Z33k/zR4RTgCdpfhrGOgH0 /xglgJ4CwM3CAGC3UAY4DjRMAVWzgEHg7RTQQ/JkLk9B608DeoSfA3bCiExBi88BHqblR0EzTEEr pGQa5HYKOPYfgLMge1NQ88OYAfn/I+BR4QogUAI4I7wDeI6WzArPYQPc8xbgEeFdwKPCe4DTND9D 8ZxwGXCW5s8LL2MO+PMW4EFADzz7JuBR4U+A5CkPfcoDT/0KcFb4A+B54fe4AJ56FpATfgboFH4M 6BEuABbQbzuFs4AHhWcAD9NvjwivAE6jLMAZpACcRRpAWhtw8m7AbuE2wHHhScA7kQd3QivPAXLQ 605o5QqgB+jsxJ3IDHgQ+t4J9ZNy4B7uBA1gw1spl7ZSLm2lXNpKubSVcmkr5dJuqPkFQE64COgU fgjoEf4d8KDwBOBhWnIE7t8N9bwLeFL4Ld4NtB3Hk7T+SVr/JK1/ktY/SeufpPXvpffspffspffs pffspffspfcchPL3AGeE9wHPAT8PQvmfAM8Drw4CT36BD9HRPERH8xAdzUN0XA7RcTlER/MQHc1D dDQPA2c0+H7o3SVATvg1oBPK74fevQLYSfMHhV8CHqZ50OSA08DP+2FctIBkXO6H1jsBQaoBx2E0 jwAlVwCPCq8DTgO3j1AajgANbwDOArVHgIY38VFo/VVAjqIT7j8Krb8BeBDG+ii0S0qOCr/BR6Hm GTwN9/8akNw/TVYcQA/FAqBnmtI8Dc9eATxMy48AH6ZB02oAp5EOcIbiLMXzMFLTQH8fYLfQDTgu /ATPQCuvA3JQwwy08iagh2IBSOMMtELypJUZaIXkj1A8CnbADG1lBlpRAc7S/HkYlxnKpRloBUYR WnkGn4NWfgHICT8FhPkO6BF+BHgQpPocmemAR0A2zkHNCsCTQM85ePZ/41l49leAHNA/C8++BugB nswChRrATlp+kJYfpkjkc5byYZZSOEspnKUjOEspnAUKRwC7BdAj0MrP8HliUQByNO8EOs9DKwQL YDTPQytvAR6k3x6m5Udg7M4DneTbaeDJebKyA84Kb8J8kyEjYAxZAQeE/YAJ4RbAKaRhN8EoPwMr lgzpAE3Cc4BBijFkBgRdDTgg7ATcBbV1w7NjbDdQ8ixgJ9TZDTU8DTgtHAecEb4HOEvz56H+bujR p9lxorUApymeg/rH4Z7fs3eQuQA4hOrBJowwuYj834LIvwGKLLUU9fQTyTNIz8qkPItKWJOUl2Xc IwerbaWUV2SUK9GH7FYpr0KF7EUpr0a87AYpr2G+nL5fizbLElJehwplP5LyWcz/kP1RyuvRbuX9 xJal/8qU70t5jJSqQinPIKX6dinPIrv6E1JelnGPHOnUD0p5RUa5Eh1Uf03Kq5BF/ZKUVyNOkyvl Nbgzfb8WhTVlUl6HLJoeKZ+F2zXjUl6PqrT/DpRgmVris5gX+SzmRT6LeZHPYl6WcY/IZzGvyCgX +SzmRT6LeZHPYl7ks5gX+SzmRT6LeZHPYl7k8zcRj8pQCaRlkOugb3QaR6NoAv52gC3Bo1X0TVji +7D6oGQIciOoGL5pQLsh8WgDlO0EayUBT5FPg3AdhLv3Ag7Anavgud1wz3YoG4I7huh9ffA3DHUN 0HtH4NMElI3Q78Tnh4ACHv764L4hqGEKPu2DXALa4un7t7ZDfjfcy1OaJ+HpAfp+r520llGp1gTc MSy1Se7goY+jtM1B+h4v0pdW2tcdUNJH3y81TnvB02sf7SVpV+xHP3xTRGsepiW7aY19wCOxPNXK MNSzm3JsTKJyBEqGaatinaSfiQwKSItjtC+p94+J3BZpJy2NAgd4+uatnZQLQ/RdW+QdZgn6ifQ4 kR4PkWdiKzylfUTq1yjl7XZ65xzFmT0iXLuNPif2+lb4XEzlIXM0g7S2YVrDFOXDpDTymfwmIyb2 f5DST/ovjss4lQZyFVskY81DHWPp3og07pTumYBPt0u1J6AX4gjtTY9SH5WRPigdntevlDT3AyV9 tP1+qf1iKrE76ViRbxbOgdiCXsfSs6YSbZakaEiSt0qosQq+XVzqByX5FXvTJ9G/k34r0jMocYzQ OEAll1B1Kx2z1DOLf7vjvzSD56RFHJtN8GmI0kDa30ilPTFvHKMSBaMZPeiX5l2C9nKQynI7lPSj AjrGIbhngNbfTKkSn01AGgMuRiHto6mYzvH5lBfT2ofhHvBpKP07aQ/GoIYpKCUjuIP2hcyc+bWm ynfQtwCOU/lN1beF0ixK7RSVtglKYYLOqwmqB8SnedoHMicHqUQN0TZEDm2nz6a4txr41w4aUXx2 POMbcT4PUJ7MzdF90tvzdl2nXfEzubcfpGiS8nAgLfMD9PsxKrFTGXI+Rns6Ikm6WNcgRTJzr+03 +V7UEAXwVIhK5zD0azA9ZxdSNbKg5r+eR3O1p7Q0L+lZUXr65+m7hX2fk9f5dNVmcID0ROyLqPVT Uj+eXkEGqA4dobq077o9FfncN4+ng5L0XzsHCFeJ5E3SJweoPiK9GUzXQ+7cTXXanxuh/655MTcn opQaMgfElaiYjtUYuu2bfFlJyTK+Y6h/fHRidEeCXzU6PjY63pcYGh0p5ht27+Y3DO3clZjgNwxO DI7vHRwoXtW3e2j7+BA/NMH38cOjA4PjI/xE38gED98P7eB39A0P7Z7i9w0ldvETk9sTuwf58dHJ kYGhkZ0T/CjcmhgchidHBvj+0fGRwfGJYr41we8Y7EtMjg9O8OODfbv5oQS00T9RxE8M9wEF/X1j kCePDE/uTgyNQZUjk8OD43DnxGCCVjDBj42PAt2EbKh99+7RffwuIJwfGh7r60/w/5e4c4GPqrj7 /syezdmzm90QECFclA03uQlRUCjXBVERECKKUqiaEG6rXEIIGJDLEhEDUo2WIl6qSC2lapFq6127 EIwIiIhBI6EaUFBplJSyIa/l4bzfmbNJNkif2j6f533P+D23uZyZ3/z/M3OSeAjPDuardlAzsgRn hmfzrDnTgpPD03XBzoPypxbkkzl859SewXgzL5kXnJU9e2EwZz6Nd+qdP4PnT70rmJdNW/LCNJuM 2bOC83PVYyhxOnfmhReRPH8ODVqgmpQdvCs7b5bzLCVzzozsPCo2Na/nuKnT58/Mzqvvgf51j+6v uuaKm5GIRgWv6Hnl5QnST0VfHpNN+dPDqh5TqVhe9pSps7Lz7gzOUTEJl9PO38FaFlozfnY4n/w3 5mfnO23sRQFz9ANy6Lv8vPDUeT1Hz8/pkj2va3DK1OC1eXOIzc/P7d+r11133dVzVl3hPXPmzOqV vzB3zvS87NwZC3vl5E+bMzt/XjypOp+WTQPuVOl+Omc+0i4Mzp83lUrQJBUdzKYnp+bNCuerCk1e qKt39fjRQ4nN0xf085T5To/eNSOcMyMhL8fw7JyZ86coLeYEp4Tn5c7kAUrz3LwwCXJINXV2fs9g 3bPnzMYguoS7BqfOmqwyNRQ1uy7xeWukkyuTRv55yJPj2F3907Wu8bIG6Ap0CfMUTF9Jn6ccZMqc u2bPnJOd+FDqnO3UFOHre2DO/Pzc+fnIviCcM1WlmTF1Zu45DfoxfaF7oteUqdOycaKe2fNyC+rf B4WdJlb+8N/01e9aBu8WPnGB8Ni2aMK7i/MWJXgnF9Jyftfw32xu44TfL0njyvix6QMBld7o92PT N2mi0rtDPzZ9aqpKnzTix6Zv2lSlNzN/bPoLLiA9R6HeKt06vXqrHqj3zURApInW6jcdorPow34o bwpjGJ8nMdrPEIMZn4eLQlYRD4pR4glxC+9lE8XL4jZRwgi+jxR/YfQ+zuhuS5f0yyaypUyVHWVr 2UteLAfKLvJamSlvkhNltrxVzpZhebecKVfLOfIROV8+IxfIF+QS+bpcJd+R98v9co38XBZL9bOp mPyTS8qoyy+3uVrKUlcX+a6rt9zjChkjXaOM610TjPGuqcbNrlnGLa5FxgTXvUae635jqeshY5lr gxFxvWAsd71trHO9bzziOmCccP2FPj/eWAfXd/+BDo+gwzPo8Ad0eBsddqNDOSmOosNJsVB60KE5 OrRDh0vRoR86XIMON6DD7egwEx0WocN9nK1Dh2fQ4UV0eAsddqLDR+hQiQ7qZ3u18jGXgQ6p6NAG HTqjQ190GIYOY9FhIjrMQIcF6LAUHe5Hh3Xo8AQ6bESHF9FhOzrsR4cj6HAcHU6qz7k21iHp2wQd WqJDJ3TojQ5D0WEsOtyKDneq3xShw33o8Et0eB4dXkeHnejwMTp8iQ4nxQyKy5cp6NAJHXqjwxB0 GIMOE9EhjA7z0WEFV79Ah43c2YoO29BhHzGfo8NJdDgrV7l88n5XK7mGfi929UGHEDqMQYeJ6DAN HRaiw73osBYdNqDDC+jwNjq8iw4H0OEwOnyNDt8ZywxhRIxmxnKjg7HO6GM8YgwyThjX4NM3NdbB OzRBh1bo0AUd+qLDNegwHh3Um8Y8dChEh4fQYQM6vIYOO9HhMDpUo4MtptD+GfIidOiBDlejw03o kIUOueiwGB3WoMN6dNiMDq+gw7vocAAdjqFDjZzvMuUC2r7E1QkdLkOHEDqMRYdJ6DAdHeajw3J0 +Dk6bECH59HhDXR4Fx0+QYev0KEaHc4aEwyfkWc0NZYaLdGhGzoMQodMdMhBh5noMB8dVjTWwf9O gg5t0KE7OgxQv5tEh0nq3yJFh4fQ4Wl0+AM6bEOHQ8SeFrfIZmKibC9uk5ejwzB0GIcOs9ChCB1+ jQ5b0WEbOuxFh8/RoQod/ktOdAXkrS4sxHWpnOkaIue4MtEhGx0WoMM96FCMDhvQYSs6vIUOu9Dh U3Q4hg5/l6WGJd81LpR7jE7GSONy43rjKmO8cZNxs3GrcQvtnGAsRIcIOqxEh8c424IO29HhY3T4 HB2+RofaxjqkvpWgw0Xqt8focAs6zECHheiwDh1e4u4OdDiADsfE1dIQo2QQHQahwxh0uBMdFqPD z9HhWfXbI3QoR4dj6FArW9PXF7vSZBd8O9PVDx2uQ4dJ6DALHQrRYS06bEIHxgfXbnT4FB2Oo8M/ ZLHhlY8ZLeWfjEtk1LhCbjNGo0MOOsxFhwfQ4Ql02IIOUXTYhQ4V6PANOlSjQ42xzJ1sRNxBY7n7 CmOde6TxiPsm44T7NqaHOWpetTz8l5rapcvwxYWFVpK0zNyiCFtRrmVKy6ouWsFWVG25iamORPgv 0ugiopP1Gx6JPLFieD99QYYzKpclpeWOxDfLEJY76GxRVUBSPKLasqTlKyn5Ddujj+oCdux45pm1 a9es0RcFK/RWoOtWXVRUpJ6qLjz6orioSFcnqzgSCqYWZ1lJwjJr4w+qq45TQLKwklcEVwRHhkaG biAEI0FqT/IVI0ZkZIwYscJMkqan2iooKtJP81C5IvUM0y3NpFxV2Vx931JJSKTT5xbVRiIFlpvm ZYSqQ2ojkWkWFBdnRXJRzilp606VxZFEOC33GbZlBEWiKGYkUrwhumFDcSPtTEuavpffW8WmH+mU FX86m6qV6XHqqrUxPU4FLcs0pOmudEqhFWZuJJqRWulxC4/bqWyGLkalXj/DTBJmUlFRZmYwaHqF 6S2KFEXGMyS2JzhxxGQWWQ3JQiH1gKRKTiKVCXUWEd2aytTUrFBIhAyXkAZJLJcwjZBasXBhSmka EXURkWxGBKdyuyt9LkohWm+hkL5UJ2pDM3UZrRMm6lyG4lvUoAYG9w0D+9qwYYM2htwiK9eyEKmR pWMZHmW1kUjcav9fWLpXWsnbItsiGwlrCUrgxhbvkZa33/BCNh5Rb+T/A4v3/8DilQyFw7ugxPDC BIv3JkmvJ5Jo8qZj8jrCqrd5FZFVXK0i3MKLzZ/P6OsK+ydW726weq9berH6uNl7pfTWC/k/snvl sluj59i99tLQ+Q3f/G8M32wwfPM8hp9YaxHRLcoq/g9MP9lFOXWmj8nr6zrb57a+rjf+SNS5DiWa vzdu/l7H/LGZOvP3eoXXa4nmBNWsoWKZ7hCvR3qtgcN0gcMGqitv7Qplf4UranUv1kYc82+4qq3L 51X5HigsjOdTmc6qXeNeVGaSlBrfKlUpZl1Urdcnvf4o29Ohp0MP67CG4LWk17ft6acfWrXq3nvv 0VcDhy1XG48yqXAt5u1Uo/6qCP/VVVTzl9Nij/B6ztY9ub6K2re8ydIbUK6xOu4cl0WUcyCQ11o+ rGPHtI4dhy33JEmP0q8AE/GZ0mfxwFd38LAdr6ooZ6YsytVRbrc7fw1Ra/I9pvSoWetMJLLY5xa+ pHoXCZHS41msLDdCgoJGZVJ7LVvcTSJ+w/Y2+Ame4kuSPuVTRcpViot8UvoaRI54vNLjf0ns0WOK E3RF4mXXVWqF89j4/R2vKodUl/G60wqPW3rinhNR52oUyFIdp7qxriUZujxdHA1WMim3wC88PuFJ Hh4aHuoWUaGpaCqcaCIzM4t8CUlxHV1+dapyomqfdPnqRko00K1FeysjqERwu4TLrZzA61JTV0j7 USjikdKDCMqRIrxHujiXhnQnVQYM6UsKJvhSUN9RJ85GlF/dqWyQsNK5Ua94sNKNxsqhIm639JnF bHELsxyf8nmFD5Np8Kpl+JUe5Czp8w4e6pQ7dLC69J0p1Ba8vPCM7vczdZ50Rje13rF0Xp/O++Dy 5fG8Kp+tc5/T7drAUuu9S5XsqY8840uWvkA0K5rFYLDhoeBDWPvqoLJ6XahyMMfDfF7pSx4cr3vd NpTlrq6pci/H23wemuVc4m2F8T5S9qHV8AifVe9vqfUVd/xW1SVlRbBuOmrwOZ9FNu1zjtM5lupe jGUlmzJZOUii13niXqfj3Od3u2S3SFZuV+93HuKWKtuPMPcvblzsv3S85CSZrEWNe16ylMkJXfC/ 5HqqqQV6JKv+33a9ZOlKrnM9JYNusDLy/9D5UgyZnOB8yun0rQbvU5H6VoL74YDOrWCwsQs6YuOC ydoFtU1iIO4CJFtRkOwTyT71x8AqpBNCkWURHh2KhJItmey9ONupRyj7YnXtq13p+GHhylptB8oP 447YcK13kWSvTE5uJ7IiIYEs4kGnnEhWpJ3QUQ01txNaca55aGNMbfBR9ZQGH+WpAZncJJoWTdvQ ZUOX4hHFI9Sa5F7rXqvQ0k+JRjYQiglFkRWEQsJyp25tRU4jpx3KdVuR7KHZehJ3vLb+2vHaQt3M ghU0JcPSCnpEcoLfpp7TtobCBwtd10JqdnWqE7qoSm9IDaWGkr2IolKpcbC5HhOddUZ84axdGpP1 e6Tfq8p7dYeaine82mgprmNdbP2vUbHX9I8vupVbE5sk/En9Gvw6RNOsBscuXHxO4YWFznBZL1HA sH2Jvh2M+k3p12NB3LlX+KX0J3ZfxEqWVspr0dLgioSgF+p1D2m0ak9uiNE+rq/rWqP+kXW1do87 eSS+QlMDKOMnw6kZCtU6TeunS3UegAys2i2KH96FhXujdX2dr+ui9NoUZ09OTJ7Ka4GKrLU4C0Vq /dLlr1+CKW20BrlFuNO5Dq/er5JC8WUri1jpUm8z4hyXT0qqbGJIv3L5ULxUzoL6nj6r8/lQRN+r bGRXTt5GXq/d3l/n9n6PcnttxQUrXC783uVaUeBPFv7kFJEi2uhwWeSySFZ0GZOdmu/8Xun3tRO5 kSwRTQhZ3Gkn/D7p958VJbyIRRO2bZGSyFmhLeisuj6j755tuHHWSaezt4vkhpyy341nz4rmRttF dGRDmXbiA6J+F8I3uoE9m2n12/pc9TArIcFZf4r0p1a2rWxbPXBfj/KZ5TN3jt6zZ8ead9eU+Ev8 +mGV0erovmg5YQ+hlLA9WhLdFvUnS3+gnZgbV6QuZEXnRpHAQp8zpSUlJaVOM7VgZ0SpKNGhVKhz 52pbREswcFo0WlnQNsU09xT4LeH32g0VTzun2Q1bdmSI8DeR/qbbzG1mycqcNTlrpu2ZtufK8j4T BhakZaRl6JqUlEybNjAtbeC0aSUlep2+uNQ0l5aW7l0QsGTApwo6dKxEbccOOS8s03Tp0wbqeINt wHQdP32AelugsqWldNfkgQFTBsyBWVlZtVnxza/il5WyLY4uJcfScx9RUhJwyYA7GhWivhmpbjuQ lJEhREbDVhnwyIBXxZbuKa+uLt+zpzSeMWHz+qW3yaHKrzJKGwX9SlP/POcFZ5o+nzbQnxB37JDq G3Wjvn20VS9CyyvrHqFegQp2qM7xrylQc7fZ0Nx+uuz4cxBHvQSqn0DkCBWuJLQleFP4T1lUTtr0 9VPW99k6sDotKy1Lvw3prlE94z9/3jRChtCVOONPS8vAws4EXK5AgqGjo9aqYI1pmv5+aIeOSYZ0 JVHDqFqHeznTv8nSN5gAvElKf6G6QM0GXEm3TGLB4qY/M1SqOrfLysrQN/VZfFPx+mZ1Y2t0sldn NNqqk+p7LQlrsfaoTZvl4lLDMAeaKF66WP9GzSc2uiYII2dh3kzRfHre1DtF/5nZ+bPFaGLkjeOG BdFC2Lb+WbIpAkyBzpUUHgaqC/V9546LCbKJaEEwrsvMHCE6jht7fVBk3DRuVJBp1kmjfgeaKlrq K4MnNK0vnRWF/t2Fc8UgIi4QrUWbnNx5ueIZvX9W77fq/ct6/6beb79zat5ssVPv9+p9md4f1PtK vT+m91Xqd/jipNpLU+9b631PvR+m9zfr/R2z7px1p1yq9yv1/gG9X6f3T+r9Jr3fUv+bzH+1lz9y b6GkgQYmCmOt6PL/756Lfgj828cUcbH+G0D1V2KF4mGxUbwotov94og4KV3Cq1tqxVtbJdTf3xrk a47nSfXze9nfORatdI6/qk3Ig719t7HRtfSfaXyd0rnxddNmja8veKzxdaezja+7nBPfrXXj6z6M Da7E61MJ8aaQ1w5sfD16NUcfNt1FZKq/WSZPofo9vitTLHM94/pEbDB+ZfxKlLnz3U+LA0kfmUXS 8N3oy5av+e5j5b3Tn+q/2nWVf5L/SdfCwJTAHa63AssCa1w7Ulwplmt/yumU065PhYzUKG3MjwMv nzfsIxwMfJkQjsfDvvOEUynt60MXQn/CcMIdOqw/NwT2pWxM+WPqunjYkBCeVUEt5s4TfE0z68Pq pmvrQ40TmrU9T+hJ6NP8sYTwjBN0zDmh+YvNd9aHvRdWEo6p0MJ9vtCsZ4tmLbq0XJ0Q1uqw/bxh X8vv60Ja87TW9WF4PIw8b8jU4eb4sXGIxPcqXakOZfXByf1ZWnWrbq2mtHqy1WYVzi291ZbzBaf0 Vq+2OhIPpxqCekqr7/WzIoqLRnfoXx9GdxhXH6bEwx2ESIc71D931THUqWen4R3uYN+z0/bOOy/5 WIdTXSYScrt2JvToeqRrLRzperbbzu5PqtD1SPc3ux/vfryHu0dKj+Y9XieU9RxMyOw5sdcT8fD2 ZZHenXt/3efhK/sQBvdN6zuxb0G/F+PhzX6l/cr6dyP0679ywKFBpg7Fg7brcGbwlYOfj4eXB53h +vnB1fqqeohriGvw80N6hB4IvTm059UTCJ9dO2NQsZOaY7WT6rrBKt11o0e2H5kxcvDIzaM665A5 6g4dCkatHPUE+4JRuwiVoxeNjoz+7PpcwroxWaTKHLN3zN5Ru9gfUmeEI2Oqxnw/NqLDprF7dPhs bBV8NrYm0z22hviqzImZhzKP3JBPeHhckHSbxtY4MeMWja0Z9+W478Zn3lw6YcKtzW5te2vn6e7p E6eXT/++7jijB+HF2amz2+cW5BbmRnOP5Fbl1sx1z7187vC50+bmzl00t2juurnPz3157o65+/Ny 8x7O25x3cp6Y12zeiHmT57057+P8PvmT85+Yf/P8ovlvzz+1wFzQY8E1C55fcOyu4Xd9X9C24JqC rIK8gicKthSUL2y/8GcLX15YvvD7Rf5FLRb1WzRs0ZRFmxaV393t7uF333b3+rufvfvQ3TWLQ4sX LX5zibkktCRvydYlpUvOLG29dMbSTUurlvVfVrBsSyTzn4xVL587HjUebSILGoIaR/QPE+LBGUH+ ie+NPNfjGvuJY+nnHXXqRp6E0HjsiJQ2BDU6RMoagjMuqDE09dm00pZrGYcPDq5m1NRjsD4y3jbN ZHxdn7IxdV1gX/2YSdqmNR2mqLyBl1PWN4ydjkqMzsP1+Oukap+ysU49dVeNxTrtQRWv08cVpNyX A18ykm8kx0Fd2j5qt47jQR0aZofj58wKwxPmgYaZYKOq9w9G/2d/MPr74mP+aj3e61Fel0PulOGc r68bCemPzfH+Ymxyxh9nfIv3I2MiI6DqtSn1o2NdjzLGpY2MHFE5Gvq4w7jIkcgRSlOpThGX2epI h3E/tAnGwbKEEfU842ziuPrDMTU+cpdqa3JG0dF146ca17nDUyNVrTZzZ1xa5pV9xuxt4XbmMX1k zmr5/YWVWFWzutmnblZp1raFu2EGcqxSzW06tVulIO/2Fs1UjLqjUqn7zdoG9tVZalrrZm2ZAZup /OrcudswjybOpKouetaMz5sJM2czSjh3nlzbaHbcF58Zm9fVnvjvnaer54/KvLAybTj1aaS+Uk1p TE8leGydxo4nKjUdS+kwBb1Hqt5USqRlNn9M9/dm1TcJXt2/1RbaWjfDljmlRqrSIpEqJ6gnqGOH capX1JljaeoYqerUs+PlDs4M1/FyPSslBDXDObObnh//w6Dn1ITwwxR6pk0I8Rm3Pvwwh5pp/72g 5+IfHepn7H8SzlVKhfp5/J8EPbP/6KBXGz8ynKuOXqMkhB/qp9cuCUHZvdPT/174Ycn/unY/Ljg6 q7VLysZB5sj2g84EDqpVjw7F+o6pVjr6qnhke7UGiscRWEH1U6sm564a+9WZCnp1NEGvrNQaqnpw tV4fsTribPugYr06idSvYlTYNDYy5tDYiFrB6KtN8XWOc76JVdARdUetaFS+MfGgVzz5em1EWh27 Se1bbSH1JrWaYrToPOaQXncVxEOmvtNZrbr0VeaYQ2pciscRWLllsFZTKzSVb6U+I+h1Wq5ez5FW r9Tq12ujMoe4tCJnlBY35DtKDDJ1e6ixU9NRu3TZ6kkrdVm63Mae+MMeTbSDSz52roSpvg+jvguj vgqjvgmjvghjvC36CvVVhn36iyvqrEp/sULqL8K41Ddf9BdfksVz9hmxwz4js8QFMluMk5NFK5kj 0uUU0VTeqf5/aruP+qqKMdP+s5D6aypu0vpJ25S0ftL6dHlH9fdTvPI20Zb4DsSPJ/4i4jtQVifK Sif349TnM/V/0tsvqi+kGIupxxL7Ferb3/jCfsT4UmQYR8Xlxleiu/GN/aFxnLddVfo+/WUUt/qK ifqGCbVZq79iUiCaiJEiFfqLrmIATLE/FFNhGsyzvxL59ikxHxbAXVAAC4VfLLL3i7thMSyBpXAP +VfAvbAS7oMiWAWr4X5YA6+JYeJ1qOX8LNiiqxQgIVMMkDfAOLgRboKwGCtLRTtaHDZuFgONScIy boeZokh9W8JYLoLGPeJi91P2fvcGeBr2i67uj6AMDsDH8AmUw6dwECrgEPxFdE1KtT9MqrT3J/1V +JOqOP8Wqu39ZpIYaXbl2Ft0Na/kONP+0JwFs2EOzLe/MhcA2phoY6KNuQjQxnxBDDC3witwWgzw dBPtPN3hdtHVkwWTYS7kwUKIwHJAI08xPARPwdNimOc5jt/Cd1ANf4OTcBrQ0MqBKTAV5ot2XiEG eJuLdtp2j+kvzaizb/TXYy7Eal/Cal/C2jpjbUOxtkKs7UasbTLWdh3WFlJfelHfc1Ffc1HfclFf csFufqm+5WK8bW8yvsDOjgrDOIYNfiMmaTv7Un/RpWm9V9wmeiWUP4LyF1D+1ZTfl9QTKXstZb9C rt6UvY6yH6e8NynvZpFCKSco5QSlpFLKJZQym1J6UUovSulOKer7RJ+pb7eoL7eoL1zor7aolr6n vrIi0ijjz5TxZ8roIm+3X6ecXpRzO+X0oZwbKWeIDNsfUFYvud5+lZxvUJ6b8hZQs2mUeQE1u4fS 7jeO2Keo3S7ja7z1G3GpcTzusU0ptRulhim1L6VeTakdKbELpX2kvtSgvzz1CvabHB9h/ouRRI0s j4p77CqxAu6FlXAfFMEqWA3qG01rYJddK3bDHngf9sIHsA8+hP3wEZTBASiHv9i2+Aw+h0o4DEfg C3u3+BKOwkm7QvwdPz8FMaiB01DL6PZ/iP8e/gFn4L/gLHWx7SopQOpR8QtjIhb2M/uEcRvHLPuE e79d5f4IyuAAfAyfQDl8CgehAg7BX+Bru9b9DRyHv0IVfAvfwQmohr/BSfg7nALq4j4Ltr07qZm9 2xOyaz1Xw0gYBWPsrzw3cRwPE4mfBLfB7XaVJwsmw53EzeWYB/mc3wUFsJDrxRwjHJfDSs7vA/rB 8yDHYo4PwS84Xwu/hHXwCOU/xf2NnD/D+XOcv8D5G0AfeegjD33koY88FbbtOQT0kYc+8tBHnkry HIYjQB95vrErPMfhr7SlCr6193m+gxPEVVP23+AknOKavvPUcDzNNX1k5cAUmEp/ucQDormeuQzx ALY7HhtWs1cSV7/naiRX12HlO4wPRHchuVsjhmOZFVhmBZZZgWVWYJkVWGYFllmBZVZgmRVYZgWp v8LSarG0WiytFkurxdJqsbRarKgKi6nBYmqwmBospobnqW+5VBi3iiQjGyZjQTn2F1hNBVZTgdVU YDUVWE0FVlOB1VRgNRVYTQVWU4HVVGA1FfRkDT1ZQ0/W0IsV9GIFPVdDr1XQaxX0Vg09VUNPVdAr FfRGBarXonotqteiei2q16JqFapWoWgNitagaA0qVqBiDSpWoGIFKlZojz0oPGg5FE+2mHvfYu79 k7GPufZDZiFmG63vcVr4IS08rPVdzJX6Olxb9C2khE/EBObJdObJdObJdObJdObJdObJdObJdObJ dKH+1cU18IC4krmyI3NlR3y2DJ8tw2fL8NnD+GwMn43hszF8NobPxphPm+GzR/HZo/jsUXz2KD5L f4tRzJt98NPD+Onn+Olh/PRzY7LobOTATLGCebQd82g75tE2zJ3pzJ3pzJ3pzJ3pzJ3pzJ3pzJ3p zJ3pzJ3pzJ3pzJ3pzJ3p+OJRfPEovngUXyzD92L4XBk+V4bPHWWOS2eOS2d+S2d+S2deS8dXjjK3 pTO3dcRXjjK/pWP/Zdh/GfZfhv2XYf+Hsf/D2H8M+48x/zVj/muG/R/F5suw+Rg2f5Q5MJ35L535 L535L13Zu30SrU+yPnvAvpceGMF4fpjxfD49MYKe+A2xa7D2q439rKTK7LPGATFZ914FqQ+SqpwZ 8wF7KVeTybufvB9xN0TeB8j7LnlHkreMfD8VZtyPbiHlAVKWkXKkXl8pm/mtLmkq8UOI30v8x8QP oKRVxG6lpGGUtIuSMnT6T/U68TO9rxE+2US0kxNhJsyCOZALcyEP8mE1M31T9UUu9fUt9e0t9eUt vTbaIFoab4grjG30/xHRgVn7RlaJzZi5W7NK7GB8zcjwDTU4zr2/iiuYz/PsbeRowZqyvZrTyT9T XMcMNhGbnySuM27Tq6/rRAo1a0PN2lCzNtSsDTVrQ83aULM21KwNNWtDzdqQszk5Z5OzOTln65wB cgbIGSBngJwBcgbIGSBngJwBcgbI2Zmcl5GzMzkv0zn95PST009OPzn95PST009OPzn95PTHc/aJ 5+xDSyaJbpx10xq/pNcIp9V3udR3ceAGGAc3wk3Cx9rNx9rNx9rNx9rN51W/p3Wrb2up70TFVxo7 dB8dFmWyi31EdoVu0B16wKXQE3pBBlwGl0Nv6ANXwJXQF/rBT6A/DICBMAgGwxAIwVAYBlfBcLga roFrYQRcByNhFIyG62EMjIXH4HF4Ap6Ep2ADPA0b4dfwDPwGNsFvYTP8Dp6F5+B5+D1sgRdgK/wB XoSX4I/wJ1ZrUY7b7INyO5TADngHSrn/rn1A7oT3YBfsBvWNr/dhL3zACmIibyu32fvc77CSKIV3 YSe8B7tgN+yB9+0D7r3wgX0gqal9JKk5XAgtoCWkQSv7iPkgPApoYD5pHzM32SfM38Jm+B08C3/k fglHVpvmO5zvsw+YH5G+nPMa+4jnIrgY2kEQ0u0TnvbQATpCJ+hsH/BcAl3sg56ugC14sAUP/e65 nOvexA2wj3kGchxnn7Bc9hHLADckgQkesMALPkgGPwQgBZpAKtBeqxlcALTbot0W7bZot0W7Ldpt tYY20Baov0X9LepvUX8rHdpDB+gInaAzdbrcPmb1hp/YB6z+MIB7IbgGroXbSTeZ4zTippNuBoTh DphP3BJYCssgAg9y/9ek/y3pN9sHrd9x/Syc5F7MPuKVQFu9F9gHvLTDe6F9zBvEhu7W35FDHYk6 EnUk6kjUkagjySFRR6KORBn9tbmm0AwugOZwIbSAlpAGrUB9j059ja4dBCEd2kMH6AidoDNcor5j yFt2V+gG3aEHXAo9oRdkwGVwOfSGPnAFXAl9oR/8BPrDABgIg2AwDIEQDIVhcBUMh6vhGrgWRsB1 MBJGwWih/hXbZDkGxoL6kt4NMA5uhJtgPPW+GW6BCfBTUF/BWwrLIALLoRDugRVwL6yE+6AI1Ff5 1Df5HoKH4RewFn4J60D9m9nqK3WPwxPwJDwFG+Bp2Ai/hmfgN7AJmAHlZvgdPAvPwfPwe9gCjLWS sVb+AV6El+CP6ouA6ut8sB1KYAe8o76NBzvhPdgFu+HcUWS8na2+GMg80ISRfyDzQBNG/4Hq+4Fu Rjw3I56bEc/NiOdmxHMz4rkZ8dyMeG5GPDcjnpsRz82I597CO8oLsBX+AC/CS/BH+BO8an/rfg1e hzfgTXgL3oY/QxS2wXYogR3wvvC798IHwp/UVPiSmovkpAuhBbSENGglks019rfmz+0q80HO13G+ 3v7KfJQ5iT7Qo9kG4miL+RviqLNJnU3qbDJKmy/YX5pb4UXiXgI1yr1M+le49xrxr8MbXL8J1NOk nnr0e5frXcTt5riHe+/DXvgA9gm/+RHP5t3O5N3O/Jh7n9in9Uh5kLrxPmd+RV7eWcwqzlldm6yu zRPAO4vJO4vJO4v5dzgFMaihbaftLz0p9reeJpAKTSHNPu1pBa2hDbSFi4TPczG0gyB0Fn7PJdAF usJl3LucY29glvUwuzqjrvBbLpFsGeCGJDBB/ZmyBV7wQTL4IQAp0ARSoSk0gwugufBZF0ILaAlp 0ApaQxtoC9TTop4W9bSop5UO7aEDdIROcIn9rdWdd7QecCn05JqVgnUZ53UjcR/Or4S+0A9+Qjv6 w2jOrwfec62x5Mu0d1g3wDj4qX3aup16TiPduaM077sW77vWXbCEOiyFZRAh/Sqejf/rUXsdx/WU +yg8Bo/DbylvM9SN4s9xjz60YuT9h33aK+wvvVL9zyt2lVf94baPY1PuXyD8emRnhvK25F4atALG Y29b9XNJ5enxddUS9e1NvUbbXn9/tvrmpf45ilpvfSeSXCPsnxnX2yWsTn3qZ1vEfSt6uDLs464+ 0BeGwAj7Q9d19m7XKLieVfl4+zNWF4dYXRzyTbB3+ybCffZxXxGsgtVwP6yBnwPvcr4HoRgegofh F7AWfgnr4BFYD4/CY/A4PAG/gifhKdgAT8NG+DU8Yx/3d7ePC4Oa1rgm8E6cxzv0AOofo/4xV3/7 KPWPua7iuMo+7FrNu8skcSnj16Wk3O270T7quwluhp9Bjn3YdwfMhNmQC/lwnx2jbTHaFqNtMdoW o20x2hajbTHaFqNtMdoWo20x2hajbTHaFqNtMdoWo20x2hajbTHaFqNtMdoWo20x2hajbTHaFqNt MdoWo22x5JH24eRRMBquhzEwFjLhBvswbY/Rh33tT+ihPS7dj/ZO/ZPDdrR9M+3e7Jpkb3FNgVmw yo6igfr260Havpm2b6btm2n7Ztoepe1R2h6l7VHaHqXtUV+BvcW3EO6G5XCvvYV6RalXlHpFqVeU ekWpV5R6RalXVAylB8L0QJi6fUEPhKnfaSzoFBZ0inp+Tk3KqUm5Mf7sKWPC2RizS4Ce6cXsEqB3 esXf8XdgXaewrlPUrpzalVO7cmpXTu3KqV05PROmZ8L0TJieCdMzYXomTM+E6ZkwPROmZ8L0TJie CdMzYXomTM+E6ZkwPROmZ8L0TJieCdMzYXomTM+E6ZkwPROmZ8L0TJieCdMzYXomjALlKFCOAuUo UI4C5ShQjgLlKFBOz4TFVaiQhQpZ9MV7qJBFf7znGiEuovVjaP2Y+M9b74+/T3dDhRao0BsVWqBC 7/hPiX9KX71HX71HX71HX72HGv+Xt3uPj7uu8z3+60ybtDMT7hQQFLnIiruooOgq3u2y7LrbXffi srpi9gjUFiotpZS2lrYGcVfAcqcoFVxqLShUmQVFaBAoUgIpSTtJp9PQhKZDkulkmqSZyTQFv+c5 2cpBzzmPc/4554+Xv/nN/Ob3+37en+s3pmEmNWZSYyY1ZlJjJjVmUqORGo3UaKRGIzUaqdFIjUZq NFKjkRqN1GikRiM1GqnRSI1GajRSo5EajdRopEYjNRqp0UiNRmo0UqORGo3UaKRGIzUaqdFIjZnU mEmNmdSYSY2Z1JhJjZnUmEmNxqheLIyyOMXiW1h8NYuPYuG1LFwUnUCjTfTZRJtO2nTS4SgaHOXT 29i/if2b2L+J/ZvY38n+TvZ3sr+T/Z3s77SOTuvotI5O6+i0jk7r6LSOTuvolCuzw4//oN6NRmfF Pq/GXYjZ6twcNe4yXA73tuKeN2vdMjVjeXgxuTQUkt/AMlyL5ViBlfgmmnAdvoXroTYm1cak2phU G5NqY1JtTKqNSbUxqTYm1cakuphUF5PqYlJdTKqLSXUxqS4m1cXDpiGBpJpXq+yFibWX5Xhejufl eJ5utX36GT7dKnfzcjcvd/NyNy9389ZetvaytZetvWztZWsvW3vZ2svWXrb2srWXrb1s7WVrL1t7 2drL1l629rK1l629bO1lay9be9nay9ZetvaytZetvWztZWsvW3vZ2svWXqtZF4Yd1H6Jwk+/WbNq FnVH57Ao7fPdPh/jjdd543XeeN213a6d6tqkTEmw9L0yJcHa9x76GdBveOh1HnqdlWlWplmZZmWa lWlWplmZZmWalWlWplmZZmWalWlWplmZZmWalWlWplmZZmWalWlWplmZZmWalWlWplmZZmWalWlW plmZZmWalenoXJY08c1mvtkcmx2dxD+bWfBVGXBABlRYch1Ljjv0k5njaj+ZYcldtZ9m8d1mvtvM d5v5bjPfbWZVE6uaWNXEqiZWNbGqiVVNrGpiVROrmljVxKomVjWxqolVTaxqYlUTq5pY1cSqJlY1 saqJVU2samJVE6uaWNXEqiZWNbGqiVVNrGpiVZM8vnAij/+UFS8f+v+czrfq26z6kSjJ3lb2trK1 lV3HsulYn9zBnlb2tLKnlT2t7GmN6mIL+fXqcCC2KLwWu05c3BRKsTtqP2n37njsulCJJvnfA9GZ rqjErhERi3Fd6IhdH02Nfdu3bwz9sTtrf7s4HIzdHQ4mzbdJ823y7XgHTsY7cQpOxcWuuQSXYha+ htmYg8twOebi67gC8zAfV2IBrsJCXI1FuAaLsSQcnLBn3Ep7Y8tCH1v2xG4P+2J2etEXY1eK9gVY 6N1rWLkYy0NbbAVW4pu4Ljo2dn3YEFvluptDT+wW3IrbsDo8zr7Hk7HwUjKOyZiCOtRjKqYhgSRS aMBhOBxH4EgchaNxDI7FdByH43EC3oYTQ4mGJRqWaFiiYYmGJRqWaFhKfjS0Jc/Dx/BxfAKfxKfw aXwGn8UM/BnOx5/jAvwFLmbHJbgUs/A1zMYcXIbLMRdfxxWYh/m4EgtwFRbiaizCNViMJeHxaLLI 2UXFbVR8NXZnGBZL14URcTIW/S0vVHmhygPjPFCLsFd1nIqOU3FFhcpVKld1mIoOU9FhKjpMRYep 6DAV6lepX6V+lfpV6lepX6V+lfpV6lepX6V+lfpV6lepX6V+lfpV6lepX6V+lfpV6lepX6V+lfpV 6lepP079ceqPU3+c+uPUH6f+OPXHdbmKLlfR5Sq6XEWXq+hyFV2uostVqFulbpW6VepWqVulbpW6 VepWqVulbpW6VepWqVulbpW6VepWqVulbpW6VepWqVulbpW6VTl3teiu5eIyml4ruq+LDqN2L7V3 U3tfNI/GzTRuFun9rtxM615a98aWOF8WBnxrROQXRX5R5BdFfpEf3uCHZn5o5ofh2HfD8zJguwzY LgO2y4DtcuklteE3fNTBRx181MxHzXzUzEfNfNTMR8181MxHzXzUzEfNfNTMR8181MxHzXzUzEfN fNTMR8181MxHzXzUzEfNfNTMR8181MxHzXzUzEfNfNTMR8181MxHvXzUy0e9fNTLR7181MtHvXzU K0OKMqQoQ4oypChDijKkKEOKMqQoQ4oypChDijKkKEOKMqQoQ4oypMjHzXzczMfNfNzMx8183MzH zXzczMcdfNzBxx183MHHHXzcwccdfNzBxx183MHHHXzcwccdfNzBxx183MHHHXzcwccdfNzBxx18 3MHHHdFsHszzYJ4H9/P3M7y4j+dyPLeX50o8V+K5Es+V+D/F/4/wXpH3irEbvHcTT68KD/FgPw/2 82A/D/bz4CAPDouTjbzYzYvdvFjkxSIvFnmxyItFXizyYp4X87yY58U8L+Z5Mc+LeV7M82KeF/O8 mOfFPC/meTHPi3lezPNinhfzvJjnxTwv5nkxz4t5XszzYp6XSrxU4qUSL5V4qcRLJV4q8VKJl0q8 VOKlEi+VeKnESyVeKvFSiZeKvFTkpSIvFXmpyEtFXiryUpGXunmpm5e6eambl7p5qZuXunmpm5e6 eambl7p5qZuXunmpm5e6eambl7p5qZuXunmpm5e6eambl7qj9/NShZcqE9n4X14Y5YVhXhjmgQoP 1PZNw9Qdpu4wdYepO0zdYepWqFuhboW6FepWqFuhboW6FepWqFuhboW6FepWqFuhboW6FepWqFuh boW6FepWqFuhboW6FepWqDNMnWHqDFNnmDrD1BmmzjB1hqP3qAyvqwyvy/6ifp6I3cCKG1kxsXqv 78Rq/f5ufftEU91JeDvegZPxTpyCU3Gxay7BpZiFr8EESesxWo/ReozWY7Qeo/UYrcdoPUbrMVqP 0XqM1mO0HqP1GK3HaD1G67Hoa7Tup3W/FRetuCgLCrKgIAsKsqAwof/vMoDu/1Pkm+BjtZ9s/O+j vZ8/+vmjnz/6+aOfP/r5o58/+vmjnz/6+aOfP/r5o58/+vmjnz/6+aOfP/r5o58/+vmjnz/6+aOf P/r5o5+CRQoWKVikYJGCRQoWKVikYFE2FGRDQTYUZENBNhRkQ0E2FGRDQTYUZENBNhRkQ0E2FGRD QTYUZEPh/yIbCjxU4KECDxV4qMBDBR4q8FCBhwo8VOChAg8VeKjAQwUeKvBQgYcKPFTgoQIPFXio wEMFHipM9Pihif8X8kN8VeSrompTVG3ytC/SvqZxkcZFGhdpXKRxkcZFGhdpXKRxkcZFGhdpXKRx kcZFGhdpXKRxkcZFGhdpXKRxkcZFGhdpXKRxzcYiG4tsLLKxyMYiG4tsLLKxyMYiG4tsLLKxyMYi G4tsLLKxmKzFwkJcjUUQb2wssrEYHaEWl38/Z0TaDROZXlFTK/+nHDG7X21GtTOVbSnZVifbXpVp x8q0RDTzzYqyUDdehmvty6/zrH8PQyJ7yNVVuTmkO4/61nspXKHw6FumpiHRPSS6h0T3kOgeEt1D /5+qzZDoGxJ9Q6JvSPQNib4h0Tck+ob+n05Ftd1KlVLPv7lvGY3ih96r8tLB6B9p20LbFv4b5L9B 2tZ2NjmemELfPvr2TdS/Vc5vt0e4w6S02nt3hz669tG1j659dO2jax9d++jaQtcWurbQtYWuLXRt oWsLXVvo2kLXFrq20LWFri10baFrC11b6NpC1xa6ttC1ha4tdG2hawtdW+jaIqYGxdSgmBoUU4Ni alBMDYqpQTE1SPc+uvfRvY/ufXTvo3sf3fvo3kf3Prr30b2P7n1076N7H9376N5H9z6699G9j+59 dO+jex/d++jel6zZuRBXYxGuwWIsCX0TGh84lAnV6OjYo9H02NMmzmfE5bNhRez5sD6235xRDqti B0JbXOWMn2X3+r6wIf7BkH/zt5W/EB0R/6eJ/x5T7XcK+1M7wxYeW+u+D+MZGfBsyMQ2ifTn8Lxn bnZ8MeyMbbHTzXhah2Mn+qNpsQGZWjbjVkxCYxgPw/Eo9MTrMRUn2P2/L/TGzw774+fgAzg3VOLn hd2pxlBMXRJaU5dBjUhd4Tgv7EzNh5qQWuq4zPFamKFTTdAxUzdBVqZW+fw276l9qbucr8Y97rE2 HEg94P4b8LOwP/VzPOK9tPPHHdmUavNeO7Ziu/MsdnrdhR7XDYae1H6MhZ6GY0Kp4VhMh91hg91h w+nenxNaG8z0DdbV8O0w2nBT2N9wB+7G/aEU/eUhVXP8VKXqdqoOUnWQqq9TdQ9Vs1TdTtX9VN1O 1e3UrFBzhJojlByh5AglR6h4gIplKpapWKbgIAVzFNxOwe0UzFFwOwWzFMxSMEfB7B8omKPgIAUH KThIwSwFcxTMUXCQgoMU3E69QeoNUq9MvTLlBilWpliZYmVKlSlVptQgpUYoNUKpEUqNUGqEUiOU GqHUCKVGKLX9kFI5Sg1SqkypMqXKlBqJTo09GJbGHg0/o1SzGDxIoXVU2RvbFWaJs4WxgXCv6P5C bNSkfSB8Qpz9Jh4Pm+J14bvxVPi6aO+IHxNOiZ8cXRp/V7hK5J8af2/4DNXuF/3ni7nvxz8Rro1/ Onzp0G9ndcf/KdwXvzDMic8OG2u/v8SqX6lJT+sSz+L58IonvsYfuzwx7wkD7jrkjrvdcZ9cOk8u fdyO8EEeezq0+1YtX16ayJH+6B2+vdU3X/DNPdaWt7akO2Qm8uGDIeObT4cXfOs133rMN472jVc9 r3sif+2qJ3L4ZHl6lvP3hV2+1WOVm6K3i6z9E9/cJLKew2YR86JvbxFVGVNkh2Nn2CM69oiOPSJj j8h4VWS8KipeFRX7RcV+UbFfRFRFRFVEVEXEqyKhKhKqImEPz+3huf28Vqv8/dFh1lNn5Ws970HP /SVbH8fmME7XLnrmU9eEivuPuP+I+4+k7nb+g1Bxn5Fosm+NWvmVvrG7Fvcm4QfVkkfZ8mxo8+7O WLs6UtNwVyjQrd19t7vv9uhCT13l6hVyqnciWn4Zlnn6Mt8cpsQ4JcbdoZcSgRKjh/JqlBKjsWx4 2B3TIqktVhQ9CRwTLolP543jcDxOCwvip+NdYW/83fx8Js7iPbrHP+nzT0/87vLZVnO23Oul7ih1 R+VeL4VHKRwoHOReLxWWUTpQYhUlVlFilfzrpfY4tcepPU7tIP965V8v1cepPk6tZZQfpdiy1EMq 0cN4IixIbXJ8Ca3Ygh3I4RWfdTu+6h67w4KGKPymYUp4uKEO9TjF+RmYo0KtDKvkYC9vjjfcGXY3 3IXV+B7WhIejpIgcEY27efoDqs8bqs8bqs8bvP5hmf6GTH9Dpr8hq9+ITuKPmi8rtB+i/ZBv1alR w2rUsBo1zPZRto+yfZTdQ+weYvcQW4fYOqS+DKsvw2rLsNoyrLYMi+9htWXYWketc0itGFYrhtWK 4UkJT1wpAu7k/V/z/q28f2tsI4824+nwfGyTrvgcng/3i4KDsa3ez4itbFgY2xGejOWwE114BbvC t2PdjrvR6557HPPoQ3+0UrSkYwWv96Io8gYdS9gXFsSGMOz1CPaH2WpTm8qdVbmzMvgLatSW2EGf vY43wsbYbx2DLjwJMdTq12TRNsXrOnUqEVbEk16nwtyJena44xE4EkfhmHCeaL1AtF4gWi/QW6+P vy0sip/os5NwcvTP8VMcT8Vpat7peFf4l/gZzv8I73Z+Jt7j9Z/grPBZNfJfVZaHeG0lr63ktZWi /a/Vy5viH3LNh/Gn4Zvxjzh+FOeF5fGPOX4cnwhflhUXxD/l9afDlTLjC4d+Y/YhGbIo/sXo+PhF mB1eVl9/mpod2lJzMC8clCUHZcitMuSgKFkpSlaKkpWplT7/Jv4N/47v4MZoeuomfBerXH+H9+7E Xc5X4273+b7zHzjeG+amfoj7sTZcn/pRWKSbLU896Pwn+CkeCufLqvN1uOUicKUIXGk+uF6XW576 z/DN1KN4zHWPe+8J1z3p9UY0e3+T8+e9v9l9W7z3Il7yXiu2oM292rEV21y/3bVZ7PBZDqq36F4p a89P7QpPytzzddHlsvcC2Xt+qtd7YjAlBlOvQRym+jEQfp0ShylxmCpCDKb2YQjDKsAIKl5Xw8bU AYx7/QbEXErMqQorGsRdg7hriIeNDZMdp4SFqsRCVWJhw1Tn01SPBMRgQyr8uqEBh3l9OI7w/pE4 Ckd7/5iQ1emzOn224Tj3O941J+BtOBEn4e2uPdnn78Qpnn+q91RY1WhFw/LQJsNXNnw7mt7A1w18 3cDXDTfgRtzks9vCIpm/UqU6X6U6X6U6XxVYqVqd3/B991lj3fe65/3uv9b5j7AOPw4LolNUiStV iZ9PdOZnJvr5cypBn4xfJbO/LLMflbUbZO0Lem5Zxj4lY3tlZbtsbJGFG2XhNln3ZzLrIpm0Qcbc JGOekzF9suQOWbJNFjSL/h+J/r8R/b8W/bV/qfAhEf9y9N/Uqwes5Kc61tbYBl3qUTXhl957HM/o c8/6bFPoVD07da5fq1mDOtejeuCg1Q7oXo/qXo+qX2ut/Dl1asDKt6hFm6w6q97sVm92W3mfep2x 8n1qdkbNzqgnm6z+IbXgIbXgIas8aJV/V5t5dK+tqX9VaS8Jj+pgj+pgW3WwR+XmoNwc1MG2ys8H 5Oeg/HxAfj4gPx/QwbamrvO9b+EG3Bg6VfVOVb1Tbg7qZlt1s60qfKcK3yk3H9DNHpWbD8ilh8T9 Q+L8ITE9oJ9k9JOMuB3QUzJidUCcbhKXa8XlWnG5ViwOiLXdYm23WNsttgbE1oC42i2udourTXpR Rkxt0uEeFVMP6HBbdY5O8bFWfAyIj90myI3ioBlPm9CeD7+k9B7doV0sfEY171LNu8TDi1TtoWob VdvExC9U7l2U3axSd1F2M2U3i429YuM11XibarxNNd4mRv5EjIypsjlVNidWdoiTvMraqrK2qqyt YqZDNd2himZVzm0qYruK2E71PVTfQ+09KmC7CtiuArargO0qYDtl96h67apeu0rXrqJlVbGcKpZT xbKqWKsq1qqCZVWwHSrYDtVqh2qVU51yqlNOdcqpTq2qU6vq1Ko67VCVcqpS7lBValWNcqpRVjXa xjubVZYulaWLlzbz0GbVZZfqsksF2aVadKkWXSpDl8rQpTJ08VQbT7XxVJuqsEsF6OKpNp5qk/ld PLVZ5rfL+HYZ3y7j22V8u4xvl/Gtsr1Vtudke06252R7q2zPyfYuXmyT5V2yvEuWd8nyLnviftNx ba7+YHg9OleW1fZZl8mo1TJqtYx6hp9XyJoD/LqOX9P8mpYtBX7t5deH+fRhPn1YRlRlQZUvVvDF ChlQ5Y8VIr4qyleL8tWifDVfrBDlVVFeFeWrRflq0XyAXg/T6WHRfIBWD9Oql1a9ovoAvXpF8gH6 pOmTpk+aPr2i+YBoPkCjNI3S9HlY9FZF72qRe4DNaTY+G24SsWMs2Ohsv7WXw4Nic1f0Npbtd5Zn 2QDLBlg2xKpWdaDAslaWtVrdfqtrtbpWq9tvda1Wtd+K9lvRgBUNWNGA1ey3mv1WM2A1A1bTahW1 vexAdLInlT1phyflPSnvSf00rO1R2zxt1NPaPK3N08qe1uZpbZ5W9rQ2WozQYsRTy7QY8eSyJ+c9 Oe/JeVqMeHrZ08uenvf0vKe3eXptf5i3R9ilXu4PL7P6ZU8e9cQutexxFXe7ilvbH/xiouLWuWr0 0B6qcOjfML0vfmF0zoRyPT7p8knPxFltb3dwQscph7414qzo/p3uP2wazpppixQeZ2eCEhGmmEnr UI9TnJ+BNWHIPXZNeKbd1Tt1kdoaR6Mz3OM5n/ySfiPu9StXvPa7/f1Ev4nUl3pMRSL8ilWfZ81X 6ThCx1103EXH2v56F/1GrOFX1vCcNTxnDc/R8vf33SfipLfsv09x/ely8QzHNa6/13u1PfckNpei 46xv2JqGrWmvNe099BOcfVY/YF37rGufdeyzjn3WsM+zhz172LOHPXev5+713L2et9fz9nrWPs8Z 9oy90enu/gTrf8PyzW+pshk6P+RJlYmqmpj4TZFvHfLlDtbPrv1Gz++qD4s3e+oTnvqEpz7xv6w8 tUpziutqVeYMx1rFWOPaP6wY0ya66H5zwAF76zp+/ccw79Bvd7zsyf888Ruj51j3Llf+gtda7Qs6 rf8pKm14SwWpdYYspdbwda3vvkatNdRaw56n3PUGd3uYF1vNbp0UXEPBNTzZSsU1MiIrI7I82sq+ p2RFlo272LiLjbt4tdUM1mkG6zRvdf5B5cjycisvt75ZOU5xj9PDGrY/xe5dvNw6UT1OpPpOqu+c +GlEWRU5EJ616kHK77TiQSuu/QxnkNo7qb3TKgetcJDKO6m8k8o7qbyTyjupvJPCOz1pkMI7qbuT ujupu5O6O2VVWdUd1/1Ejwgrh6eimC44blI6EMVNI887G3bWF53irGQPUzWflMwnJZ1yTKcc0ynH Dv2MsGBmGTLHV3W8gk5X0OnGdLox83pVtyuY0avmipKZvKq7jeluY7rbmLm7au6u6mxjOtuYuaOk sxXMHiWdZkynGdNdxqJpevkBK7lH7y7p2bW57jVPLfHg/Tx4/0RVmabbj8aPUUnOCkUWDLiqGD83 OlyFseeJzvacbDTZffa4T+1nrtWaBSxOTfwEoVC7nhLHyKdzQ9X7tZ/KusL3dkfHOqtZP8r6UdaP Tlj+RbPCRaHjLZaPsnx0wuo2x3ZsxU50gXUsG2XZKMtGo3d62hb6lum7nb7b37oz9+yip+RpW/aE vCfk39yNPzLxE788bcu03U7b8u/t0Lc7z078FHBip07b7Z6ep+32t+7Wo0ksL0enxxu8Oibca1oq mZZKpqWSNT1mTY9Rq2xiGjAx1X66NkinvSajEg+8zgM/4YGf2EceZR9Z++3I2tQzYOoZsK7HTDcD ppsB082A6WbANDNgmhmwnsdMMgOmmJI1PWaiGDBRDJgoBkwTA1G91fzck/d7YtUT93vaAU970dNe jE7z6at067PGHda4w5WVQz/D/h8eOtdkd564/jQd1oY+Go7TcPxNLz3ivbTzxx2fMGk97/hWr213 nsXvvPeKa3pcvzvs+D0vTqdaD9V6qNZDqR5K9Vh396GfSfVQpIciPdTooUYPNXqo0UONHmr0UKKH Ej1U6KFCDxV6qNATvY2dr7DxFTa+wsZ9bMywcRsbt7Fxm0m1FnXb2LPNVFkwVRbY8orJshaB29iy jS3bTJIFdmxjxzZ2vMKGV9iwjQ3b2LBt4l9Rnhb/SnRatDq6ONwdXYJLsSDcFy0Jt0RL8Q0sw7Xo DaujPchjxDUHws3ROA7idbwRbp707tA26Uy8B3+MP8FZeC/eh/fjbJyDD+CDOBcfwofxp/gIPorz 8DF8HJ/AJ/EpfBqfwWcxA3+G8/HnuAB/gb/E5/BX+GvMxN9gdnTcpF+HpyY9HX4x6Rk8i014Ds+H jZM24wW04MWwcfK94ZbJ9+GHaHW+BS+DrZN/ixBunnJEuHvKUWH1FFP2FFP2FFP2lONwPE5AT7hl StE1gxgKt9SdiQ/h8nB33Vx8HVdgYbiv7mrQvW5VaKtrCxvr7Hjqzwgb6/8I7w6/qD8T5+ADzj+G L4bV9V/CReHm+ruwFj3OX8Vu8Fn9QLivvoB9Pht1Xgk3T42FtqlxTMYU1MGkONWkOHUaEkgihQYc hsNxBI7EUTgaHwkbp34UX/H6UscVjj92XB9+MbUc2qa517Sjzcdfjo4KW6KjofpFx2I6jsMf4d04 E+/BH+Nz+Cv8NWbib/C3+Dz+Dn+PL+CfcXG4R+TeI3LvEbnXRleFNdFCXI1FuAZLwnrRvF40rxfN 60Xz+snfCVsm34AbcRO+i1W4GbfgVtyG23EH7sS9vncffhjW8/o9U7aHLVO68Aq60eP91xz7UPT5 IIa890bYUleHekxDAsfjBLwLZ4AOdXQQHevrPuj4IcfzHP8cX8ZF+AoacXm4R+TcI3LuETn3iJxr Rc61deytY68IWj/1ipo20S2hLboVt+F23IE7sQ4/xno8gAfRghfxElqxBS+jDe3Yim3IoANZ9IZH 1IRH1IRH1IQXov0YRRkVjOFA2KBObFAnNqgTG9SJDZP7Q9vkARSwF0XYnUwuYR+GMIwR2LFMHkXt e79FCBvk2yP1akG93K+X6/VyvV6e188ML9T/g+M/4ouu+RIuChvqL3N+FRZiEa7BN3A9vg35Vk+j ehrV06ieRvJpQ/1/OK513OD4BOhQT4d6OtTTQa49ItcekWuPyLVH5NoLcu2F+r0oYp/vjnqfHvJu w6T3RpOjI6MpqKv911dq/1UGTEPtr3cnkar9iUkcho9G06PzcHFYKsaXivGlYnyhGJ8jxueI8Tli fI4YnxMtdoclYa44nyvO54rzueJ8btQUHR5dh2/henwb/4Z/x3dwA27E49E7ol+hNyzh0SU8uoRH b+fR9Ty6nkfX8+h6Hl0f1f6C9IGwjFeX8eoyXl3Gq8smfS90TPo+7sEPcC/uww/xH7gfa/EjrMOP sR4P4EH8BD/FQ3gYG/Az/ByPII3/DB2x90eHx86Opsc+6PhJXBCWxv4iLIh9Dp93PjusjM0Jl8cu w+XhcjPb5+JfCleZ2z4X/4rjVaElvjC0x9uiKfH26Jj4NlNvh115Z5SI94b18T1mkXz07vhrjn21 vw3kuDc6avJV0ZGTF+JqLMI1WIwlWIpvYBmuxXLcG+aqF3PVi7mTt0aHT96GDDrQie3IYgdy2Iku vAJ6ivZlon2ZWrN0ypGhQ9QvUWPmTtkbJdSXperLUvVl7pSD0ZF1cYituqNwNE7DmWFu3Xscz8YH oulqyty6D3t9eViqfixVP5aqH0vVj4Xqx0L1Y476MadOLNUtgViquzt01H1v4l/Qd9S/He/AyXgn zsbMsF6mLZFpS2Tasvr50eH1V2IFVuIW3OX9ex1/GL1DNi2r/4nXPa5/Fbsh5mTO7TLndpmzXuas rx+MptWXsM/1oz4XfzJoWf1YdPjUY0LH1GMxHcfheJyAt+FEnARrnWqtU611qrVOPQWn4jScjnfh q+51MS7BMufXYnnomDYpdCQuDAsSX8SycHliOeRNQt4k5E1C3iTkTULeJG7Cd7EKN4O9iVtxG27H HbgTd2E17sb38H3cgzX4AeiTuA8/xH/gfqyNDk8uxTewDNdiOWibpG3ym5DfSfmdlN9J+Z20zqR1 Jq0zaZ1J60xaZ9I6k9aZtM6kdSatMWmNSWtMWmPSGpPWmLTGpDWm/jg6/LBpSCBZ+y+sx1+WKb2q Ue1V7W+PHBdbpJqlJv7rAnWox1RMQwJJpCb+gn1KNUuZAHImgJwJIGcCyJkAciaAnAkgZwLImQBy JoCcCSCn8h2t8h1tEiiYBAomgYJJoGASKJgECiaBgkmgYBIomAQKJoGCKjlLlZylSs6KvhZK0WzM wWW4HHPxdVyBeZiPK7EgzFZR56mo81TUeSrqPBV1nmo6QzWdoZrOUE1nqKYzVNOEappQTROqaUI1 TaimCdU0oZomVNOEaprQd7v03S59t0vf7dJ3u/TdLn23K6r9vGM9HsCDeDw6QeU9Qf8t6b8l/bek /5b035L+W9J/S/pvSf8t6b8l/bek/5b035JqPV+1nq9az4/67GX7MYAC9qKIQZSwD0MYxki4S2Vf p7KvU9nXqezrVPZ1qvpiVX2xqr5YVV+sqi8202fN9FkzfdZMnzXTZ830WTN91kyfNdNnzfRZM33W TJ8102fN9FkzfdZMnzXTZ830WTN91kyfNdNnzfRZM33WTJ8102fN9FkzfdZMnzXTZ830WTN91kyf NdNnzfRZM33WTJ8102fN9FkzfdZMn530t9H0SZ/H3+Hv8Q/4XsjoRBmdKKMTZXSijE6U0YkyOlFG J8roRBmdKKMTZXSijE6U0YkyOlFGJ8roRBmdKKMTZXSijE6U0YkyOlFGJ8roRBl7ibS9xJP2Ek/a SzxpL/GkvcST9hJpe4m0vUTaXiJtL5Ge9FKUmNSKLXg5SuhiKV0spYulYh+t/RtVx886XhCW62Yz dbOZE93sS6EYuxizdbe3dLXY3FDU2T6us83R2T6us82xF18VXxAeij8Rnok3R4fFn9b9Xrafb7dP 3xYdp8sVdLl4fLv9/X91uik63ekTf2Oy4P29Os9VUUqXS+lyKV0upculdLmULpfS5VK6XEqXS+ly KV0uZZIumKQLJumCSbpgki6YpAsm6YJJumCSLpikCybpgkm6YJIuTL4rlCavxt34Hr6Pe7AGP8C9 YYbOOUPnnGHflbbvStt3pXXRhC6a0EUTumhCF03oogldNKGLJnTRhC6a0EUTumjCnFkyZ5bMmSVz ZsmcWTJnlsyZJXNmyZxZMmeWzJklc2bJnFmaXA7FyRWMoYoDGMdBvA45oTMv1pkX68yzdOaMzjzf /i9r/5e1/8va/2Xt/7L2f1m7hJxdQs4uoWCXkNPBZ0zZE0p2Cjk7hZxOPksnnzXFmqZYk44+Q0dP 2TXkpvzWeQilugiTEEM8Sun0KTuKnB1Fzo4iZ0eR0/lTOn/KziJnZ5GrO8m1b8dp3nuX8zOg1tpl 5EwGM0wGqbr3+1wMmg6OtuvImRBmmBBSdh45O4+cnUfOziNn55Gz88iZHGaZHGaZHGaZHGbVqaN1 6midOlq3AFdhYZhtmphtmphnmphniphhP5s1SWRMEpm6H0z8RabpdT/Df078Vabpdc85toW0KSNT x5f2vdm6sWi6iSNj4siYODImjoy9cNpeOG0v/KS98JMmkIz98JP2w+n686KEPXHavqBkX1CyLyjZ F5TsC7pMKevsC0r2BSXTynzTyvz6fwnF+i/jorDY/qBUf7nXcqr+67gC8zDfPa8Eu+wduuwdSvYO JXuHkgknYcJJ2EOU7CFK9d9x/Q0Tf1WwZOpJ2E+U7CdK9hMl+4mSKWixKShhCjrBvqJkElpsEkrY W5TsLUr2FiV7i5K9RcneomRCmm9Cmm9Cmm9Cml+/x73zeA1qfb1ab2q6y9R0l6lpnalpnWlpsWlp vmlpnWlpsWkpYa+ftdfP2utn7fWz9vpZe/2svX7WXj9rr5+118/a62ft9bP2+ll7/ay9ftZeP2uv n7XXz5q6MqaujKkrY+rKmLoypq6MqStj6sqYujKmroypK2Pqypi6MqaujKkrY+rKmLoypq7M1HOs 6QP4SEhP/Si+4t5fdX4xLsGl3pvl+DXMxhxcEQomtIwJLWNCy0xd4TurvP9j164PT059wOsHUQ7Z aVE0/b9TdybwURTp36/u6unqTHoChBAg3LfHuh7r6sqquK7HroLHKoqAiILr6oLrKqByeouKXCqg eCGoq7iIt4DigYonyA3BcEMChAn3lTD1fqsyiYkJhuuv+/Z8ft3V1XU8Vf3Ur56numcGC25+Cm1L qanfSqklotHL9Oro5eAK0EFfhGV3UbQz4Tt0fvRO0A+UWHp3E74fPChCLL4Qiy/E4gux+EIsvhCL L8TiC7H4Qiy+EIsvxOILsfhCLL4Qiy/E4gux+EIsvhCLL8TiC7H4Qiy+EIsvxOILsfhCLL4Qiy/E 4gux+EIsvvBXtPjCchZfLTFUn+50Ee2cruIy51pxh3OdONfpJk53uosr3b+IDu6N4grZXp8tO+g/ yan6JTldt5Or9FfYhhkShpPr9AiZp2fK9aKe3IC/tVHvFI3E0MQMMVHPFZ/puZR+ZvLXYE+h9GMp /VhKP8u5Ue9kbl1LLXhzeGXtdWtqOYNaessP9DT5IZieyJcf63eY4xbJT/XncoYeSu33UfNuuVbn Untrah9G7ZLan6X2GSKQs/QE+T0y4cnLubqbnKenyPnkWqiXMivmYKdO1F8g2xekvIq5cxapR5O6 n5ybSJB6HKn/yjz6DjluJ8dT9rcdj0faAczmDZi9/+q2Yya/Ud/o3iyk+yp28gx9nTtTj3GXid+7 O5iRM0Q1ebx+UX4gQmbp42nBG9Q0E39Uyrn4mgv028zSEUpP0KL5zNT9kjO1TPqkkpblyvW0agPx G/Um50rh6SkiAnygQABSQBSkghDEQBqopqeJ6qC1Xir+CO7Vk8V94H7wAHgQDAYPgYfBI2AIGEof TtFzxFQ9x3H1UkcCD0SADxQIQAqIglQQA9VBDZAOaoIMUAtkgtqgDqgLGoJGoDFoApqCZqA5aAFa glbgEp3jXAr+Bi4Dl4MBYCAYBO4Cd4N7wL3gPnA/eAA8CAaD4XqJMwKMBI+Bx8ETYBQYrZe4J+jJ 7smgDbhUv+8+pLPdh3U2Wt6eu5KPnhWhY5O5E/no2MXoWJHcmciTuxgRu7WSexK75N7EUlmofVmU yJX7dBuZIF7rul4kkef5+mxPaeUFiV1eSmKpF9W+l5rI9ULdxosRn0a6XnqK1xv0AbeDO8CdoC/o B/qDAWAgGARe0Eu98WACeBG8BF4G/wGvgFfBRPAa+C+YBF4Hk8Eb4E3wFngbvAPe1zneFDAVTAMf gA/BdPAR+Bh8Aj4FM8BnYK6e7M0D88ECsBAsAovBEpANloIfQI6eHCnUU3wJ0F8/oqf56Rxrgmbg GHAi+J1e6p/KcYjO8UeBMZzTTv9FwrTHpz0+7fFpj/86cZPBm+At8B6YQvxUMA18AJDdR3b/a8Lf gG8JfwdmgdlgIVikl/jZXMsFG8EWsBVsA9vBDrBL56g0UA1UBzVAHb1E1QVZoB6oD07WS9Wp4N96 sroV3AXuBiPAc2CcnqMmctylJwetdE5wrF4a/JbjCRwvAhcTvkovCbpxvTu4HjxE/BjinwRPgbFg IijUS1KEzkmpwZHxlcK4SskC9fXSaDedHb0J9AA3g1tAL8B4jzLeo4z3KOM9yniPMt6jj4KhYBgY DpA3OhI8Bh4HT4BRYDQYA54ET4Gx4GnwDHgW0Mbo82AceAGMBxP05NQLdHbqhaAtaAcuAheDS8Cl oJ9+P7U/GAAGgkHgLnA3uAfcC+4D94MHwINgMHgIPAweAUPAo2AoGAaGg5HgMfA4eAKMAqPBGPCk fj88Vk9OS9Hvp0VBqn5feMwVk2H+DXKB+C28XCSeEH31WNEP9AcDwECwR2fjP2fjP2fjP2fjP2fj P8fxn+P4z3H85zj+cxz/OY7/HMd/juM/x/Gf4/jPcfznOP5zHP85jv8cx3+O4z/H8Z/j+M9x/Oc4 /nMc/zmO/xzHf47jP8fxn+P4z3H85zj+cxz/OY7/HMd/juM/x/Gf4/jPcfznOP5zHP85jv8cx3+O m1/hcr5Azpk6H581H581H581H581Hz90DH7oGPzOefid8/A757kTdJ59P7L4raOV7i69ktlsMbPY WDlbNGK+XMEMNgQfbiw+3Fh8uLH4cPn4cPn4cMZ/ysZ/ysZ/ysZniuMzxfGZ4vhMcXymOD5THB9p LH7QWPyUsfgkY/EhxuJDxPER8vEN4vgB+fgB+eoYna2Otb/HmY/tb2z5bOzsbGzrbGzhbGzgbOzf OPZvHPs3jv0bx/6NY//GsX/j2L9x7N849m8c+zeO/RvH/o1j/8axf+PYv3Hs3zj2bxx7NR97NR97 NY6Nmh/0puy7CL9sfjVNx7E349ib+SkZjKcOegw25hhsynnYlPPCATovHAgG6bxYhl4ZqwUyQSPQ GNxN/Hi9UrjMKq8xr2PHyaniNDlNXC0/EifLj0Ud+vc9+SmW1AzRSs4SF9HXF+HXR7AYzsS3T5fz xUn0+3Ish4bYOauIXS2OwV64CHuhpcwT51Hup8m17GOp6RM9kfSP2Tonc+0mrIppIo24rzibbX6X suJv6To3ijaV/54u8pzI6DidWtsyH/4VGYpjTmS23EXs2cyW05gtN9jfKN5o/o2S2PqcnWnXFGuT tgUymP8iWCeOI8VvOZst2tDCDK41pK3mV9866O9kL9Ea+T/1zsBec4n5krNvSM3chE1YwFkOZz1E jLO9nH0pWglPtBER4AMFApACoiAVhCAG0qixvaglO2LjdQE9aNM07MCPsTM/0XO8XqKN1xv0AbeD O8CdoC/oB/qDAWAgGCTa4Mu3wWdvg8/eBh+9DT56G3zyNvjfbfC92+Bvt7H/fxHDut1OTTm0Yp38 iDtp/s3kE/0u1u1G2t6LPpmKXB+SitbS9phId74XzZw54gR6pgv98GfZkVSdRCfZxf7GXCfZQ39i fpVI9tGr5ChxihwtTqWeOHe6BZbMJO80cZLXWpxAb3USDcnRkHpO5m72Eo2paZOp39YUS/6vyUzZ mdxXk74rx2s59kLDvtdLsJHzsY/3WP1ZKAJySeGbf0IhdSYpM0mZQso4KQpEplgNi2JDibXYTbdS k7mnffQ87O587no1GHeOLW8+d3ABuSjTWMSRdF2ED1+ED1+Ej1yEj1yEj1yEj1yE71tEne11nvnG EyUew0hRtrQFeruoXa7OznBWV9CTtvXCEp+ttyBdAe2Io3G1qHsHuT6n3lTq3V1lvanUu8r8Nwul pVNvhBJ3UGI+JW6nxBRK25JsRRHjrD2x5vcCO2PJdwW3cqWXqEvOFCT2ybmTnEXkjCFLwvQaOQsZ FavF+WINWAv2oNl7QSEoAvtgh/Z4Lh30CbIzbHG1uEZ25Xgtx574PrciTx89XvZHL0aJP6APp9Pj 31Nja3tv5upnbG3z9ULGXAZezt6kjpzkUbaXAFq0iqSL81VH0Al0Ea3UaDABrOB8JVgFkFMVELed 405kM7//WIBke2jzHiQ7hnbvQbJjaHcW7TaMEdDeKG3NlYtEdat1H5DjU3KsIUcWOdaQI4scfyB1 dWReZzVvri5E7t3kXGNzzbf/S9CR+jqhyV04XsOxN6y4SjSF8QrgmCjMWBdmrAHffWD/Ucfcv2xS SWIKuA/tCXWwY8P8Gl6mvA2tup35bh1y51Hjeh23+raCfGvIF6X0gJJdrmSLuqK73iKuB38Ht3H3 23M/OyJXF9AbzTSpV6Ml6+jpXGRaj3+5gVI2Mk+eIWpHqustkXywSW/xe4Ce4GbwL9Ab9KHctOR/ Ai2m5GxKzpa30arecP4q7uNqtGgNI8i2Fh7Oo4/W62+tL14b+QqRrxD5CpOtN2vKyyhlGaW4lHIM MlanlF2UkqAU80vzASWsNP9HhHyFyFeIfIXIV4h8hchXiHyF4jjRXbQV14O/g77iHNEP9AcDwEBx DjVWo8bfwFkRevhSOCtCL18KZ71MT79JT3+Ins5ET/+KnraVr+oRtOkbZoiWxdIwbxlp8rAmThOt 0dHW3hl6sfecOMd7HowT50Sqi7aRFRzzOW4Cm8U5/tHgFNBDtPV7gpvBv4CRL0CqnUm9cZN649p7 ZXpwvc61qxGTkPulZKrMZKpM5I6T8iS7ArFez0MzeiRm4Atuwvdbga+3Cd9uhXdUYi261iMRJ7aA mALvKH0mpfZILJM76edCchfBDfv0LC+id+EX7vZS9XZSziLleTbvJ1ydQ8wcYqI2b1zupb5CemWf XoCPmfBShE/eBKkW4EsmSNkGXuqRWEctCbzU7UiWL/dwLKTWIjSzOGcRtSbwTrcjcb4XcIwiRSrx xSUV0YIdaF0P/NpdwqGUAkpJUIqmhDxbty8ccheQO0FuTc68pAxHm35KDEeGVeRuRu6l5N4p9zJi jfRF6PE+NC6BnaD1PmRZRWnNKG0ppe30UvR826pU7nMoquMpb6Dkfcj0XzOLapcSdyNHjkwIl1y7 qTvHixE+SjcxKRKzSZFLfaanskmRS5mml7IpYzO9+5P7xd1P3idyV3F/bFp7X0hbxf2gjYd5H+DT g+x/WOYI9ztt3E9/2yuV9rNI8zJEilcL+eqIqJdFafXIUx+boQHhhlxrxLWmXGvOeQuuteRaK+YD z8ukhnpcbcyxBfck9DI4w4fwalN/FjXUoyZTVkPiGxHfhPjmxLcgnnK4Cya1qbleMoWpyZSVjlwu V9d6mcTUBnVEQ+RLJ+VaymyIfC7yueRa6zXmehPQlPjmpGlBXEvCrcy/klNKDrKaFrpeXWTNEpFk KSZ3DvKbFrpeM64151pxbpf2ZoBa6F4mMteh3CzaUo+7X5+6Gph2cb0R1xtzvSnXmxPXgustud6K 9tEK7k0tys0ktjaooxciQ4LeWeXV5142oM0NSdOINI253gQ0JU0z0jQnTUvStGJmM/cptP1aR2Qg h+mx3ciRgRypyBHavm3KeXPbg7uRIQMZUs1dEdK2PSvZz8XSm96Ttt3FOQqSUrui2qHqBKM2Tv/9 RC8Y7ceL2MHqBrlOEGp/+sHVFqLmkdIRSvsNrT5EPSH3UaLG4eoKpZxmWnRk9IU78bW9j4ekM3Zu iB2s3lhWP0ruTKyHSbvCOPVhtXZyb6IAVjtXFiU2wD7dYbXGsFprL5JYD6N2hY3qw2rtvJREAax2 rpea2AAzdYfVGsNqrb2MxE565Dh65Gh65GivDud19W/okTSkOpFeaUmvtPAaEt+IdI1J0wQ05bwZ 6ZqTrgXpWpKuFVqTgucW4nO1keZ/fWaImli7GVi6zbEq/oCt8DnWXjX730JTnS7ij05XcZ5zrXjE uY5jNzz39vppeQW+yJV6KpbH0/af6o7+mVSf21TmP5AW2diSs8mlZy6e/HTnYz3Zhsy/260iVA0v +TghRGt80mPEn/icIC4Ul4kTxRXiSmKvwpY7XfxDDBEXiKHiVfEvMVVM5+xjPiPE12KhGCkW83lO 5OCdPC9yKfEVp55TT8x1GjrHiXlOW6edWO1c7Fwu1jodnc5io3ONc42IO9c63UWB08O5WWxzejtj xE7nKT5ZztN86jnP8qnvvOK86jRwPnZmO43cE9yTnOPdk91TnZPc1m5r5xT3TLeNc6r7Z/cc5zT3 PPc854/uX9wLndPddm475yz3Uvcy50/uFW4H5xy3k9vJOd+9xr3G+Yvb3b3e+at7g3uDc6F7o3uz 09a91e3j/M29w33QudJ9yH3UucEd5o5yerhj3CedXu4E9w2nj/uW+7lznzvTXeiMdhe7q52X3fXu Ructt8Dd7LzrbnV3Oe+7e9xCZ7qrpXA+ka6UzgypZMz5XFaT6c63MkNmON/LTJnlzJFNZFNnoWwu WziLZSt5tJMtfyOPc3Lk8fJ4Z7k8UZ7krJAny1OcVbK1/KOzVp4hz3Ry5VnyLGe9PFue7WyQ58hz nI2ynbzYyZeXyw5OgewouznbZQ/Z00nIW+XtrpD9ZX/XlwPlQFfJUXK0G8hJcpIblW/Lt91U+Z58 zw3lFDnDjclZcpFbR66SG92mcqfU7m+8iJfmnuJleEe5Z3lneGe47b1e3oPuFd7D3jvuTd773nR3 lPedN9t9xpvrrXWf9/I87b4diUai7reRMBK630WqR9LdWZF5kSXunMgPkRXu4sjqyGo3J7Iuss5d FsmLrHeXRzZGNrsrI1sjW93cyI7ILjcvsieyx90YKYwUuvmRfX7E3eQrP83d6Vf3q7sJP92v5Wq/ jt9QSr+J/zsZ9X/v/1428E/1z5cN/Yv99vJ4/2r/HnmKf5//gOzsP+Q/Iq/xh/nD5HX+CH+k7OY/ 4T8hr/dH+0/Lv/vP+8/LHv54f7zs6b/ovyhv9if6b8l/+e/6H8g7/I/8T+Ug/wt/przX/8pfIO/3 F/mL5Ug/28+Wj/vL/OXyCT/X3yBH+1v8IjlWCeXKl5VSjeWrqqU6WX6mTlNnyHnqLHWWXKz+rM6X S9QF6iK5TF2qLpWr1eXqcrlGXaGukGtVR3WNXKe6qe4yX92obpRx9U91hyxQfdVAuU/dpe72XPWA etDz1MPqEc9Xw9QYL1BPqae8dPW0etqrqZ5Vz3kZaoKa4GWqiWqaV1vNUF95R6k5aqF3vFqqtnq/ V9vVXq+dKlLauzxoGbT0OgRHBcd4VwW/DY73OgcnByd7XYLTgtbeNcHpwRnetcFZwVlet+AvwQVe 96Bt0Na7IbgouNj7R3BZ0N67KbgquMrrGXQLbvBuDv4V/Nu7Legb9PX6BAOCAd7twV3BPd4dwYPB Q16/4JFgiDcwGBYM8+4KRgYjvbuDUcFY757g5eA/3uBgYjDReziYFEzyHgm2Btu8IcGOYIc3NNgd 7PaGpUB83vAUL8XzRqaolKj3WEqYUtsbnVI3pa43PqVeSkNvQkrjlMbef6KXRTt6r0S7Rrt6b0S7 R7t7b0b/Eb3Reyv6z+g/vXeiPaM3e+9Gb4ne4r0f7RPt402J9o329aZG+0cHedOiD0Zf8z6Kfhz9 0lsbXRD9wYtHl0XXejuje1KzvERqs9ThkcapI1PHRYamvps6PfJs6uzUrZGXQxXWiXwTHhueG8kJ O4T/iOwO/xne4qeEt4a9/Gphn/AOPz3sG/b1a4X9w/v9zHBwONRvHA4Ph/utwpHh4/5R4ajwef/Y 8IXwBf+UcEL4mn9q+Hr4tn9W+F44zT8v/DD80L8w/Cj8yG8bfhJ+6bcLvw3n+u3D+eF8v3O4MFzs Xx1mh8v9ruHKcLP/93BbuNvvE+4Ni/z+YSIm/EExN+b698S8mO/fGwtiMf+BWPVYpj8kVidWx38s lhWr7z8eaxhr7o+OtYy19J+NDYoN8p+L3R27338+Njj2qP9ibETsMX9i7InYKH9S7MnYk/7k2NjY WP+N2DOxcf6bsfGxl/330ty0NP+DtPS02v5XafXSGviz03al7fXnCjeK/S5EeHaNS8RRorE4Qpue qlfrdeIEnUd4aaUpEnqsfp1PgX6Ys0t0J/J8TigveT1Pb2C/Mnm2s0J+c3WD3s7nx2uqknq2gcer lLcf+LBczDJqyDS17HfD8yLdEl1IOGQm7yxinK8uL2NJayqp81u9Qsf1d5SwitbmViXjAWwBpY5K lr5G5+vP9drk2dYKtW8EOXq5nqd36wtECn13jGhS5nqiqsr0Du7ddkr4UXL6H4ul+OqL+kURgtJ7 +JPcm8BanU0ZyziNYGe1FGcSamSvfqZn6YXoD7qD3155/a/qF/SzHAeDNvq3urfuRahMP5a0nlB+ hdwJ/YXORYO+0N8gB/fB9F75XKVpv62iKwR+qhBpNjQ0GROn7O9KdLOsViRjttPyrfT9Ur0Ne78a USdzF0pr1xvtHdpYkrpC/ny9njEWL+lxszJqjz+UTVOV3Ml02eXO/l3u7MsDK4PtRJs+qWl6Efcv 0IuqqHlXmbF9ovhDFalf0/8xI1p/ccAylc+/zmiH0dkKVxYcQG5aph+woXd/Op71dQeQHx3Rb1ve Wmbu28Fu+hXLpq/QrxW34IBKKNBTLWseoF5UUsLWA9eqSnInGVbPPaTck+1+kWGOI7797gDqX1c8 l+lC9GjbQdcQ/uzVVuBvtpaSGW9l8Sd5vVEleY7m04jP0eWkfCl5nF38+Zn8J1aaP9m7aMkO2GnH /gSGPzfpLTDYCjumjFbvtvGP2csN9cd6up5vZvT95C8qE35E1IX/rxQXmxGSjMthbphWkYtL8xSW CQ9n5qkm/iq6Ep6UjFtN783Z/6xaUr/V6CfJnwL73JpkchP/pn5dSP3efvP/VAsjWE83EP9o8vqX eib9/3XyrCJ/7y0TfpjcdUU7YSyhNsm4D/UUSvjvfutfU3l8gjtm+FFfqi/S3fXFydTPVch/Dyz2 ov6v/l7PLxPtiqvFvWIIoaFimPnOjHgNzZ0k3sM6nCami5PsqsIpYoZYKE4VS8RacaHIdRzRwenq dBW34dH/TfQyvrzoY7x4cbt7k9tT3Ik/vlgMcJe6q8VAN8/NEw+6G9yNYrDxzcXD7k53lxjiFrqF YqjxzcUw45uLEfjmqeIx2Ug2EmNkZ3m1eFJ2ldeKsd673rvCeLVaPBtJj6SLb/13/HfEd/6H/nQx y1/q/yC+97WvxVzj04l5xqcTi9Ul6lKRY3w6sRyf7kqxwvh0YpXx6USe8enEBuPTiY3GpxN7jE8n Evh0jzgCb26E46vH1Bgnxfh0TjXj0znVjU/n1FDj1QSnpvHpnFrGp3Na4tNtdY7Dm9POxYEMIk6n IAiiTpcgDNKca4MaQU2ne1ArqO3cEGQF9Z2bgoZBY6dn0Cxo4dwSnBm0cW7Da7ve6Y13Nti5A+/s Eaev8b+cfsYncvobn8gZkNovdbhzt/F0nNFh9bCOMy18LXzN+SxcHW52Pje+hjPP+BrOEuNrOD8Y X8NZbnwNZ4XxNZzVxtdw1htfw9lsfA1ni/E1nO3G13AKjR/hFBk/wtln/AjXTUtJS3VVWq202m40 bXfaXtc8U1hkNcaxGuOiMaPwKEaLp9DpsWICMS/yUeIl8Sqz1ET0ybf65KNPHzDqPkSrolaromjV V8R/LeaLVLGAj4uWLcSqXiJ+wLrKEasYY6vRuSYiV2xhxG/l01RsE7tEM7GbT3OxR+wTLUQCjaxh NbKB1UhpNTK0GhmikT1EdbcnehlavUxHL3NEprvMXSZqusvdlaK2u8pdJeq4q9HX+lZf61l9rWP1 tZbV1yyrrzVd7WpRU2L+iwy01mXPJmqhu4owN1/UlSnocYbV43rocWfRUl6NNrdCm7sSvhadbmV1 ugE6nSMcb5m3VrjeOi9X+F6eFxepXoG3XTT0dng7RTVvl1ckGnn70P4WVvubWO1vYLW/gdX+Blb7 G6D9fxYZ6hx1jkhV56pzhafOYzxEGA8XEHOhupCYtqqtUKqdaicCdRHjpBnj5BLyXspoSbGjJdWs gIiYupIxk8aY6SSaqM7qalFNdVFdRAt1DaOohh1FNewochhF/yRXD3ULaf6tbiXmNnWbcFUv1Zta +qg+lHw7Iy2VkdaPXP1Vf+IHqAGkH8jYi9mx55j1FNIMVg9R78PqEa4OU8OIGa6Gk2uEGkGax9Qo Ykar0UgyRo0hhvEpomZ8Us6z6llyPaeeI368Gk85E9QEUk5UE4l5TU0i7+vqdfphsnqbnnlHTUHO qWoqfTJNTUOqGepzpP1CfUWZcxSaqRYodFItUtmUtlQtF43VCrWaPlmj8qhrvdogmqqNKp+e3KTi orkqUAXUuFltRebtajspd6gdXN2pdhK/S+1Ckt1qD+XvVXspuVAVUnKRKhI11T61j9oTKkFerbT5 f9UgIhoYNmEPm7CHTdjDJuxhE/awCXvYhD1swh42EQ5s8iD7wcFg4RpOEZ7hFOEYThEhnNKf/YDo IFHdMIuQMMtCEaYuSl0sYqlLUreK6oZlhDQsI+rCMqtFzXBNuEZkhGvDtSIWrgvXicwwN8zlal6Y J+qE68P1on64IdxEOB7GSV8QFpBmc7iZNNvCbYS3hztEVrgz3EmaXeFu0uwN93K1MCwSqWEi1KJO zLjWNQ1/sfdiHvtIzBfpsFggasdSYlFRK5YaSyVlGIuJ+vBaTWIyYpkiy7CbyITdstjXi9UnTcNY I5ERaxxrTDlNYk0JN4s1I33zWHPCcB/xcB8xz8SepZbnYs+Ta1xsHCWPj02gzBdjL4tahg2FNGwo qhs2FNVhrDeSbDicj7RsGIENxxAeCw9Ky4M+LPga4UniffZTBNoGG35M+FM4UIrP4UEJDy6AMRfC r9Ku3weWB6XlwVqWBzMtD0YtD9a2PFjH8mBdy4NZlgdDp5pTTcScjk5H9j2cnuz/5dzKvpfTi/3D zsMiBkteKlzLkimwZHf2hiVTLUumWJZMs5yY4ea7+aKG5cF0y4M13X3uPlHNMmB16UlPpMN9AeGo jIoasqPsKOrLTvZNNsN9DSz3NZJdZBfir7FvtxkebGB5sJG8TnYT9Up5MFdIGHC7COC+IhG1rJdl WS/TrNoyPv+k/sToPVudLaTluECdD8d5cNyFhA27SctuvmW3OupidTExht2kukxdxv5y1Z6UhuM8 y26Zlt2ilt2yYLeuIlTXqevYd1PdSH+9up79DeoG9obpAst00STT9VK9iOkN0/mW4wJ1p7qTvH1V X9KXMN0gwsUcd4+6l7BhusAynbRMF1VD1BByPaqGEmNYL7CsFyZZb6QaSbzhvsByX5ZlPWlZz1PP wHoyyXrPq+cJj1PjYLQX1AukNzwoLQ9mleFBaXkwgAenEi7mvg/UJ4RnqO/ZG+4L4L5swob1alnW y7SsF7WsV9uyXh3LenUt62VZ1gvVNrWNXIb7Mi331bHcl5XkviI4TlqOCwMncIQsZqvoHdE7RUq0 X7Qf+wHRASI1OghuSo3eHb2bmPuj94sUy1Nu6sjUJ4VrGScj3ATXVA+3hFtFuuWX6pZZMmCWXYR3 h3tENTglwTg3nFIjJmNSVINNlEizPJJueSQDBkknbBikZqx2rDZpDHdkxBrEGhDfKMkdTSjBcEe6 5Y7qljtqWO5IhzueocznYs+Ra3xsPOknwBrpljVc4Z602ay8nrruz6eIC0SH/dn5/39sOk+vN0ie rajM7zLrPHat72DLXmNWuKzn/bE9X1pSp91/n/Q+843/aX3RbL1K55Zf0am63pIVOn3LwUt4ZDd9 IZ6nOe7X966QIw9Pe+ahr8uUlpP/0zO9xe6T8fiK2+nZVToOSlf2yniiGWVyZ5NqsTDrHrUJJVcY S7zrX2iLlkpTtt5QXGXjNla2uqA3VFyb01v1Sr2EKxWeQhzqVrJKXv7MjJ+kVpdZL0B2WRrO399d 1ssrrmoeqa3yJzhV5pqgx9ljkV0N/9LArA/pVwh9lUxTollmBO/Qs0viD6qeNVZHV/14blbBdE6Z FI/a9SCzVr7chtYgTVmGSvbvgd5fu2q9qup0B7+haWXK1Tt1Edhr1rr0vnLpfu651P/Y9guP+QPY 9NOHkfmSSspbJY5CBxseRqk/vx0lLLcaPrWcWukGNxzwM8TDnyt+Ul45qcqOvQPM/6aericnnw9k 6Of0dBu72szuZWfvQ7IfFsONK6z9kGttE8tmZk7SKzhOTKaK2+dtX4PP+eSWX7m2TFZXlKzNfsZc 8JWeA54m9gI9T39j4+cXWxH2ifZVBy9pBcnXlzuzc6h+o0zMTXq87qkfMqv8+tbS2D8S974ZdxWf OgrzzLXis9AN+mPakn3kRmqJPph5DAYrsQu/Esnns2VlgJdLn42YZyxVlPzdkZLxUDd6KWaPI8zz 5gpXe+nPyqUtPuYwu602GnII9S0wWm/tLdtPJsT8tiLZa+z1jXqWvd+7hKxkDouJEyqUGWccbEo+ XZIwR8lTp13FVw9/fvvxOXT555UlVoqxvey8vYZPvILtudzanpWMdkbzEeauyraf8Nm8CteLfhqT jP935fHiYJ6jH/Sm/36QGYrfsRis77fHAssAbxkQ+o9+tzhkr5XYZ/Z5J3dqyiFI96Z+H8Z8J3n2 mX5VmPeD3jNhAHPCYp/BEiVWcAHs+02SJ4qfn6VVKHOmfkd/lCwzw5wl48uxg9YHL63NxyjVS0rP SnyXlSZU4lcWW+KW0b4y+lH8jkhy/Gy1jHy1vsSefSTM07xbwO2EhusxzHW3J0sp824LPTBN9z0E aa/VA/QLuiehTxnVL+gbLD88ymz0Av38kX5a/4O5tcA8A7Qtm6on6eeLa07OGln605+UmasX4lUW j9zfl4aSdqfeU4wDt5jLlb3djvfSt4LKz1J2ni71fK3lu8K+91D2jYvfln9j5Zfayj/FtW8wbapa EtuiCu9f/RJbeU/W9Co6vK0q/rR354h5ugezlbU/GA3Gy1rEcT9PuktTbjh8efUzur++T4+24dno +zjzpkxyHiq2F3fot8H0w6vHlnRC8Zssh1XGar2OmdDOj9zTdehhqc1dfNf1ZmyOzZVZgAdd1yHY 3GVyf1N8V5HF8OB3ybPlyfGTlPrXGc+Vbfrv+nr9gX5XuPZsgO4DW3cttgj0e3o3Z0P0v/Vpuhk8 erK+Xd94GHUV24+ND0veJCcV+7Sl7xuOK3/1SG56whEow2jvwmJWx76tcPft9VV67o+z8K+7Ic1S xpxd80SHjadY6qkUW7pcnQn2867qL70h79CyIxf7auqvKc/+N0ZbL2M7Fb/pqm/DOprP6Cu+9pHd L9VTdCf9EKFh+ofiuEOsa+bhy3uQNW4v+57X/+5WauNuPfy3Kyt71/1IbsXWIfb3Wma9I7BiUdU7 yj+b9wA1Sr9u1/Y3HnpNZba6R6SUA9qwhQ7bctUjjoQkVdSRZDqs28Nelz9Cd6mqWlZj2f4fj5Qj t2H1bD9iPZN+GHIcifH+Cz6POBRtxO5ZVZwz+c2OknWRWfY5w6yfzXxzMu3kg6/3l94O5TsQFcrY 79OQn8ljV+vNSlGxJ1y8olP6LDj6c/6xXdutK3oK/+DrtfkP4VteOtfOHT9+l6xkTe5AfbtUcf7B 1/qrbpmHmvHgnzwJ81aDeS5d6tnraXa/CX6u8mnE/9qG3b9j/9+ZKJNu9/+9LAe2HRhDHuqsXul3 paqsy75B8ON3B+0Ti1LNilaaqSStWauqLzox5n6FrbztXswaeE9V8Kx9EvMrrPfpLUewrJUiuaJc 6TeOjrbfcjJP0GdXcrWqss33qFaW5CwJ2RX+lcmYkjr/aOv6iVxlzh78scwSWcz3tSpIZb6VdaJ5 SnMoXrt+Wr+kp5Z+DywZMhZBck1zdqkcJ1aQ96WDr69c/kN4U0jPtU8lvi49t+8AYW/6B/yk7wC+ vbefuiv9bnIVedbZVSszk1susGefMfaKmSH6c/alnVGqiTMP7PualeQ/lPcf5pnvW1rsLD63++Sq +c+zQ7It9cu/b4R+bdFzLJ4WtbFJ1yefJq0oHtNW1246eEmraEfxE7Yy3rruqm/XL+tn7e8GlL7T oy/Ubx5kyZ/9MhazkXH/9ehEZU+Vi58o/iRuS9VPcQ51s+/IJJlZb8We2Ip9tFhn/8hEOp8488z4 D/oKe/7/iPsasKiuc+t9zsw5cwYOPyIxgEgMQUQkBBGRIBgkhBhjDTXGeK1xBhgmBoZhmB8qM8OZ n8horDXWGGOsNdZYa4g11lhjjNdaa6w1XkuNMdYaY6w11lo/a60xxsq39jsjMb33623v83zPlWev eXnPPvv8zMz7rgXM8k28Ao72PdX3Lv++76d9y/r28Z+Y07YXvrL2R7fy/9IZPdbX2hfqmxT7jiK8 Ap+meH3fq31OvA5Wga3tQOflM7b1/aRva6xr85/OD2JF9DvnuX02ykX/HnE1ePX3+PPBXRL6/wro Kz8L6vv81qf5/6XzfbnvNWi1lbHvDtGxV1GdP0T3gP/2dXPflb6f0YTop/Zjf2EQexWP+deP+r/1 7//Lp7H/81E+uVWxor93/t/69z/5PRWe6T+x237q0O+Q8M/0noGM//3O4xRnshJoz6G07+/BOn5P 3WQwG933Ad6h/OujvpN99+P98jRT+6J9PaZT8e6Maqo7Y99vif2mQmT9n5im/MZ/cB30txV9XvS5 2E8g+yb0mTAe7bOygX3RHnzLQ6ML46G+cX1P9MU+2dC3v+8E/bUEf8eeR0/6JKZfR7I86pwjadY/ /unGf31e3+97Ffha//c7uJb7yl9WTIsF32BTWRkrJp+YYbTl9muPu3m4L/7mZ9Qpd/a19L3Je1if 1vcsj7Dqwq8cNvo3YC3/g/O19bXh+tvoGwWRjerms9Spf43n8tOb0U/Sv0WuILf+0Z3tc8XW+Cc0 3n957D/893P+0z4X6C8COE+gVxO9mvfiez1tVv8h3+F7JbEKnL3I3v9vfOxmxnzswuwRQRTuYBZy p5tL7nQLyJ1uoTBTeIotEZ4RnmHLyJfuRcEjLGQrhEXCS2wTd6djO7g7HXuHu9Oxndydjv278DPh V+ynYpE4ih0SS8RS1svd6dj74gPiA+wId6djH4iPiI+yD0Wn6GLHxbliJzshLhFfYCfFdeI6dlr8 obiJ/U7cJr7F/ii+Lb7N/iTuFHexi+Je8V32Z/GX4i/ZX8T/EA+xK2Kv+Gt2VXxffJ9dE4+KR9nn OlWXwK7rknUp7AZ3mGN95DDHyGFO0uXocgQDOcwp5CoXryvVlQoJ5CqXSK5yyeQql0J+cgN1M3Xf EFJ1s3UmYRD/rJyQxl3fhAzu+iYU6t/S7xJmctc3oYE7vQlN3OlNsErJ0gDhaSlVShee4X5vQpt0 QvpE6OB+b4Kf+70JXdzvTdC435sQ5H5vQkT6q/SFMJ97vAmLuceb8BL3eBNe4R5vwhru8Sas4x5v wuvc403YxT3ehJ9yjzehV35Kjggfcnc3UeDubqKeu7uJEnd3Ew3c3U1U5DXyq2Ii93UTU7ivmziQ +7qJmdzXTbyH+7qJw+VfysfEEdzRTbyfO7qJ5fKn8h/FCu7oJk7gjm7i17ijm1jHHd3EZu7oJnby z8eJmiIqohhQZMUgBpV4JV4MK0lKsviskqqkit1KmpIuRpQhyhBxgXK3ki0+xx3XxG9xxzVxEXdc E59XRimjxO9w3zVxKfddE1/gvmvii0qVMkF8ifuuiS9z3zVxFfddE7/HfdfEV7jvmrhWsSpPi69y 3zXxB4pbcYsbuPua+Bp3XxN7uPua+LrynPKcuElZpCwS31CeV5aIm7n7mriFu6+Jb3L3NfFt7r4m vqO8qewSdyq7lffF/cpR5UPxhPIb5bfiSeUj5VPxE+UPyl/EC9yVTfyMu7KJ15Q+oyB+zl3ZxBvc lU38G3dl0wnGdGOWLoH7sekGGrONebpU40hjoW6wsdhYrLvLOMY4RjfUONY4Tne3sdJYrcs11hhr dAXGWuNE3b3GScZHdUXGrxkf0xUbnzTO0I0x2o1O3di4oXE5ugru7qabwN3ddI9wtzbdJO7WpnNw tzZdJ3dr04W4W5vuufhp8Y261/mn9nTvcLc23c9Vg5qkO8h92nQfqN9Q5+gucZ823U3u06bXc582 vYH7tOnjuE+bPp77tOnv4D5t+kzu06Yfwn3a9EO5T5t+pLpOfV1fwH3a9CXcp01fzn3a9A9wnzZ9 Ffdp00/gPm36R7hPm76O+7Tpv8592vTT1E/U0/qZ3GVNP4u7rOmf4i5r+gbusqafw13W9C3cZU3f migmKnp7opqYqPckpiSm6udyZzW9L/GzxM/0WhJLEvQBJgqnUfUSofiSWDIT2AB86VgK+rCepaF3 S+jqw5DPxZeBDUcXVFgBqqQR9XAcU1EP+f/zMJ7+BwxeMROpYiahYk7HXk/iawDq5lNYcTZrZFXM gho6ATXUCebgwlc1c7O57A7Wia9BzMs0HDmACpuGCquydCFBSGQZ9AnhwUIyau69qLnDkckT8liR MELIR36kMBJxAWpxOtXiUajFjwHrUJEfIr/QdOEp1OViqsvFVJdHoy77ke8S5rMSYYGwAGs+h0o9 GJX6eVYqLBFeZGOF5ajao6hqj6KqPYqqdhGq9muIe1C7i1C730U/2CfsY+OEXwjvsQrhIKp5JVVz EdW8BDgGNV2mmp5MNV2kmp5MNT2VavqDVNPvo5peRjU9EzX9NXaX2CP2sCHi6+KP2N3iJlT5bKry 2VTlh6LK7wT+O2p9FtX6HKr1Q1Dr/wN4CBV/KCp+L/DXqPtZVPezqO7fg7qvsmG6BFT/XKr+eVT9 h6P6p7F8XbounY3UZegyWA3vBIjRCdgIdILhwDzdCOyFfsAKeD/AXuW6cuA43ThsrdRVAsfrxmMO egMQvQEZ/lnrh+mz1hPp89UP0+erJ9JnqmvRJwJsvD6on88EdIslLEn/Hf1ydr/+Jf0KNlD/sn41 K9e/ov8+u1O/Vv8jlq7fpP8Jy0BHeYsVczdRVsL7CqvgfYWpvK8Ak6VkNkEaIA1go3h3YcXoLkeY TvpA+oANlY5KR1mS9KH0IdNLx6TfMAld5wQyH0kfIXNSOskM0sfSx0yRTkmn2B3SJ9InLJ73JJbA exJmnpPOsQHSH6Q/sBR0pj8yQbog/QlHvCj9HzZQuiRdYnfyXoUj/lX6K0uTrkpXWaX0mfQZzu2a dA3n87n0OeLr0nXEX0hfsPHS36S/YeWbssgGyjpZz8bLkiwxAR3OwNAsZIUlyEY5jiXJ8XI808mq rLI0OUFOYJVyopyIOeiC/H91lwdi31T5DuybJqdjfoY8mKXImfIQrJwlZzHugHo3MFvOxgr3yPdg fo6cg/nD5DzMHyGPYHfK+XI+8iPlkUwvF8gFLFG+Vy7E+vfJ92HfIrkIq42SR2FOsVyMfUfLo5nK Oy6ONVYei3yZXI6Z4+RxWKFCrmKSPEF+CDNr5VpmkB+WH8Y5PyZ/Hdc1VX4C6z8lm3H0erkBR2mU rVjnabmFVck2uY1NkB2yG0f0yB2sWv6mjOohd8peNkj2yT6crV/WcC0BOYh1QnIIK4TlMFZ4Vn6W xcvz5Hk4SrfcjTkROYKjgAGwwZwBsCIwgO+wEnmpvJSN5jyApYMHvIStK+QVLEN+WUYdkL8rf5dV yKvkVbjba+Q1wO/La1kx94DFfHAFrPC6/Dpwo4xXqbxJ3oR935A3s4fkH8s/xspb5DexdZu8Dfu+ Jb+F/HZ5B2a+I+/EzJ/Ku7H1Z/IeVgqGsQ/5X8i/YIXgGb/E/APyAWTek9/DzIPyrzCzV+7F+fxa Pow578vv4wyPyB/gnI/KR9m98ofyh2ysfEw+hn3BUbDXSfkkVv5Y/hh7fSp/itXOyecx/4/yHzH/ z/JfMeeqfBV34zP5M5zbNfkGS+c8ho0Gj0lAnGgYwEoMKYaBbLAh1XAnKzWkGTLZWMMQw1A2Cixn OKsw5BlGsEcM+YaRbJyhwFCAzL2G+1ilochQhBVGGUZhZrGhGHNGG0Zja4kB2hHc6H42xlBuKMex xhnGYX6FoQJbKw2VOBb3FBA4Z2LFnDMBwZmA4ExAcCYgOBMQnAkIzgQEZ2IZnDOxwZwzAcGZ2L2c MyEGZ2IVnDOxdO5VywqVCcoE7AXmhAyYE+aAOQHBnFgpZ05sLJgTlIDytPI0qwR/amNJikNpxxyw KOwLFoU8WBRmBpUg1gkpIcRhJYw8GBXOB4wK859XnmclyhJlCfYCr2KjwauWI/OSgledskL5LuIf Kj/EsTYoG9gjnGkhA6bF4jjTAoJpAcG0gGBawD8of2YPKJeVyzjKX5S/YB2wLlbEWRfiPqWP/99b RsYeMgpGgaVzBsYGg4EZgIpRYWOM+MeKjHHGOMSqMRGYZET/NSYbk1mpcYAxBZmBxoGswphqTGWj jXcY72CVxkHGO5FPN6azEmOGMYPdaxxsHIw405iJowwxDsHWLGMWMuB2iMHtcCbgdkBwOyC4HRDc DghuBwS3A4LbAcHtgOB2QHA7ILgdi+Pcjj0Abvc4S46bFjeNyXFPxD2BeHrcdMRPxj2JeEbcTJbK mR8y8+PWMTHuB3EbEYP/IQb/wxzwP8z5PF5gYrwYn8Ee5CyQlUW9GzgLZCJngUCwQOA31G+wIeos dRYbqj6lPsUGqLPV2ewu1aSa2D2qWTWzbLVerWc6tUFtQmxVrZj/tPo05sxR52BOi9qC2Ka2shzV rtoxp011YI5TdWKrS3WzLDDLbyI/V52LPPgl0K/6gV2qxjLVgBpkd6shNYyZz6rPYuY8tRtHXKB+ C5lF6mKsDA6KoyxVlwJfUJdhznL1JZzzCnUF1nlZXYn4u+p3MX+Vugrx99TvYc3V6mpsfUV9hQ1X 16hr2AjOXFkemOs6NlL9gfoDVqOuV19D3KP2YM7r6uvY+ob6BnCz+mNWoG5Rt2Drm+pWbH1L3c7y 1bfVHci8o76DDPguEHwX+DN1Dxum/lzdiznvqvtYrvoL9ReYuV/dj6McVH+FTK96GGuCDWP9o+pR 4IfqMcw5rv4WW0+oJ7DOR+pJxB+rH7MSsORPsNpp9TQbzrkyywJXDrPMhGcT5rHshO4E3CXw5gWs IOG5BNyrhEUJi9hdCd9O+DYy30lYykYmvJDwAqvhfBoZ8GlWwPk0S+V8momcTwPBp4Hg0yyV82lW DGZXRXy6lvi0SEw6yptvMWbOjxOJHyeyf8NXIjHjicSMJxEzTiFmPJmY8SBixncSM04jZpx+m3+P RP49Cvn3SOTfI5F/Txz590jk3yORf08C+fdI5N8jkX+PRP49SeTfI5F/TxL590jk3/MI+fc8Sv49 A8m/52vk3zOF/HseI/+eOvLvyQBTjwdvThASiKOnszFChpABDs2ZehmY+mOsnLj448ITwr8hz7n4 OMEqWMGwPYIH2CF4wZv9YORjwcgXsEpw8ecQf0v4FuZzRj4WjPwlVgUuvopNAAvfCvyJ8BNWLWwT foqtnIU/SSz8QWLhNcTCHwILL2I6YuG62/i3Dvz7QeLfj4B/P0osnDsM6clhaAA5DA0gh6E7yGFo AHH0rxNHv198TlzIxnNnfzYtxtQ5Lx8pviG+wUaI28HL7yFGPowY+XDxPfE98G/Oxe8WD4uHkf8A /Ptuci0aIv5G/AiM/GPxYyB3MCogV7d88Yz4e2Q+FT8Fcm+3LHI2yhH/JF5EzP2NcsU/i5cRc5ej PPEL8QZi7nV0l3hT7GNZ5HiUrRN0ImLue5Srk3QSYu5+lE3uRzm6eF08Mklg/4XE+4uJ95cQ75+q G6zLRJ6z/0LdPWD/9+lywf4Lif0X6fJ1+YgLdAXAUbrRbDSUwFjEZboydq/ufuiBQtIDo3QV0AOF ugd0D2B9rgcKSQk8QUpgOimBJ0gJTCcNUAv2v5wlgvevZinE+NOI8Q8mxl+m3wbGPw6Mfy+r1L+r P8iqiffX3ObJJJEnUxJ5Mg0kT6Y6UgKTSAlMIH+mR0kPlEMPvM9k0gAG6TfQADJpAANpgERi/wZi /2nSGekMWP5Z6VNkOO+XifHfSYx/EjH+FGL8acT406Ur0hUg5/S1xOkNxOlTiNPXEqcXZRmc3kBs 3kBsPp1Yey3xdQMx9RRi6unEzmuJlxuIl6cRL68FF4fulQvByGXi4inExWtjLLxELsH8UrkU8zkX ryUWHuXcBuLZBuLWE4lbTyJunULcejJx60HEre8kbp1G3Dqd2HO6vEheBE75bfnbYJOcPZcTY66Q l8vLkeeMeQwx5gnyank1eCTnyqXyWnDlCuLKg4krV8rr5R7w+NfBkgcTS36c+HGlvFXeir04Sy4l lvw4WPJ27Ps2uPJg4splxJUr5Z/Le7HCu/K7mM+5cimx5MHEksuIJVcSS66RD4MlVxBLnkAsuZRY ciWx5CpiyQ8RSx4jfyR/hK2cH0eZ8Rj5gnwJGc6Py4gflxM/fly+Kd8EQ+XMuIKYcSWY8Z2IOSeu Ik48wXC3YRirJmZcQ8z4SWLGDxIPnkA8+EniwTXEgwcbxhrGAjkDfogYcI3hAcMDWJM7iiWRl5hE XmJJ5CKWRC5iErmIxZGL2BRyEZPIRUwyTDVMxdG5l5hEXmJJ5CL2KLmIDSQXsTpyEcsgF7EMchGT yEVMIhcxiVzEkshFbOBtLmJJ5CIWRy5iSeQilkEuYhK5iCWRi5h0m4uYRC5iSeQiJpGL2EByEcsg FzGJXMSSyEUs4zYXMYlcxJLIRayOXMQk8g+TbvMPk8g/LIH8w5LIP0wi/7C62/zDJPIPSyL/MIn8 w5LIP0wi/zCJ/MOSyD9MIv+wR8g/7FHyDxtI/mFfI/+wKeQf9hj5h9WRf1gG+YdJ5B/2KPmHTSH/ sLrb/MMk8g/LIP8wCRpmICuHYhnGJpA+qVaGK8OhDfKUPHD9kcpIVqYUKPdCbxQqhcgXKUUx3VKq FCuj2UOkXkqVUqUMyDVMjTJOGYd1uIapVmqVh4ETlUex2mTla5gzRZnCxiiPQclUKnXKVCiEJ5Un sZXrmSrFpJhwPg1KA/aKOjFyhVMDhdOMY3GFk6i0K06s41Jc2MujeNiDyjeVbyLTpQRwFVznlJO2 GUzOjaWkcCqUxcpiINc5D5HOqVBeVFAlSOeUksKpVF5RXkHmVeVVHJ2rnRpSO08qryk92Itrnkrl R8qPMOcNZTPwTSifeOWk8jvg76F54knzPEyap1q5olzBylzzlCtfKF/g6rjmiSfN8zhpngmkeSpI 7ZSS2ikntVNqTIDCqYDCGcCqSOHUkMJ5kBTOQ1A4g6CC7jSmYWY6FE4ZaZvBpGeqoWeG4yj50DPx 0DMlwFJjObASGiaeNEw8NMxjQK5e4km9xJN6eRjqZVpMsXCtMgM6ZCYplllxs5BpjGtk4+Oa45qB tjgb0B5nBzriHEB3nBvIvegGkBfdAPKiu4O86O4gL7oB5EU3gJSPjrTN1+MHx2ez++MnxX+djY+3 xHvZNHKq05Pa0UPhjISK4BpmJGmYEWoTNMzd6jNqM5g61y13k2IZCcXShtihtkM5dKgdyHCtco/q U33IdKkBqBSuT4aRPhlJ+mQE9MlCZL4FlTKCVMpw9Xn1eczn+mSk+qK6HFtfgj4ZDn3yMlbj+mQY 6ZOoMrmHlEmh+n31+8BX1VeBXJmUkDKZqr4GZTIKymQj8j9SN7EiUiajSJmMJmVSAmXyJjJb1Z+w e9Vt6jbMfFt9G3muT+5Td0KfFKq71F3YuhfKpIg0SQlpkqnqAfU9bD2oHkKeK5PR6vvq+5jJNUmJ +hv1OPK/hSYZDU3yEVY7CWWSRcqkSD2lnsJxuT4pJn1yn/o7FRyP3AELyI80Xz2vXkCGOwVmqxfV S4i5X2Au+QVmk19gAfkFZpNf4F3kR5ql/k39G5B7BxaofSoYIDkI5oCYgwGSj+Bd5E2aRW6CQ8ib NIs8BXPJU7CAvEnzExITkpDn/oK5CQMTBiLDXQbzyGXwroS0hAxs5V6DBeQ1mEteg3nkNZiTkJ2Q ja3ccTCXHAezyXEwJ6E5oZndTUpsGJRYiJQYXg8J8xPmQ6EtgPoaRuprNOmuqdBdLyJenrCCFZH6 Gp2wMmElYu5cmEvOhUPIubCAnAvzyLkwl5wL9UwYfDkzCPKr6hayjxkzz8QwY1gxbBhOjLn9j4Kj B48axjyMhRhLMJZjrMJYi7EBYxPGVowdGLsx9mEcxDiMcQzjJBODB2gw8xkaYrAX4yji8xiXMK5i 3GCsXsRQMBIxUjEyMIZGz6E+9//xWBBdq744Nvg+ZRjjaRurr8GYFD1f2mdt9Brr6zCmY8yK5mOP YvAEDcGxGWMb4tP9ueg4h3ExFh/FuBKLr0dHiMWGjKFipGCkYWRF54ZyaD6rb8CYE71P9fb+ex6d m0/zWL0bw4sRxIjErmFR9Hihoti1LsVYgbE6tn1dbHtpbFQgh+exnl/PTow9/dcSveZtGDsx9mDs xziEcQTjOMYpjLOxxwu3Pd6afxnjWuzxeGy/a7dtv8lYgx4jDiMZYxBG5peP/PlryMbI+6cfxVD1 l88Vv7aGwthz/a+OjK8Oen0vjB6HXlcZ0Xl03NtHCUb5l4/9a0TXFUMTka/CqI29/rCtYfKXjw1T MWboB8w+1Tqpq9c8r40RyoQqcGFbCnBJWxpweVsWcFVbDnBtW35XL98rMMu8oa0o0DD7bGtd19HZ F1qnd50wb2orJazoj7e2VXed4FsDc2Zfbp3Vddq8o21i1+loHMNrrQ1d58y726YQTgPuo3gfxQfb ZgIPt5mBx9qswJNttq5zfK+AHTgH8c1We9dF85k2J/B821zgpTat6yLPB9wmfau764r5ats84I22 hQGvKa7V23W9XmxbQriccBVQqa8BJratBaa2bQBmtG0CDm3b2nWd7xUI1ue27dBWmZJbgxrubNtu jZkGtUY0mWMgYspsXaSp9cVt+4BlbQc1lWcCi6L5GGa3LtVSTHmtK7S0+vFth/uxpu2YlsbzgaUx LGxdrWXVT2o7SXgGWEfx9LbzwFltl4ANbVeBc9pu9KPdIQZW1LsdSmC1qaR1nZZT73Ukajm0Wn4s E3Sk3kKeCawzlbf2aEX1EUcG4dBbMc8HekxVrZu10vpFjlytlMeBzaYqRwHi2tZtWkX9UkcxYVl/ vMIxHrjaUQNc55gE7HHUATc7plM8S6vg+wa2mSa37tSqTVNb92gT67c5Gvpxp6MhsLN+j2OONtE0 o3W/NsU0u/UQnYOd0N0f73d4cSaW1iPatPpDjmA/HnFEtGmm5tbj2sxndncGCSOEi4D7OpcCD3au AB7uXA081rkOeLKzR5vJ9+r2PnOmc3N30ORoPaWZTR2tZzXrM+c7twEvde4k5PHVzj2alW/tjpj8 rRc0+Zkbnfs1uVlsvdC9KIqmcOtlzdasdB4iPAJMpDiR4tTO48CMzlPAoZ1ngbmdFzQb36t7KfAa 4gWtNzVnc0HnZWBx5zVgWScyPN+9wrTYrtfmNo/3cqzxxnWvNi2zx2la8yRvMsfmCMWDgHXeTOB0 bzZwljcP2OAtBM7xlmga36t7XbPdW97dY1ppOq3Na3Z7q7R5pjX2ZG0hx1COab19kLak2eutBQa9 k7UlPNO9OZqP4UZ7prbctMWera1qjnin9uMi7wy8d5Dv3hbD7fY8bW3zUu9sQkt/vMLbDFztdQDX eTuAPV4/cLM3DNzmXdC9s3mnd3GgwbTLXqhtaN7jXda9h1bbFMvs964EHuLIM937TXvtJdrW5iPe NYTrb8U8333IdMBeru1oPu7dqO3gcfeR5lPeLd3HTb32Km1381nceaB3e398wbsLeNm7F3jNewB4 09ur7W7Re48C47wntN183+5TpqP2Wm2f6YR9snawJdl7+u9wkPecdtB02j5VO2w6Z5+hHWvJ9F4k vNIfZ3uva8dMF+2ztZMteT7Wj4U+WTtpumK3aGfqjzsWES4FnqL4rGMF8IJjNfCyYx3wmqMHeNOx WTvD9wrsadA7tgX2m67bm7XzZmZ3aJca4hw7gcmEgwgzHXu0S3xr4JBZtndoV82yYz9HHjdkOw4F Es2q3a/daMhzHCE8/ndxoeMUsMRxFljuuACsclzWbvC9AkfMKfZwQDSn2RcElIZaxzXgZMdN4NR2 PXBGe1xAMWfZFwcSG2YTWtqTA8fNOfZlgdSG5vZBhJmE2YFUc057HmJHeyGwo70E6G8v53nMP9UQ bq9CZkF7beCsOd++MpDRsLh9MnBZ+9RAhrnIvkY7zDFwoWFl+4zAZXOpfT3mr2mfjRVK2y0ckTkV zcewwr4xMNRcbd+Cc1vf3gzcSLil3YE7w/PXGra3d6B7UmyeaN8eyG3Y1e4nDPfj3vYFwAPti4G9 7cuAR9tXAk+0rwGebl8fuNlwrn1jUI91dgUKzFntW4DV9r3AKfYDOM+L7duBVzhS5pR5mr03UNxw vX3XV5Hng5Ct7XsDuY1y+4Fgsnmm/WigrFFt7w2U8Tg4yDyzHRmz2X6CriuKp2/FjSnt54Bp7ReB We1XgDnt14H5TgYscsq4dr7vNbPVfjow3myznwvUNJY61b/DCmdKoMbstF8MTDLPtV8J1DVWO5Zy dKb140RnVqDOrNmvB6Y3TnHmAKcRznTmA83OomAm5yTB7EarsxT8BNwgmNdoc1Z0nWt0OquBc50T ox08WMj7YLCkUXNO0bIa5zmnaVm8EwXLGxc6Z/Ku5DQD0WuCVY1LnFattHG504b+gvdLsLZxldOp neGv2+DkxrXOudqNxg1ODbjJOS/6GgtO5c9vcEbjVufCQK55onMJEPchOLtxh3M5vyfOVcDole52 rgXuc24I1FHHOdtS4lPRfXjlv9BS7kvRbC1VvjRgrS8rVp8v8yrXfa1lsi9HW2va7ssH8jpzs2Wq r4jXHF8pEJUkom+Z4atA9Zjtq9aO0Sv/VONB56agpfGwc2uwufGYc0fQ0XjSuTvY0XjGua/rRON5 58Gu042XnIeDfsw5hjlXnSeD4cYbzjPBBRbReT642KI4LwWXWRKdV7sumiY7b2jVllSXGFxpyXAp wTWmGa5EbYplqCs1uN6U58oIbjQVuoZqWZZcV25gv6XAVRDcYil2FQe3R/mGpcxVFtxlGe8a39XL GUVwr6XGVRM8YJnkmsSfBVfdrc5uqXNNJ5wFnI5z67XMcjUEj1oaXHOCJyxzXPbgaYvd5Q6es7hd 3uBFi9cVDF6Jctp60RUBi4vyKGIplqBrEbgr8UZLxLUUuMi1AiyOvzau1ze4gJalrnUhZlnh6gnJ ltWuzSHVso7PNOld27quWHpcO0MpUeZmXuXa09Vr2ezaj/c4cVTLNtehrnP1Ga4jXdctO13HcfQ5 rlO4D3tcZ4H7XRe0HMsh12VwsB7XNZzPEddN4HG3PrjYfNUdh/VPuZNDaZaz7kHBXn4HQlmWC+7M 6Gs7lGO57M7GOtfceVqp5aa7MJTfpHeXhIqiDLMpzl0eKm1KdleFKvj7IlTdNMhdC5YOrh6aGMWm TPfkKAMPTbkNpxHOpKOYCa1N2e6pXeea8twzui42Fbpnd13hjDpkaypxW2Kxk3Auf3+FtNidBB8O zSNcyM8qtKSp3N0cWhKNCZc3VbkdWkpTrbsDfBisOLSqabLbH+XAobW34QYwVbeW0zTVHQbO4MhZ a2hTFJtmuxdEmWpoa5PFvVgramp2LwMij4zDvTLKWoNVX2JoB3/Xh3YT7otiU4d7DbgoGGnoYJPf vR7ME7w0dLgp7N6oTWla4N4CdLi3g3Mecu8Ct+TPy7EoNi127w2dbMh2H8C7m1fmxKZl7l50z2z3 UcQr3SdCZ8xZ7tO8I7jPhc43rXFfDFxuWu++ErrUtNF9PXS1aYuHhW40bffIYTFW26l6m2d61LDS tMuTgmo815MWToxWwqa9nqxwatMBT044o6m3vTY8tOmoJz+cG+UADc2eIvQC6jJNJ3jdjvboptOe 0nBB0zlPRbi46SLvtk1XPNXoeqha4bKGXs/EcFnTdceR8PiGZZ4pgQwr80wLZ8T68nrPzECiVfaY OZfwWLUzVtVj4z3d49RuWFM8cwOp1jSPhuOe8Mzj/cuDGmjN8ixBPsezPJDaWORZdatTWPM9a8M1 1iLPBpwbuEQoxVrq2RTs5VcXnmSt8GyNVtrAEWu1ZwfWmejZjS6Anhuus06xbwlP530qPMs6zbMv 3GCd6TkYnmM1ew6H7fy+hd20jtdq9RwLB602z0loHNTwcCTKdjgGZ0fxFquxd4QXcYxmwksJV/Bz CK8mXGd1es4EROtcz/mAYtU4G+HMJDjbOs9zKRqj3wGxF3pBuIdX3XCPdaHnapRXhDfHEFcRnGpd 4rmBfkExXVePdXmHGBhqXdWhgFGAV4S3Wdd2JEZZBM6qH8MrGtZ3pAYKrBs6MoCbOoZGOz7WAYZ3 Wrd25Ea7fHiPdUdHQaDYurujGIg8Mvs6yqJdPrz/NjzE+1T4COEKwuPWgx3j0bvRwcOnrIc7atCp 0cfDZ63HOiYFJllPdtQBz3RMRxeb0jErMJ3u+QXCy7E7c76jIVBmvdQxJ1BjvdphD9RZb3S4tTNP ix3e8LUWi29iJK6l2Tdl3pQWh28asMM3U1vS4veZNWtL2GfV5JYFPlskGXOc2LrYNzcyqGWZT8PW lb55kcyWNb6FkeyW9b4lUENrfMu1hS0bfasieaZlvrWa1rLFtyFS2LLdtylS0rLLtzVSjo65Q1vb ste3+9kFLQd8+yJVLb2+g5HaqDowHfAd1na0HPUdi0xuOeHdEpnactp3MjKj5ZzvDHTcOd/5fh5+ 0XcpMrvliu8q4uu+G89usTG/GLHYZL8Sabap/sSIw5biT4102NL8GRG/Lcs/NBKOKtDmSf5caK6o 0iFNYcvxF0QWRFWeLR8Zp63IXwzNhV4fWdy8zl8WWdyS5x8fWWYr9ddEVtoq/JMizc0FfKZpsb9O m2ur9k+PrInqrGd2+2fd0rNRjWmbSLpyUvNZrvj8Df1H7/HPAZJWsk3x26GYohrnJjTmbts036VQ RfN4vxvrz/R7I+ttZn8QOgt3ILLRZvVHYlxlqc3mX6SttTn9S7Vjtrn+FZEtNs2/OrI9qgdt8/zr IrtsC/09kb2c50QO2Jb4N0NTQ1lHegmP2pb7t6FrQEGjXwAjJzgGSFNHTvOjRM5F0bbKvxNXtBaa y2nb4N+jzeX6N3LRtsm/PxZfIbzO+dJ8FruTUK/z5RjirOartq3+Q/PVaEyYYtvhP6Itt+32H4d6 hYadn2bb5z8VVazzs27DnOb9/rO4Ywf9F4CHOXKNGZwRRdsx/+Worpyf/3/Z+x6gOK4zz9fNMIxl PMYYY4IxwVjBGGOCMSEsIVhRMEHzT4RgrRYTecL0TPf09AzzfwathBAzEEI4grSyougURafV6Tii aIlKqyisLCtaRaslFNERrcKqdBQhKkWRKcLJhNUqCr7vfd2DRgjHSu1e1VUl9dXve29ev379/nz/ +tHdSJNbbrcdl65tWQQO5VByc6tKvsf8anEcL6NR3Fcrka+VuTS3dRXcOcL941drpYWtKXCfCHeR XzVJd7emt4072a1ZwDVbc9smnNqt+V2b6Lp8tQF541t9W4u6Zp1pW0vbhp2ZWyvaRp05W9dAzbyt NW2NvCbY3rGI9w7oj9B2wT0Lrw12RVR8WrA3ssqsDu7cnspnBvdQ3xHcH0nhcyiH/KFIOp8XHIxk AR9a4oXBE5FcviR4KpLPl8NZGvmejq8Kno0U8dXBC5FSXhcci1TwdcFLkTV8JrWfyG/zG4JXts9R axmpQW5o7ghObUvjm4LXI/V8c3AmstFcFry1bYoXgrcjm3hXcDHCIRepnYy4lXsr4JEg7w+pIlvk +yx+c2hVpINvD6VEuvmuUHqkj+8NZUV28TtDucD3hPIje6nNjBxAfpjfHyqKHAFeuo3lD4UqIsf4 wdCayDHZp/BDoZrISf5EyBA5zZ8K1UfO8WdDGyMj/IXQpu2VaEU1/FiIa7Pxl0Ji5CJ/JeSOXOan QsHIVbMU2rKtmr8e6thWxc+EutuOyx6K8si0uQ28IeRDfR2b5cjNmhLaFbnB3wrtjcyaSehAZJ6/ HTocucMvho50LPKFoWORXEEVOhkpElaFTkeJkBI6F1UL6aGRaLKQFbrY1i/kBvdEU+NbE/JDl6MZ QlHoajRbKA1NR1cLFaEb0QJhTWg2WizUhOajZYIhdCdaKdSHSXStsDGsjtYKm8LJUZPAhVOBi+GM aKrC3eHstmtCMLw62iBsCRdEOoSOcHG0UegOl0XNQl+4MmoTdoXXRiVhb7g26hUOhE3RMF3faJtw 2ByORoUj4YZoj5AVBpsvHAubo/3y2gknw7bobuF0WGrvE86FvdF9wkg4DPxiuC16ULgMpw4IV8M9 HWnm2jDcYQnT4d3Ab4T3RY8Ks+GD0ePCfHgA+J1QRXTYTsJHt0/a1eHjbWp7cng4esaeGj4TPW/P CJ9vk+zZ4dHoqH11eDw6bi8IT0Qn7MWui9sr7WXhyUiFvTJ8LToJNW9CzbXhueg1+Sr22vBC9Kbd FL7bftHe0MpG58xqIb9twd7YqokumCtbtdty7ObWtOhdu601s5O1S605nRq7V9jSqTE3tIJ3todb Czshlmst2bbB3tZa3plmj7ZWdWbae1qrO3Ps/a26zjy+pLVu+xzlnYXyXb99d+uGzhL7vtamznIa vXRW0Sils5ruonTqZI3DHYxeZafifu04rewV4M5AZ539YGtzJJ/6984N9B68s4lKY2ezvDuE9uG2 fSC4B9rHSMx+tFXYdonPa3Vtu6Ts3uC+iv24y90p8Lda/Z0u+a7fPty6udNP17q9nrDkaWaO+T+E ML9lFgjL3GF+R1TMByxD1GwiqyaPsI+yyeRRNoV9gjzGPsWmk8fZTPYZ8gSbyz5PnmTz2RfJU+y3 2W+TpxNqE9aRjMSaxC+QzERvoo9kJf4o8UckWwtEPq7N0RpJjrZO20RM2re0neRN7Q7tu6RDe0E7 Q76vndUukMvQmy8SFf73Ay15nDxCniAN5FGygTST9YQjXydN5L+QPhIl/eRnpIv8C/kFGSG/ZFaR nzPJzGPkA+Zx5imGYeg7Thr63CTzNNPI8EwWY2e6mAKmm9nF1DJ7mG8zbzB/z/yUeTPhewnfY4Iq vyrAhFTtqg6mVdWt+jqzRbVDtYNpV31T9S1mu+o7qr9loqqjqiHma6oTqh8yvap3Ve8y/aofq/6J 2YHvY+5Sjat+xnxTNamaYr6luq76NbNP9RvVb5gDqt+q/o35b/QpOuZQ4pOJTzL/I/FniYvMgDpR vZq5pH5B/QIzr35RXcT8Vv1pdQXzO/qGB/OB+vPqalalrlEbWbV6vbqJ1aq/oubYLLVN7WVz1AF1 G/uy+mvqPvbT6n71Pvaz6u+oD7M6+uYEW68+qv4J+yX1mHqM9agvqidYr/qq+ir71+op9RS7Rf0r 9U12K30ei92ufl89z3apF9SLbHcSSXqM3ZGUmvQU+52kp5OeZ/82KS/pU+xQ0ueSJPZMki9pJzuT 9HbS2wnJSd9M2pfwWNJ3k44mPEn/r2rC00k/SDqZkJU0nPSjhGz6PFBCXtK/JE0klCZdSbqeUJ70 66R/S3hdk6c5ltCgef+R5xJ+of2d9ncq+r6cRLqBJ5Ns+rbx2iEFGkAhyZOaa29LQnXtusvVxZJL 8kuba6ekdqmrWqrrl05Ip6Sz1cPSBWlMuiRdkaak64ZVhlyp1xCUdr6ue12Q9kj7pUPSoDRkyH29 GqRKBTI+hzL+W8IwHzAfEBYkOoUkwLFn8UlUwn6X/S5h2O+x34NjQ+z3SQL7DvsOScQnUdXsT9mf Eg2+CfYI+zP2ElmFz6Am49Onj7G/YH9BtPjc6ePsb9jfgHbQJ0tTE5gEZum/BicmqEk6vjmWkZCe kE4+lpCRkEEy8UnRZxLyE/LJs/hWWHZCZUIlycF3wJ5LWJPwOZKLb8Wsxmc2PgH9T2ZSceYoJ45z ZIvjnGPEcdFx2XHVMe244Zh1zDvuSMQxL6mlZClVykBkS6ulAsesVCyVSZXSWqlWMkkNUqNklmyS JHmlsNQmRaUeqV/aLe2TDiIGpKPScWlYOiOdl0alcWkinpwbpEnpmnRTmluiBemuk3Vq4kjrTHNm OnOgNO8+anLmQd1CZ4mzXLobI2eVs9qpA06pztkszTkFqOtyNjv9zs3OdmeXsxfazHPudO5x7nce gvEzj0iK1aDvrD+Bc5IBlECygFQkj7xAEkkhUBL5JJCGVAA9QiqBVpEqoEdJNXkdny7Xg9Wh710+ Tv6KNJIUsgkoFewOR54kAlAa8RE/vnG5Gd+13IZPlEdIJtijHeQZ8k2gZ8l/Bcom/50cJh8n3wV6 jhwFyiU/BHqe/APQavIO0CfIP5Jz0L8RoHz8b9gvkgnyr6SA/G+gQvJLoJfJr4CKyC3yPvT9Nvl3 8gpZBHqVYZkkUsqsAttXgc+PfwZsXwqpxOfHq5hs5jnyGvM88zz5PL7vWQ3WsA7f6GwkNcyXGTP5 AtPMNBM9PktuwLc7jYzESMTEtDAtZD0TYIKkjtnKdJB6sJ1dZCNYz6+Rv2K+zvSSN5l+pp98Gd/u 3ASW9CR5ixlmhomFOcP8iHDMeeafiI35Z+aficD8hBkldpRfB1iBfCJpCjQFpAWfznNrXtGUEA8+ kefTVGgqiF9TpakiAXyTKIjP34U0Zs1XSKvGorGQv4a1vU4WUPbL6JclxOOAYcAZwHnAqIJxBROA SfKX4rB4Rjwvjorj4oQ4KV4Tb4pz4gLwuw7WoQHSOtIcmY4cR56j0FHiKHdUOaodOkedY4OjydHs EBwuh9+x2dHu6HL0OnY69jj2Ow4BDTqGHCccpxxnHRccY45LjiuOKcd1x4zjluO2Y1HqllTSKilF SpeypFwpXyqSSqUKaQ1QjWSQ6qWNQJskThIltxSUtkgdQH3SLmkv/Q+iic2JdnCCX9Zuwu8rvP6f Jt9GoMdRylNQyp9AKX8SpTwNpfwplPJ0lPIMlPJMlPJnUMqzUMqzUco/jlKeg1Kei1L+PEr5apTy T6CU56GUv4BS/iIZBSpAWX8JZb0QZb0IZf2TKOvFKOuvoKy/irL+KZB1lpShfH8a5fsvmGeZbJB7 KtmVKNmfRcmuwvcjXkNpXoPS/DmU5rUozZ8Had4KOrCN2QY6QN+S+AJKcy1Ks475G+ZvQB+oTBvw /QgjSrMJpbmOGQU5rmfGmDHyJc0bmjdIg6ZR00je0Ng1dvq+dkp7Sg+sUzLM/aOE8WwCuSsBlAOq ANVKmQ5QB9gAaKJlqifEUk+ZY/wPA+tMeC+JFZ5KcY1nrWPyftAyscZT67gGuOm9QiEaPCbH3B8G rSPWexrEjZ5Gx8I90N/iJo/ZcddjlljvlMh5bJLmDwPraL3XRdEjSWkeSXR7vIigJyxlAnK8Lszn eWekQu8tcYunTezwRKWSe8Df5d7bYrenR6r6CFR7FyWdTyX2efoRuzy7xb2efVKdDJqnY5M23AOO 9YDnoNTkOUhTxGHPgNT80aD1xCOeo+Ixz3FJuB/iSc9wrN14iKc9ZyTXPYjnPOcfBu5Nwb3iiGdU vOgZXxGXPRMUbi54gEK86pl8KEx7rok3PDcfwKxnjsIt+vrEec/Cw8DtDh4W73juUjiIl0WovRoK dzB4hKYtrsCgw+xtdiR7tY5Ub9pyuLcEjzkyvJkfBXdH8CS2ke3NQaz25jkKvIX3odhb8gDKvOX3 odJb9dBY66121Hp1D8DkrXM0eDc8gEZv032g434ISH7fKofNKzgkr2tFwDFpsy9FavelYz2v1/9Q CHs3O9q87Q+AttcF6PVlOaLeroeBtNOX6+jx9i6h37tzCfT4HsB+Xz7mD/mKpEFfqWO3dw/2dxmk IV8F5vd5938UpBO+NdIpX819bRz0HroPA97BB0DPPeszOI56h6QLvnpMx3wbV+rPh+K494Rj2Hvq AZzxnnWc9154AKPesXhIl3ybYrY93hbHbOWSjbvi45Zs0JRPjLcjS3ISv66xdYnN0XWfe2luZ3zB +D6hLekGmwK67+6TbYB7l6y/qFd7vZnoN0De3QcAh4OnY/LsPgIpXIcel275tki3fR3Soq/bqfL1 Uf/iXOXbRcvp2Jwpvr3OdN8Bal+dWb7D1E46c31HnPm+Y9QHOIt8J6ltxzGDvDtLfadj9tlZ4Tvn XOMboeN21vgu0rlwGnyXqe2kbSLqfVedG33Tzk2+G07ON+sUffNOt++OM+gndH7RB9G5hDl0bgE/ qfgzZwf4H2Wend3QTp9fTdvAY7v8yc69/lTqd5Z8bdwaLbVJofiUmC+gfaK+0XnAn4F9O+zPjq0z 1qe2H9Ye/TL4PBzbEf9qWuY8Bj68Qgb113R+74NB9svUX6E/huvEfDFNESA/OLZlPhavBXCe9LRR UB8b86sxOE97+imWfCT1mYpvjPeV9/lIxU/G4DwHfhDWGH0f+EPniGeYAuWW+rnTMpZsFsB50V+A 6WV/sfOqvwzLwX44p/2Vzhv+tc5Zf61z3m/CcqrD1JdQvQU9ovrkvONvcBF/I7VFLrXfjHoR0wPF LqJsQTvUzrmSwTYpOoLrBXaLnh+zgQ/o1jK9WrIvsf5DG9RuulL9Nrrmrgy/tHQ+rQ/65sr2e12r /WHab1eBv81V7I+iDafjgTG4yvw9rkp/P573UfZH6ZdrrWLHYzreFVdH6TOOdZk9XhoPtcMxfNi1 PsSeumqV1OQdomNawnI7GW8rqX2M2ch4mwh1sR1ahx6DOXA1+AzuY8Fz7pPBEQoa29D1xrjmdPAi loHNco0HtO5zwcux+MU9ErzqivrPoB2DuMN9MTiNMQXYNNdR/01Xm384FhO4LwdvoE2j/p/GDdTW XQ3OUh/tng7Ou28E77jO+O+6Z0PEPR9Su++Ekj0klOpRhzI8yaFsjMkUe4nn0thMiZsw5onFKLQt pQ16zJMaWk3tJe3XUmwXi8Pm79lgRCyGUWIP2haNxzwZoQIa73iyQ8Wx87E+jAd/w3yhnsDYPKtD ZVhG48YYlDjxPiyPBZXY7z4o87o8rlsCjcViWB7XxWK0FWIzT4GMj4zNaOwVH3/RmCsWd8XFWLSv eC6to8zJA7oF+udq9O9+QK/M/n2xGMtl8x90Sf4Baoti9Vxe/1Eq166w/zjKU8wO0DpU50D+MO3x n3f1+0cxv9s/7trnn6CI1zfXQf8ktRGuAf81lM/j/rkH4hiAa9i/gAB5pEA9pHbrfIDFdDSgiekg 1QnXRCDNNRnIXNI/aoOuBXLQ1twM5LnmAoWuhUAJ9T0x0PHSeyzUPxiz626gvIUNVGHbYD9aNIFq HKdSv0Ub0LWkBepaMgMbWnICTdQWteQFmlsKA0JLScDVUh7wU/+HPpDaJ4gJWqoCm1uqA+3UHrfo Al14zwK+sKUu0NuyIbCzpSmwh85XS3Ngf4sQOETvE1r8gSE6Ty2bAydo/Zb2wKmWrsDZlt7ABRoD Uvsfs80tOwNjLXsClxDQHvUzVLZb9geu0HlvORSYahkMXKdy1jIUmEEbBuvYciJwC4+dCtzGNs4G Fqktb7kQVLWMBVe1XAqmtFwJprdMBbNargdzW2aC+S23gkV0fltuB0vRjtHxLwYraOpWBddQeXCv Cta4U4IGd3qw3p0V3LgkPxCD0/jDnRvc5M4Pcu6ioIjlis11lwbd7opgENcP9MS9JrjFXRPscBuC 3UuyGrsPiPkoyLvrg320jntjcBctIyxhtF3afkL+/BeUP6G/oMyQW/f+DsAtEMmaac2x5lkLrSXW cmtVg8pabdVZ64BvsDZxCzJZcyiszVaBuyuT1WX1Wzdb261d1l7rTuse637rIeugdaihz3rCeqrh tPWs9YJ1zKpVaCfikvWKNU2hKet164z1lvW2ddGmsq2ypdjSbVm2XFu+rchWaquwrbHVWNkYQQ2D rd620bbJqpHJxtlEmxvqBbGHtEe0Jj1GrwdXoPv8jw2CbK/7T9kHNYJurAd6AvdBU3Ef9EncB30K 90HTiUBE8jSRgDJxN/QZ3A19FndDP467oTm4G/oc7oY+j7uhq3E39BO4G/oC7obm427oi7gbWoC7 oS/hbmgh6NwoKSJjQK/gbmgJ7oa+iruhn8Ld0DLyK/Jr8mnyHlAF7ol+BvdEP4t7oq/hnuga3BP9 HO6Jfp7JZrJJNe6Jvo57ojW4J/oF3BOtxT3RdbgnqsM9UT3uiRqYrcw2YmK2M9vJF3FPtB73RL+E e6Jv4G7oBtD0H5C/ZH7I/JA04p7om7gn+mXcE31L1aP6OjHjlwabVSdVPyQc6PV5YlPdUP2aCKC/ CzCXDAmTtnuyaoERWy5brlqmLTcss0Dzljsw8WoumUvlMrhsJBsncV4uzLUBRbkerp/bze3jDnID 3FGk1VwBV8yVcZVIa5HXcibgDVwjZ6ZE5YZ9CeTmZUVuUvH6VGJYWKMXQHqorKhg/ktAeqisqFFW kkBSXgcZonvmj4B0NIIMUfl4FOUjGffJH4NxOUCSqDSkgCzsAHmicpAKUnAY5IlKQBr5PtBTKAHp KAFPw/qfA7ml++EfgzX/V5AwuurP4Kpn4R74s7DyN0k2rnEOkwJr/Byubi6u6/O4oquZtxgz+QSu 6Auwom6SzwRhRQtwl/slphdWsRBX8WVcxSLc0/4k8wPmJCkmjKZMUxm3HgWqJywFy4nbzLVbii1l MeLyLJUKrV1OXJel1mKSieu1NFgauJ1Qsoy4Pdx+SyOQGchGiTuEqWTxxogbtIQfJG4IWwhb2hSK ysSdsPRYerhTwPsfJO6sZbdl3xIdpHUVGlDo6HKyH7Uftxy3DMfINmc5o9D55WQftozGrmU/YxkH Oggly8haalmwTADR601SEvI5LaTX8Awk6+yDrVvOCzXYwvnYzFpuymQ/b5mzzNkHgC88SPZRGN/d JTJx7BJpZFphpi5wY5yWS1uiS1wm0pV7MxEjborL4fJihCt+nStcRjOAW1wJUjnQbaV80aoCXrU0 IpOlzbqKq36QrCmczprO1XEbKFmzuCaZrLmcC0qauWZrPtcc184SWYssNzlhiVycP0by7FsmYUVA vq0VKLu11jXWGipjVgOdCWs9lQ/rRshtwtEWWjmriD0ScaxyS1RSxnGVRu0T9kmUhms4+zdxpmes btCdYpi/MkulNWgZsG6BWdZaO6B/3dY+kGWzdRfIe9i6l2OtB0CW+5u7rYe5crhuH8hJFOoesR6z nrTctZ62nrOOQI+p/PdbL+IozbBiFyxR62WoYbJetU5DW1RrcURYU9YVurpRS4P1BvR/FsY8D+U9 UK8MtK7HegdyxdZNNmKptKltybZUW4Yt27YadblBJluBrZjqq63MVgm01lYL2irJGmsz2RrwanAl W6MlajNTnbRBy1BTsnltYVubLWrZbetR9I9q4ICt3yaBrGlR3jLh6G5Ox5Xb9nGZtoO2AdtRrsl2 HNYXVsvaZxu2nbGdh5kr5KqhT7u5MduobRxqTwBNciW2YZRAOkpcK1oPCCSGzpLtGuAmVw063G9b gHK/7S7P2iZ5DQ/X5tP4TD6Hz+MLYa5FvoTKO1/OV/HVvI6vozIOM4trzm+w5oO0lfNNNolvBhJ4 F1dFCY75+RJ+M4xAx22AI+1cE99F5RR4M9/L7+T38Pttq/lDlpv8ICfwQyCPLjo2/gR/Cq7ZDBLq p+Ozz1mO2xcEDizDGftdWJ9JGE81yEu/yIoasAIDohYsxXnbbn5GTLNkWIabR/g6MVPMoXoNMgOz JeaJhWKJbUAsF6tAQqnlWABrRmdnwD5sH5ZrWPqFi2I1tEXtHUow1pStDEgwtDUu6iy7xTrLUXGD 5TzHQr1h6M+c2AS543yT2Gw5Y63gS4QKURBdoh+toGLJxM12tKx8uX3cPi62i11g567Jtk7sFXfi 1eBK4h7LTXE/tWbA58T94iFxUBwS0kWw6HyTbLnQdmnsN8VTYi/XJJ6lPeHPwjpR2WniL/BjVH5k svZBv8/zl6hN4q/AGk9xdbA610GuCsEeFPIzMNeH+FtcFX+bX7SYBJUAdsdyTUgR0ptHmkeELFjB QyA3c5awkCvkC0VCqVAhrOGabZN03i3HuXKhRjBY5oR6YaPtmrAJtKcHDIzIueD6k+AfrwtrQIO1 YLOa4YhbCApbuEyhQ+gW+oRdljZOI+wVDgiHLePCEeGYcJLTCqehVa1wThixTEDLk8JF6JMW+nJZ uCpMCzeEWWEe+jgKbWssc1Dzjp3Y1ZYeezJYm1TQJRPITQacUwiyUm7PBvmdsa+2HBXy+Rl+xtrH T1kmbeP2AnuxfTXMA2svs1fa19pG7bV2k73B3mg32232Wk4HqWRbsHvtYajdJvTxY/aovYfz2/vt u+377AeFPvuAlcNo6uU/32H+Cd1hCsSNTzWk0/8mYx4gzFdYkmY+BDQINAR0AuiU+VQjkPms+exb E29NmC8AjZnHsOwS0BUgWjYFdB0Izts4u3HWPAN0y0zvYVmtSbserpGCdzQE72hYvJdJwJhXhfcy iXgXo8aYNwnvYjR4F/MI3rk8incuyRjzajHmfRxj3hS8Z3kC71aeJEwKl+LCMeFzh+ZSwpgNkFZA Wq96ovawueZhoNNBegRw7ENwUoauSUbt6YfEOcDICrgoQ+eH9PLDQdcO6VUF0wpuyFg3Kae6PYD9 kJ8FzD8I3SCkdz4auhOAU9AuUaAGJN8PHNsyrEtdhow/AtmA1SugYIV2KYqXoezhYIJ5X1cJWPsh qJVhuixjnekh0QBoXAFmGSZYt3W2h4MJ1nadpMCrICzDdENOjVOQjgPaANEHYQIZWNfz0TDNK230 K9gN2LcMB1fAwDIc/SNwHDC8As4Azq+A0WUYfzjorkM6YUb9WBFwTDcDuKXUu/aQuAmYWwETSpuL kC48HPQqSO/eg469h6U6KUqaDsiCY5p714qHPle5vvajoc8HFN1/vi5tGTJXAD23FNIcSCuUdM3K /fkw6PIAhSugBFC+Aqruh74mzn7H29uYvVTsmN5gXrIv+nrz/fYjJifx66rM99IcbYyb203392nJ psTbgJgOK7pFfUZM5tdnLJPpBfm4ngOIALdsI6h/0W+Ry+mY9B2Abtm+mul6gZ3U7wLslX2A/oBi 3+/I8q6HOYnZZz34NP0xebz6k8o8QJvUXtI2EbRdWE892EU9zJ0e+qCn7d5Q5leZT3ou+smYD5uO m2dox0DkNugxA/gLQ7LSr+XrtGyNlnxKbJ26Zd9oSJX7ZsiIO/+OPBb8fUzxffDbkK2UHYnDyRWw 3C9fXAGX4/xrnI9dwmwclvnXJX/5H/GT2eb7fWGB+Z4PjPN3SzYLYFirpOC3DCZFx8B+GMAnGcAH GcD/GGxKOegw9R+otzWyPhnAzxi8si0yhBW9UPQgZhepbNF2qJ1D+xTTkW7ZbtHzl2zgct1aplcx +7KkW91K/6PKmvfcOx/rg74ZwDcZdsv9NoBPMlAfNKnYJDoG8EGGo8p5H2WDltvxlerE+ryCPV46 prmHD7V1H2VPc+7HA3Yy3laWxNnIOHuIdXOUOuXyHFAbvR7kZ32BDBrb0PWmMc36YqUMZMVYDXlq x5T4ZT3ERoYFxY7Bmq6nshWV7ZmRzj2dLyUmWF+r2DLq/3crdo7KH/jo9dDeemjPCP1dD3KzHtpb D3K2nrYJMra+TbGfMXt5VInNYnGT954dxbaUNrCPUdleYr+W2+FlNngphonZYTpO2hY9BjK1vj/u /B5lPGXyfGHMBWNbv1spq4xD7QpYHguaV4Ayr8vjuiW0xWF5XBeL0f4jsdlx8/3x1xnzvbgrPsYy K+cOx83Jct0C/TOMmh/QK8O4eSnGMlC9npRt0ZK9uibLteGmIk+xclpnQZE/moJdMSp6ZwQdM2pl xOubMU22EcZMWT6NeSvEMQBjoYISGWgHafvlSlp1TwepThjB1xnr4vQP6hk3yPpmBB9tbAYIsu+J Ae3RoDxPdMxGF8CvtA3jMG5WxqnUN8I9nbEL0AvYaUZbZNwDgHs44yHAoOz/KNBOQkxgHAKckO2x 8ZQsp9QXGs8CLgDGlPm6BLgi3ycYr8vzZJyR6xvBdxhvAxblGJDa/5htNoEPMK2SQdtDPwOybUqR 590EMagpS5YzU648j3QdTfnKsSKljVLZlpsgRjRBfGiitgfiMRPEYSaIq0wQT5k4eX5NomLHYPwm t5IGZXkwQSxkghjIBD7C1HdPfqjtpvGACWIhE8RCpgNKuWJzTRAPmI7I7VM9McEcmSAGMJ2Ok9XY fUDMR0HedE6uYxqRy+jTGI+dfezHf34a409pr0xVoDpH/6LKjpC/IyQpB5AHKASUAMoBVXFpNUAH qANsADQBmgECwAXwAzYD2gFdgF7ATsAewH7AIcCggiHACcApwFnABcAY4BLgCmAKcF255syHpLcA txXQ+ouEaFRyuWYVIEXp24ySwhg06YAsQK5cvpTmA4rkvmpK741ZUwFYA6gBGOR2NPXy9TQbAZsA nFIuAtyAoNyuZgugA9AN6APsAuwFHAAcBhxR0mNxaaz+ScBpJT2gnHc67vg5wAjgIuAy4Cpg+l5K 50dzAzD7R6SxuZiX5/GPBa5BPOpk0PZxvaaUujeW4Y78b+djaez8WLuPqAHJynpD+SOp99JHMgDZ 5O/0tXqTvkHfqDfrbQhJ79WH9W36qL5H36/frd+nP6gf0B/VH9cP68/oz+tH9eNAE/pJ/TX9Tf2c fkF/18AaNAatIc2Qicgx5OHvQqASQzmgylBt0BnqDBv0/YYm/YCh2SAYXAi/YbOh3dBl6DXsNOwx 7DccMgwahuD3CcMpw1nDBcOY4ZLhimHKcN0wY7hluG1YNKqMq4wpxnRjljHXmG8sMpYaK4xrjDVG Az0O5fXGjcZNRs4oGt3GoHGLsQPRbewz7loRe40HjIf1kvGIQseAVsqfBDptPGccgfxFhS4bryKm gW4AzRrnjXdMxKRGJJtSwSd8bMUvLhDliwsa/OLCKvziQjJ+cUGLX1xIwS8upOIXF9Lwiwvp+MWF p/FbCx/T5mhfIc9oX9VWk5e1Fq1AXtNKWg95XevXthK9tk27jXxRG9V2ki9pd2j/gbyhfUd7mrRr L2jfIx349YXD/x/3jGFSGTc+rzJM/5t8bokCsCy5VQqqFeji8hSgNbkblDyt16TkmxUICsDq5oLV zQWrmwtWN7dLqdur1KdlO+N+71HS/QoOxV1zUPk9RF7SjQBd1F3WXdVNA91APq2bBZrX3dETvVqf LJNuRJ+qz9Bn61dDaQGUZ+uL9WW6aX2lfi3oJGqlbh700qQ3w1o9jl/aIPiNDRa/sZGgLdGWEJX2 dW0NSdSu0xpJEn5vI1n7lrYZ1sGudZBntV6tj+RoN2u3klxthzZC8rSntKdIvvZd7bvkRe2MdoYU /D9unVl8U/V54I0gHczio5hfhflXMP8K5l9V1QIvTfRjeTOWfxPzvcBLEr+P+VrMy+e+gvk6PPeT wIuwvFTlwnbouSXYfpPqVcoT36TPPiVuhnyaai3liQHgx7DOd+h1f4/537+DfejAcgfmX8X8q5gv lXur8M3IPVgH2vz9L1QvAZ9SRvQSHn0Te4UjVf0FjsuOPRdoPmEC8xo8SvCs/4klTjxXjyWPY/41 PDeErT2OPXkNeSLWKcM6NuDFmC/GfImqAstFzJdhC1iO/FU8WoJHP636DOWJDuxJBdak+VcTbmEd eR56sbVT2Bpdi0+qBrBc5uXI67EOh22ewDZhNtgv0iuyLyeagXcmgnazQcy/hnwi0Qu8jdZhWORv Y33sJ0soT7BhzbcTLcAPY5tP0BLm5zTPvI9Hd2D917H+NzCfhq29j3wK699R/QTKWdWPgderLtGr 0DzzGyyxqX4OvJLWIQuUMzrk/478HcoTErDmOmznDVqf+SW2MID57+HRL2D9D7B+AeavIz+L/O+x /nuqFqhpSPxHyN+mcsuqE9+F/CItZ5oTR4BPq0AS2Exah7yXuB34bylnrislwBNKsJ1M5Fl4rhX5 DuRPqz7Ao1+B/E8pZ69i/hTyi8jfVjXRNVK/h/wE8kHk3chnKU/KgGuVyiuINTvV9BsqzZh/Dflj Ch9E3o2cnvs01jyHR4ewZAJL2rDkgLzuNA/8BPJB5N3IZ5HT+uuw5hY8i8g88VtUKjD/Nvb8MOaH kR9WSgaRdyOfRV4NYzmT2I1SJFCOV/858vfx3B0KP4F8EHk3ctrCDpyNb9A6CXuQfwP7/D7yKWxn ivaZeS9xFPg88vcSv43cjfwt5CgJiTPQwtO4Xrex5hTymwrfjjJwlsoGlixiC4vYwiK2sIhSMY1H p7FkWikZBp6AY3ku8RzKzChyN/K3kP8vylESpmQZ+7+snQ2YjdXa+Nez1vM8e2I8SUOM4UyT788x PkIiwvhKiJKUfFZCc5AkR5IKSRQl30mRUEnlOzkMORKOkOQ4JRxpCMkRe951/9Y+15V53+t/Ov/3 vVzXb9/7Xve6n7Xuda+1nvXsPZvINtPE2y7kH+w9vbTBanTDBG1f9BbJUp2GJg1NGrM7TTxbboar ycwlto8jXH7ieTKckqgr82IIOX+d/E/c9lqzYQ7sATfDk1B8HqTuQaKxE287kachz01QoreNdnaM ibciji7TkN9yDNYwsjmMo5SeRf4hvFki7CitUmjsmVaYin4nI7sTzXLmSAWYzipUi/XtmbCS5ZPo j7EWnUN+SXYQ73vWtCJuPRRLr1DwgOW1rGZj4XVEYxk21ZgLXyJ3hIsSa6DdXzz865gw3CWjHz4v 0QhYS/37JSbhSpHDaiKb4+T2IvIki+zdTq2VwXKp6y+jVVLa363noaycVYV2bu5hTu1hHsnsKI88 hdLvE30cQnv6Ufcd7N8hzqwwwXGJj9Cu1UI3XtVDuz/qYdgXQd6E/ajE6rGYdWCc7A7MwX7op8Fr YHmusg/mx1rJaMaWcF0pbSGjbGeuyCkJis+6iTV5jpVLkpO70KTDA2FpGV/W27nk812s2ytkFQ12 k5M7xTKoRO4licaOneRwiqzn3nY3i+1Z2e4IjMtuibBdB1aTY6uZlY6bmS+r4WZ2EFmrU6Wujecn 1HqKGfQUeShXeVRaZVpLqWntVhXf3qt4ZZjjzai1MvyF9UHs60trbSaL5qjMdJvhX8rOQsuzEuvP U1jKVRbAKXBjWFHk8AVm7u2yyzBzD1K6NkE3Q0XuHFal9CSak7RfIlwv3CVrHa2dLbuh9zl7Yiqt vYz+fWJeBjmdvnwrd0q6gy/+d/iR5XG5e9SlhHa8nmJVkVGbQR/nyFwztdgHKwtNum81+jM8z8Ty LJ7/hvw35Gz8b5fIW4rnNrR5kFC9h3wC3hUUUnJfIf5vYqSq4GGH23/lPsreJ/Rk9ZMMn8Ddywm/ P72QfLuB0hm0fBfXWoe3VOmp/1eJRkBM/F8Y32Gyv5sS4s18KbJ/E3JL+ptHL35hrfiFmZhKO1nt 9VppoalD369KtFZakoFczbf3rt4Wev2xb+8GvVto21bqku26oT9A5ji1Oss9sO5sfrSc6rewnhsz jiv8PpKfeqaV9+DtWILibS5+6uIzy/ctvxParCuj5K7MRsDEiMNCag2Gk8mB475EbxkeKsFX8dMe +VH6Pps4N6OP/al1DB6ED0nE7F2W9GKM3LVa+SrJCvaggXjrRTs74ycMXpEVIJGN0rs1tOdiWE4Y nIVfwnXoM2AbWRPcPadY6kzYMNjHPiJyS3cXip9dcAt+tuBnC36+xr4f9v1Eo3PQNELT3t21iqzO S0ssv4Tr0Gcgi30Rd2fLVdY5ch/VGj+tpa7ugtzFyeLHch36DFgGTRr5w/0GPr/D2zm4CC6FS3zZ AbPxmY3PbHxm4zMbn9lEKVs8mypiaaoQgY142Ij8IfKH0gsb1Tm0X/iB66/Itm1z8DOHWmfxIJr6 tPOXBLcxs6QNnYKazFYZnad8udvckDgdyFU2+3uZs5wOxFK5O/kj3NuX4hTQCn6Gt1L4Pw/3wiXU 7QpbUncl+mNwu2+zNMyQfoWLhX5/sfF3BKvsTOda4eBA9qnuxCqHCPwT+0iiGi5mXteitbvIk+/g 5MQ5ZR+jk0tO7mPU9hEZ8lNmmY1ABRmp4DrLWZyJNJZlsdyFPJarN3L5xli8LRpjGCmDvjX238Ff 4CKYy538ovAoVxFNvoyLHV+RjybIWCOvdJkjGpsJbRjBNoy4PUerseav9lzZPigsDO259fIXMhMv fxHYUTYzuVPaJjHxG8i+4/cV2bwPX0a/SO7H/Lmsitjbe2O5L/oDddtyX/Qwlp/KedPfIqu04fxo ush52S9K6QfUelMYK42+BB4uwSXY30+ejJKxMB9KbM0h5GxYW+inyxj5GeTGOOw/IaO+EgYLsKlN VqSKpRnPyP6I3J/SypSWJFua48GdVZfAVlyrCXcFc9kBW0rEzHfsIONYGzexa+TK/YmZxx3pJPag +dwfjkTzDHc1efhZD/fAL+FX+DkCd8DH2Ju+Yp9dKQw+RR4FV7G6nmcPek7u3/yq3MV9lZA/govh OJgnpXLyCk4Q/9ZYJsMG4d2W7kTGCdGsSnAxHAfFw/tYDqfWh6KxFE0H0QT3kRXdudd9DLaFOdwZ Dub+syVnUu5g/QrkzxquhaUZJ2upj8ZSenEcz+UT/AguhuOg9RZUljNp+Ak5syUoYWsVxts82Bty PvVT6PvjyB8l+BFcDMdRKv16XGLlrxM5ViZ8DXYV/9TyE5T4cEYwSyQOpgl3fSMTnA1zYA9ILsmd W1iIcb8Xy5ayNgblgy1WPhV8avka+r0J5sAecDOsKflGaS6aXDTj5V7XvCsz1PsT99Jl4c3wMe4t 0zkHNeDetRp3xZPIqMfI2ElyH6hb4vkD5Mc5va6gbd+g/0b8+G1p/yHR+KUTnA1zYA8o86uitMr/ g5xhw4Uu52VG6CN4KwzncYcwmnmUwv3DH8n/WZR+leBsmAN7wM3Y2Hj618tVgk/luaKl2Kyi1irk FCJwnigdCBYzF8pKqSMn1qNyYvWPiyZYJy3xP0I+heyTJz72I4MfGAVHOb1+IadXGw3Jih3+aNom GauQV9HyVZS6VbQxLBykWCoZr6BU2NHK80UfXE8mfwMfT6ylsvKsZS2dgs0E7N9mxv3IPCrMilqf FXgG8hpZgW1e2VrBBsYlF5+cXs1LeB6It6rIH8n5155wpTQHy7XCpHWS4UmK09areOaZScyt9n/h dDOOGXqCGfQhs6Mu5HRsluJhId6U/4yttRY/H0vbfJ5T+ZyI7VjIHtqXs/AQka2HPLiHeZ0H9zBb 8+AeWvuBlV/giiuJ0iW5BzAzWZ22QJ+2rZEzsv8GHCo0PDkx28JnZb9jFk9B/hD7udR9gZk+TjTh g7IahA+j/xT7w7ALnBeeF8a6yU6HzZuSObHSyCVgbbxdwn4qbS4ku4NfTJ5T+TWDVPJHZC1tC07K 6PvFmDsj3XmTfFgSbJU8Eb3/XeJMLU8sF3PGacC8zpY9ItaKsfuSkbpJ5LBQUMSWXmDPWiUnYpu9 siY0l9JYK3aWeTKb7Hq1Gm5mXVoNZQ9tw3OkqugPoT+E/hT6I+i/Qt8db99wFXfyGsnOuAeukusG h6VHIc9jzXJO3PPZ46aLvf6znK/tKteDCP9Cm2VdaiBn7bAIsz6P2b1eaCO5nXWmJi0R7qC0MPdF heXOx66Hl5kLs1kxpHQUHJdYPaTWPtaNT+TcbW1moJ9B+1mvwiet/BFtbuGXtnxd6KcT//fo6deM zjBs7kpYiqYs56DPpI/+NXJGNjxVNu7Utp9T21bW5CeIQxrjXp1z2WtkS8nArkVhErV+4Q7hXTmP B/19e7LwJ7HGDqLuIOpORF4k19I3csVejMtcTv196NFznHD3MCN8NC/IqdyvSjvvwf40V6RVwVjk kXI2N48gO5uBeKgH75X7JXvfKLNylX+d7Au08Bh57k7TTcmEbPpe06y1/eomfsKhcITQn+cvZeWU GXGryMHwYDitknh2xsZ93rGO1SyQUjNEdrHAw09R4r+KFr4p525zAPmUnNZNLeRsOa2bd+jL1dKS gBnk3+WXspo5tH+0OWX5pLGZ4J+QT3nCN7gn7Cmndds7aU9pObObCfgckqDEsAi8S87pwSp4t5wj zK/S97AEEWjDGfxbat0v53RTHHk9pedozz9o4XL0P/FZRrpEJqzE1RvDHvR3AKyXuLeUXbUUtbbL yV3/VU7u5jniU4rnh4dpYU/YhtEZzzi2lVGz2Wupl6JJo50zOMVMgU2czAllCnNtCiedKXKqsqX2 JBJU5I56A5ZPww+DZ1gPRY5gW0c8tMVDWzxkY5nHWa+qaPyqaPahmeHbEfeoq8vBZzkv38F5+Q5O YQ04370mZyWbCdZeP4jlV1yxBPef1fFWXer6zZGfckTzlHizXIc+A5ZhZ7eRCXbRu/6+PRWaWfhs gH/Xu8bwCTl72vbTC3xWxWdVeppHT/MkVv5d4jlsHuyGT0sW4eE9R+LTC7kVcWgStiNWwts5vx+Q 87vtRTt59uXv4rrtmEFf4+Es3trJbiWtsiuPcKZf3vI+f4zVD2dF5bxsz9dSOh6moWnsj7Vyji9t q46G9dYvw1j8CH8Smm3CYIfQrw6fkrpBDa5SHJ+tYUO4AG/jXKzwcApWIsKPw4Gy4sW2SASS2hPP C5z7HuYp/UCRYyG7Xk8pDSoS4W1YNkfuK3Jsi3hLai93JkGc82AD+uVyoz6j3JxxmYWcgodG2Lwj zwfM/RJ/P5VReI/cuF52MXNUemeWIhdFHoXNIVidWhkwhdEsIXWD+TLiwQL0tbFcyCiPF1n/iKZB WA9OlXzDspSMps2TZ1gDhTvxuQS5PG1OIYZPiN5aXqC1F5ihfFKf/7bylMn/DHmpfJYNs/IXIleG 4+RT8kTp23A+9iOQHUvCKehd3WXIy/C2BH6D5hvk/dhYve6YL09Eq8Nn4DDYBO6Ho4SeFqpzaLKg Epp+yNPgW/CahCyfGuyj7lk0U2ALar2InELpYXgRDVfRndCcQnb+G3H18/ArSv8J1+HNYNMadkH/ XUKWNixCsxRNNnI+taogH4Ub4YfwByzbIV9ADpHjsCT8Nl5F7gxpD/bqZ9EYF5k0mCoaj157d8Ev 0B9EXgt3YuOi1zHe1Hqo48ZCZN0EzoHz3CggZ0EFp8G34nJ3usHFXzTeu/AspZ/jebrrHfJ1LvLY xLG53vUFzWFadRR5V6IvTelXkq07grojRaOIj/ckllnx9vRiBi2fQWtn0DbhFDRn4Q9orhcqJ6fB VHiEK1aA6bAWPMa1XAa+hPw9TI03s+yMfC0jO9blpOj1MuRqcTl9f4ncED1ZoWPCkEwLHxP6q/Bw WSIQDhQ52MZYv+Uikz9TPm3E/nmXG3h7iTb8gs0/iVVHmZV2TpUk/4WT3ShfPiMzjp4OS1DDdMvr YBM4itJReBslGhtP0bdEnwVVgumyLyBPS1As2xPtfYnIpzMKc6DILURvXqT0HLXq0kKX4efoEfH3 DrgRoadzXT4j98FmBVHa7VYPiZW/h4i5+ZuCnEZkNmK/MX6LPJVCHoafR5FnCw2z2LQmAy8QtymU MppeGfQ/SAy9S7Q5JHqp9CiJKMWFNq+cLH0kVt7z0OVhzwTTqTsHP2L/BT53U/o2JJ7qNL0+AWfD z/OvtbxMHwuheR+5DHI6o9YBeQctP05pKZHtirHIam6hdAicQekcIkC2m1rIbqanSsR0ZfRuRnwG Z+K5Lx764nlvIkoiu5VtO/N6E7P1GKPAquL5RP4m/LiVcAf8R35tiSTyNrcGYjkByxvcGshVdqFn 9vmjmTtbkH/Jz7btdPvIfFabLyVW/k3ILdHn4ecXZFZCfRWsCjPcnMVmC/w4sTrVtWSn8LZis8LN aMgKoKcSpcbY7IFu3SBvNfuCjao9UxjmvrcQDoZuragEX4WPoh+K3Az2JwMfR/92Yi+QfB6TkCUC bu/ojj1riO7l9hRGMyT+JeEU+AVcC1nPvfcZr3zkNfAidXe68UImkt4p5H6wPVE6j1yE0nXIrWGX +HlpIfrv8DkZLoVLEvPXXUsyfwuZf54Z0QVmo9+IXB/7p/DGvuNt5upxcoOd0WMlN6WwXEe2IHvn WY33Ii9B3xXZrauMfriYjCoKn2aF4f4kLIs3tyJ1obUf5s+Sz5jwkB9/nv5aernwIutwJ1aSpfA+ LC+yDifTF7dPpSTW1XRyW1aGRmgaEb1GrCrn0RchDusSlLXXYNk6QfGwiNKlCaaz7wwghum0U9al dEq3ww+p24FnjOd4hp/Gk8a08ANrmZz4do18O6U+38m5zLPlyvItR+8LoV7M57+bOXvyhMr73pdv 5mzgRManLbp5WFhmOp/g7BBZf4p8xt/PWZXPvOT+XHXTFWRc5ImEqeI/JFf335B7DJF1nv+TZKPQ nPHfUvJ8yVqqg0LvQWq1EgaLeaYRwhr+SJmbeFjk2/te0x0Pl6Q07EytTrAO30+4AJP8VBlx84RE zGwSG5H1aPkLFz1AaHLMIbxZS7VV6GW4Wmh2C/2TQtsL4XzzgvQCP83lqYLOdX4o7SoMxuDhAjwE J8DlRp7nVBHqtUZO9+lyrtcX0BQLutFO+RZZsmjUbpHVQaG1F3mr2AeN8JNOrUwj39+rYKbL6Jv5 tG2JPNOm1nLYEE0lsQ/WU+tIoiVS2hXNHDNCVhv0jROU7xH5CW/zJUq07SORvcO0x2hPGJyTX71B 1lqLxltPqXwDubb3Ld+YlW+1ddATLKvLUxe9Vr8oq65+Tlqu35R5LbJ+Vj9rOUrLp9ta7L0psJPQ PIzNNM13HfVky5pmvOX7yNXMQvxY2TuLJXV1C+q+iHwt3s5Klnp/4+oX9bUyl7VkRVddknYWlfzX fMqvQ6tpqq+WuawrylwWe6897ChUPwuNwUMrvHXRpWTN1F/gU+Tz+jvZNZCXYNkOD3Hq/gH5KPzU kwivoA0nvBusZQ1PnnDaddFqLnnyKfNl75zsBTpT1lU9mk/t5Zdlf/AOS3uEXlNdQjR6pexc3vey 58I0WENovVmq75Anw2LeISwPyUxHPuiNkN0En194Cyynel/LfiQtUcfw8LO0RF9SSr6F7p8WhinI f0cuwrfTCyPfiP5dNNaP/3poffrdYHN4UmiOw6XCIBn9JaH24QtoKmFzrzDch2UV2I7SDOReyF2x PIoGvT9BGCuLXJHST+A5NFzF/AW5L/Jo2AHNGDhc6NFa3ZjSz5AP054QmylwMaWbkd9H/hHeDu9G T4/MZeo6b9vh0/Ah+CWWdZDpl/mVK/4ReRPt2QtPoHkDb32oVR/LbeivR16GPJuYrER+DM6Flan1 eszuPmFpNzoi+ydhvhsjkYNkNJeQb3FjhOYlN1Iim3thL5iDt/vceFEr5kYNmZiEp9yoYb8UHqU0 Qxgri+YT2lYTy4mwv4sPV7+VFm5wMRGN3RNFdhEjzv582IgrEm3vJ0qJpF6LB7IumApzsZ8Hd8Pb IL32XabNpp2jsC+PB2IeRLSB/NEVyL2rsD+CzTvITbB0OdYMRsKkd6RuUnHaabDJxsPHMAV9aXpd ichsw34apcwRfw+1ynEtYmumunlHDPdRl9j6E2BF/HyATSb+iaduSt0V6JllgcvVB7mWm4llXe7h 53NkLPV4av2AzcvQZQjRM4NdJnPd64nVMqH3E5qZXMvlYV14E+xI3Z3ItfGQBY/Bf6J/lmv1Rr4D P/Qr4OpBPSwn4Wc6MpHXrA/+AjgMdsHGXfGv0GXIGkofhoyLKcUVH4FEPobGP8sVR6B3axpz0Hez m5kbXI2mGGRlMGSFwZt2KxWrij6NPXX9ofBtuAi9WxuRzRdotiAf4urklWHu6DPUIusCN5tcj9Zh Uwj7WWjcuK9H3wmmQtpsWDPDcfh0rSIr/K8hc8onNzxaHj5JrSewv4jMTPRHwv3oGVND/IPu6Fmj fFYtn3zQrOp+P7ga+3PkzGjyx61XiyFrUcA8Mk+jcStnHnXdmDLuhpEKySVzD2SumcmQ7I3tECaR FQH7V0C2h0Q7Rt9DSn3sDWuUaQBvl6srJWcQ//W4fFrUDTaHJ4XmOFwqDJLRXxJqH76AphI29wrD fVhWge0ozUDuhdwVy6No0PsThLGyyBUp/QSeQ8NVzF+Q+yKPhh3QjIHDhR6t1Y0p/Qz5MO0JsZkC F1O6Gfl95B/h7fBu9PTIXKau87YdPg0fgl9iWQeZfplfueIfkTfRnr3wBJo38NaHWvWx3Ib+euRl yLOJyUrkx+BcWJm6pambj80tyC9RmoN8H/oYpC/hKViT0omwP7yVWhu4bhotdC2nv/582Ii69Nr7 iVJ6pNdSl9EPpsJc7OfB3fA26FroRtz1axQsjwf6HkT4ZBx1BXLgKuyPYPMOchMs3Vg3g9RKojSp OO002GTj4WOYQuk0ZDLT34NNOTwTGUP7zQeUZuKHyOim6FegJ3sDlwMP4s1luMvVz9Fjo8ej+YHS lyGjo4mDGQxn4s2NY114E+xI6U7k2tTKgsfgP9E/i8/eyHfgh5YHXCWoh+Uk/ExHJlaameUvgMNg F2zcFf8K3ZiuofRhSCRNKa74CCR6MTT+Wa44Ar1bDche380Lcj64Gk0xyJwyjKPBm3ZznPmoT2NP XX8ofBsuQu9WFWTzBZotyIe4OplgyHB9hlrkSeBy3vVoHTaFsJ+Fxo3sevSdYCqkzYbVJhyHT9cq xt3/GjILfEbfo+Xhk9R6AvuLyMwdfyTcj54xNcQ/6I6e2e2TCZqV0O8HV2NDVvtuJclDdiPFaBri H5Ih5h5IzpvJkNyL7SD/GeuA9TwgV0NiGKNHIaU+9ob1wTQQqq/1V0qeiuywpeXccwwzyWpace7u J08bzHyeJLSmdI78baxJl++nmek8S9Gi0f9AP0n08gULJX9tIZruwmC30K+B/hx1cyg9LgwHI/eD rfCW5yy5btfE04xySp5RyNlwDppnEk88avC3dfIUpQ3PTy7yPCSFZyNL0C+Qunonmn6UvoKs8ZAH h8FF9D1ZqEcTgc7yhETn8tSiDnId87HUFRuVz/OKaxPPTyzV38UmyMJPJ2o15wlJQ9F41/qzrL5E 4tnIEp6BLOF5iGX8pXx5TtUhf4esvchd5Wyrd4rstUDuRmlz5HXI+7EciZyE3JDSP1PrBJpizhua b+Ny0q+GTTFqZcJelO51pDQV+SKlr+GhHPo30ddDrkJpiPwA8nOuDSJ7X7k2UDpc5Hin/PM2Eyqg Wa5KWR5AniOyuZqzfL7QNIZn0FxEno7l34TBbqHvoddwCaVJQu8cch7MxF5hMwlWgWMpHUYbpiL3 Ql7EFX/AZgTyVkoH4KcQ/jfCBYmWS0v6o1mJZi2cAOmpaUVphGZ0fA3/C7t4Xh+XJ4HpeB6UaIPo D8oYmcZCdZC6y+BkvPHEQx9B01ls/Apx+a5aE0qbxhdaxlU7qy+KTS3R6NOuzXieL20Iy6BZJ7I3 GX2n+PuSn2Lvb6J0r5TavsvoJOO5E/qS+HyR9pfOv2jbOYbW/kzbDkitIIe+HEU/j6wbJbW8elxr BHIGfjLjl/gE4ZLEE04Q2rsp4WE0adgcRS4mNLfSqjqMWi7XGo7nfrTwsDD0iW0llyH5XSTrxEYX E438/o5dIZllflHpS1gS+6MiBy2xSUbTzeUh0U7jKslEpphEzHuWXneNy7PZAbRwEXKh+F2SY3F5 2nktbM/Vc4lGC+ReYumdo1Ym8nksc/EwGXki+r1EYzv6CmjOUjoFzQG8TUHTBMtTQrviMF4uD2l/ O/ryd9pwmExwmTxVem1PAYeIEuMORzNS57CP46EG12pIaSb5cxh9faFd32VcWidshEfIgd143uni n4iGtLw5fTlMrEqgLwK7Yjkgcd1LzItL5N4ZMsFZStzKimxz+wyZLDb3wclo7sIylWulYrmDWrnY zIArKW2fmL9Zti8hbV5BHz9HnwY/oT0POkv6O8j1WixtFvHUmowKE1GdT1YTDYmM9yCeX2EdWE/0 NiauJX6yGKkSbqWiVh61NmIZJ9szsVxBZqaIHGaoq8m0NYy4tH+Wm9GJOSLeujNG5eD9tPBkYsUr xV4jV9memLPTbel7bi6LN7tavkKrsqjl1lXxPJanxHmqD3nVR/b0/I5WvpOsO4EN64Bx82giddvr v5D5axhN6eMGtzZi+ST6zkR+qtCuS2tYK2RVcSOyCCZRmk6vm9HfQ3ASvITn5ozXLTADtknYyCo3 KjGOsrK9LGumzYc1zKaFZMUlPsm9RK5eIp8vMRYiXyBuoxO7WCk00usZ9LSR28VYc/IYnbXCGFkU Y5cxx7HsA9nj1GnJQ3sP/A1r4BnWQFlhOtPOhmRpJjm8k6xmLbKW87EU+3fRD8CyFXJb9Ato+V7k JehbxvfAHGbfGbknl6vEp+d/y3h1ktnKmN5GvzLcvhb/M5/XF5fW0vIx9CUdy05x7nmom6bKWp+p iZG18uWl4lkpfudN+fJ3OoknjUJVCH0h0Sslmvg98i3reDf5JnycvweJF0KuhVwLubZ8TzteR75L b/U56Bcj95Dvj8k38628GTkP+aTI8lc8tu5q+ZUb9HXk24DWzzv8NsvP/L7NWqH8HYFS8nfu8RT5 a454ivw9SHx5OEB+5Sb2lPzKjciX14kcHxO+KL9yEzst/sMjwtgp5K/Ff+w48q/IzqYjrI1lT9hH fvdG2nb5sGtz+Cr285FdrRO0+Rz6cuiLCmO30Lsa8BT9HUvpChhDfyOWzbjWSfTb8JmFpiGRcZqL lN6D/QSuuI0oXYRPcvWmWFalrlhmImciZ4Vb0V9Aroofp69AS+5Erox8N372CZNiyPyST1ISpfeg GY+3VfIbOHi4EQ+1kGsh15a/l7f2u5BLwOLUakGbs2hzL0Z5Nj39mVLaFr6FpgfcDM9Rep1lzdi7 yO/hcz3yRGw+gC+jX4G8G/mstFB+hcO2VvKwNp/Lm8v5yMRNPkmP17r8D2nPZcZCPnm3mjNSenmd RNJp4k/CdEgtPNS6vAlL6l6m15dnIx/B55+R9yLnUUpGXf4KzTH8yDdwlCrkjUs6oUzvxwcPUCkP DO77sBo1oOfQQWq5sie/Ozo1S1f2ZJGfr4qrZBWqNHWDKqZqqLqqgbpFtVF3qXutj47qCfWU6q0e Uo+oR9VzCfsiKqbKqHLqWlVT1bNemqq2qqu6z161kxqpxtiVo7/KUcPUOP6PQVcnUkl2zSivUlSm ulHdpJrZ1flu1UNpdYf6k3pa9VUPqz+qx9R4VUKZ1h06tFJtOt1+W7rq1blT23Q1HS/X8Zuhf7Br cwXrsZZqpG5V2eo21U3dr4yqojqrUWqs6qcGqMFquJpAnatUuqqoZKe7WTVX7VVV9Tz6kqqojcP1 KlVVsn5rq/qqsWqhWqnb1T2qp213NdVFPameUQ+ogWqIelxNTLTgGlVYZajSqrL1UEc1US1Va9VB dVe9VKCqqzvVaPWselANUkPVCPkt095ZQ3qbO+F9sB8cBIfBUb17DhhqnoWT4Qy4AC6DK3v3HNLX bIRb4Q64Bx6Ah3v3HphjjsJzQl/DorAsrAYb9hnw0AN+S9gOduoz6JGBfld4H+wD+8McOAyO7De4 Z29/DJwIX4Hz4GK4Aq63jnv6W+EOuAceGDDo0YH+YXgUnoRn4AUYFwb+gEd6DwgKwaKwJCxrCwcH 5WAVmAnrwUawGWz1iPhpDzvDbvB+2A8OgIMfGdxnUDAcjoJjc0Q/AU6Gr8BZcD5cBJcNsWMUrICr 4Ua4Fe6Ae4c8NKhfcBB+C4/DPHgOXhwysHdOqGAhmALLwkowa8iQzFphI9gctoOdYXfYxzIrHACH wpFwLJwIp1rWDmfBBXAJXAHXwk2WdcLtcDfcDw/BI/DEkEd7DQlPw/PwkjCmYRKMhjyaMySWAlNh OqwAq8GsoTaSsfqwMWwO28AO8E4od+Parj0p/8GrsfO8tEr7/5I8fjj0/83ArhiBXUVjKun/7J3P Oyd7dtUryCK/k8auc4X5zeX/jeTZ1ft/ZrHfTc2IaOtV3vG0R/YHuUv83bzmd7PMf2PR3810Wmp4 9X5D6cFvddG/pbE7VQlV8j+UrkPSdn/K+I9eb1Dl/qPX8qrCf/Dq2Z303/Pfx8SzO/i/59W/i7Xs 3cZQu+tPVQvUCrVJ7VFH1DnP91K8cl4dr7nX2evjDfXGelO9Bd4Kb5O3xzvindO+Lqvb6RF6gp6h F+vVeps+oE/oi6aQSTVVTEPTxnQz/c0IM8HMMIvtHJRrJbmcNe0LvO9V4P3EAu8n/ea9X6A8tNN8 v4p5v3lfqM6V75PnX1k/On+l/5RuV74vrq70XzylwPsKBexbFXjfvcD7Av0pfuDK9yUqFXjfocD7 4Ve2P23eleVl1l75vny1Au9r/Oa9nX/lMwuUj+G9tutDMdfDih3cayXXc9/mXAm7VlVIaHcmXg8k Xo8kXk//T9ZVlide1yZecxOvu69sRdXoyl5WXX3l+5pjrrSvefDK97W2X/k+66MC71de+b525wLv 7yzwPqfA+8EF3r/ymyyzQr3pBd6vvtK+XoFR+m/lOwq831ng/e4rR7HBDsvIRqa3N03182ax2vay /5SdqVOVFxQNrmGvKKbC5NZRbnKraFO0IdpoNaH3o/ejtTvtnVaed8Y7o7T3s/ezMlHTqKnyo1uj W+2+KfmgTQvTSq6ni+niViN/QRRJe0wRW7OGfV/CnkYGq1kqVx1WF70U24Yk26qU5I5KJ7dK7mTZ OvkOyza29UXtmpxuTwuZ9szTKDqujC5q2/QPXnMje9LSxe37H3jNjfYqbd/tt8yNDlhutX2VDE1V GdFh29YNtvTvvOZG39rXjfb9d7zm/sbySMLy+4Tl0YTlsYTlv9rblva2o7230d5/lbSn5HZKOvy2 JNpGC7fTwh208F8lOynZTckeSrSKafvPTrPCWr65XVQXtVEtbqNqklsmZ9uob4g2qNC2aaONlLEW 8mmk2/Xt1LL1ezJeipHyvIveRTtq+V6+jVag7X0PfgP8hviN6VSdqpJ0hs5QV+lKupIqZFrZ0Swc 9Ap6qeSgT9BHFQn6Bf1UFDwYPKiuDgYHg1XRYGgwVF0TDAuGqWJRepSuro0yogzbp3JROVU8qhBV UCWiSpE980VVoiqqZFQtqqZKRTWiGio1yowy+V3u2iotqhvVVWWiG6MbVdmoQdRA/SG6KbpJpUc3 Rzer66MmURM7OpJvN5Bv5aLsKFuVj+6N7lUVot5Rb1Ux6hv1VZWiB6IHVOVoQDRAVYkGRYPsQpET 5ahq0dBoqKoeDYuGqRrR8Gi4qhmNikapzGh0NFrVisZGY1VW9Fz0nKodjY/GqzrRxGiiqhtNiiap etGUaIq6MXo5elnVj6ZF01SD6NXoVdUwei16Td0UzYxm2vycHc1WN0dzo7mqcfR69LpqEr0RvaFu id6M3lRNo4XRQtUsejt6W90avRO9o5pHS6OlqkX0XvSeahktj5ar7GhFtEK1ij6KPlKto5XRStUm Wh2tVm2jddE61Y7xvo3xbm9zZZO63eZKruoQbbXZ0jHaZrOrU7TdZtcd0Q6bXZ2jnTarukS7bVbd Ge2xWXVXtNfOka7RfjtH7o4O2DnSLToUHVL38JvY3aNT0Sl1b/RT9JO6LzobnVU9op+jn5X8zvcY Oz/G2Ey62rtaPemlemXUaP5n1LFeN6+7esYb4A1U4/jfUCd4f/SGque9Cd4E9aI33XtNTfZ+8n5S L3nnvfPqZe9X71c1VRYZNU2HOlSv6GSdrF7V1+hr1HRdQpdQr+nSurSaoW/QN6iZurKurGbpTN1B zdZD9aNqvX5MP6Y22PuIEepT/Sc9Sm3UY/VYtUk/p59Tm/VUPVXl6lf1q2qLXqD3qa2miF1/Lpk6 po6Km2amuco3rU1rT5vZZrZn/KH+654f9A56e1lB36CvV/u/2PsK+CqO7u2R3Tv3rkxCEiCEIMGD 3iAhuFPcvUAhaHAJpFA0xQuFYoUggeDuhBYN7u7B3d0h4X/2sNDwln5vv1c/aeaXOXN39+7d85wz 5zwza2obtQ3Nr4apYbSA2l3tToPVHmoPWlCNUCNoiHrMMYwW0mprzelDbahOaaLhaZRjvYyvjels mdnSbMeemv3NkeyNZNLJnTJABnAPmVFm5J4ys8zMk8msMiv3koEykHvLHDIH95G5ZC6eXOaReXgK GSSDeEqZX+bnvjJYBvNUMkSGcD9ZWBbmqWVRWZT7y+KyOE8jS8qSPK0sLUvzdLKsLMvTywqyAg+Q TWVTnsF6OTXPKFvL1jyTbCvb8syyo+zIs8jOsjPPKrvKrjyb7CF78EAZISN4dtlL9uI5ZH/Zn+eU A+VAnksOloN5bjlMDuN55Ag5grvlKDmKB8nRcjTPK8fKsTyfHC/H8/xyopzIC8hJchIPllEyiheU U+VUHiKny+m8kJwhZ/DCMkbG8CJytpzNi8q5ci4vJufL+by4XCgX8hJysVzMS8qlcikvJVfIFby0 XCVX8TJyjVzDy8pYGcvLyV/kL7y8XC/X86/kJrmJV5BxMo5XlNvkNl5J7pA7eGW5S+7iVeQeuYdX lfvkPl5NHpAHeHV5SB7iNeQReYTXlMfkMV5LnpAneG15Sp7ideQZeYbXlfEynteTF+VFXl/el/d5 A/lIPuIN5RP5hDeSz+Qz/rV8IV/yxvZYymI++THWBoI7q7QJbQKLW9FWhCqxSixhjgRHAuHO4s7i 0Hv+NdEYPPevaPz/eTT+zfv80PuyW2yLhjni//Kxv3zsX+RjVG0HfN6TZmD5eXmlAfEnhUlpUonU Io1gvNAO+Htv4AMjyFgSRWLIQrKS/Eq2kr3kKDlLrpA75Akwe0Id1HB9S7iruyvc1QtlD1dvlD1d 36GMcPUFGQ6tfijDXf1R9nANQNnTNRBlhOt7kD1gu0Eow12DUfZwDUHZ0zUUZYRrOMiesN0IlOGu H1D2cI1E2dM1CmWEazTICNhuDMpw108oe7jGouzpGocywtWHMFgbCXUP1zCoe7p+hDrin0BkAmre 3TXRRuZnG5lJNjKTbWSibGSm2IhMtRGZZiMSbSMyw0Zkpo1IjI3ILBuROTYic21E5tmIzLcRWWAj sshGZLGNyBIbkaU2IstsRMaD/t1d0xGR2YjIwn8SkRU2IittRFbZiKy2EVljIxJrI7LO9pVfbGR+ tZFZbyOzwUZmo43MJhuRzTYicTYiW21EttmIbLcR2WEjsstGZLeNyB4bkb02IvtsRJYjImvRU7Yg Ijv/SUQO2IgctBE5ZCNy2EbkiI3IMRuR4zYiJ2xETtqInLIROWMjctZGJN72lXM2MudtZC7YyFy0 kblkI3PZRuSqjcg1G5HrNiI3bERu2ojsR0SOIiKn0VOu/JOI3LYRuWMjctdG5J6NyH0bkYc2Io9s RB7biDyxEXlqI/LcRuSFjchLG5FXNiKvbUTe2oi8sxFJsBFJtH3l/QdkNPIBGY1+QEZjH5DRuI3M LUTkASLyDBF5Y3mK9Z5G67hxNq0BCaRHWTSvwqvz1rwNb8fb8+68B4/gvXhfPowP5yP4D3wkHwVj lyv8Kr/Gr/Mb/Ca/xW/zO/wuv8fv8wf8IX/EH/Mn/Cl/xp+bwdZ7lOhhehh+YLp1dy6vzCsTxqvx aoTzlrwVUXhbHkYcvBvvRpw8nIcTF+/JewIT+JZ/S3Teh/chBu/Hvycmn8KnEG/+Kz9AfMwCZgGc ZfAjmpJWSaekVwKUDEpGJZOSWcmiZLU0gyN6jrPrlPgmmZvIgfNBHawt4JtZ7S38k2yRM8k6QJJ3 gK2J4qNYzwLLpmQjuv27PkpyJYWSUvFVUil+1rPvYIvffpeRTMRD8VK8FVVxKEJxKi5FU3TFUExF Kh6Kp2LNdymgW384BOs7TCmmFCeGUkopRSSsCya+fC6fzxfzZXw738F38l18N9/D9/J9fD8/8CXE rdkyPofPgT3Os+5r5ov4IsB7KYc4Cshtg9+7wu9+2vsc2GoRrP2Vr+cb+Ea+iW/mW3gc38q3fcnG uPe5fC7sfT6fb12RyRfD3pdxiM5whAdg75Ye1t5zE58v7vULeiBmV2zMrO/9Se/C71neAN9TO7HV 5HsyiAwmQ8hQMowMh379AxmJbxcdTcaQn6CXjyPjyQQykfxMJpHJ0OenkKlkGplOoskMMhMiwCwy m8whc8k8Mp8sgHiwiCwmS8hSsowsJysgOqwiq8kaspbEknXkF4gV68kGspFsIpvJFhIHkWMb2U52 kJ1kF9lN9kAc2Uf2kwPkIDlEDpMjEFWOkePkBDlJTpHT5AzEmHhyjpwnF8hFcolchohzlVwj18kN cpPcIrch/twl98h98oA8JI/IY4hGT8kz8py8IC/JK/KavCFvyTuSQBLJe3BoymqyWqw2q8Pqsnqs PmvAGrJG7GvWmDVhTdk3rBlrzkJZC9aStWKtWRvWloWxdqw968A6sk6sM+vCurIZ7DQ7w86yeHaO nWcX2EV2iV1mV9hVdo1dZzfYTXaL3WZ32F12j2vsPnvAdfaQPWKP2RP2lD1jz9kL9pK9Yq/ZG/aW vWMJLJG9hxBkXW3PucJV7uCCO7mL1+S1eG1ehzfmTXgz3px35F35ID6YD+FD+Tg+mU/ly/kKvoqv 5uv4L/wgP8QP8yP8KD/Gj/MT/CQ/xU/zM/wsj+fn+Hl+gV/kl/hlpYhS1Hpvq3JcOaGcVE4pp5Uz ylklXjmnnFcuKBeVS8pl5YpyVbmmXFduKDeVW8pt5Y5yV7mn3FceKA+VR8pj5YnyVHmmPFdeKC+V V8pr5Y3yVnmnJCiJynvVVL1EKVFalBFlRTlRXnwlKoiKopKoLKqIqqKaqC5qiJqilqgt6oi6op6o LxqIhqKR+Fo0Fk1EU/GNaCaai1DRAkorKG2ghIl2or3oIDqKTqKz6CK6im6iuwgXPURPESG+Fb1E byh9RF/RT/QXA8RAESm+F4PEYDFEDBXDxHAxQvwgRopR4kcxWowRP4mxYpwYLyaIieJnMUlMFlFi ipgqponpIlrMEDNFjJglZotFYrFYIpaKZWK5WCFWilVitVgj1lrvfhW/iF/FerFBbBSbxGaxRcSJ rWKb2C52iJ1il9gt9oi9Yp/YLw6Ig+KQOCyOiKPimDguToiT4pQ4Lc6IsyJenBPnxQVxUVwSl8UV cVVcE9fFDXFT3BK3xR1xV9wT98UD8VA8Eo/FE/FKvBZvxFvxTiSIRPHeSZxUzBFzxTwxXywQC8VT 8Uw8Fy/ES+1brZfWW/tO66P11fpp/bUB2kAtUvteG6QN1obo3+l99L56P72/PkAfqEfq3+uD9CH6 UH2YPlwfof+gj9RH6T/qo/UxepQ+RZ+qT9On69H6DH2mHqPP0mfrc/S5+jx9vr5AX6gv0pfoS/Vl +nJ9hb5SX6Wv1tfom/Utepy+Vd+mb9d36Dv1vfo+/YB+UD+kH9aP6Ef1Y/px/YR+Uj+tX9av6tf1 m/pt/a7+UH+sP9Wf6c/1F/pL/ZX+Wn+jv9Xf6Yn6e4MY1GAGNxRDNRzGVeOacd24Ydw0bhm3jTvG XeOecd94YDw0HhmPjSfGU+OZ8dx4Ybw0XhmvjTfGW+OdkWAkGu9NYlKTmdxUTNV0mMJ0mi5TM3XT ME1Tmh6mp5nM9DK9TR8zuZnCTGn6mqlMPzO16W+mMdOa6cz0ZoCZwcxoZjIzm1nMKeZUc5o53Yw2 Z5gzzRhzljnbnGPONeeZ8/HsM87I4sxofxbNIILifOdMXgny+wleFfL7Kd6If03O8Kb8GxKPOfQ8 78K7kAuQ8QaSi3wsH0uu8kl8ErmGmf065q0bmLduYt66hXnrNl/LY8kdzBD3lEJKYUpw3pSpmqpR t+qpetIgnBnN67jsuEFvCbfITx/gLOlTbag2hTFtjraZpdT2aK9YXpwrDcVZ0rmQ7Z8QF7CDDJDz qwEDioIMsAmiM/yEPpgwuQdbi7FlnaPxJCmIv74LPp/Sd0N9Rt8Ddby+/9O2p6AVR5zAJXxJWmAA 2T+cPdLPWMv1eKj36eehPqBfhPqQft/6pkxu7VGmsPYoU1p7xH0l4F4/nqNxwacdUoN6l9Q/W+OB azxxTbLP1vjimlS4xg/XMOICq7nBdiHMeltSEVaEMFaelSecVWQVicKqs+pE1cZp44hDi9ViidAe aY9gf0ydz478m3Ls5xn2/+38+p/JsFYO/bN589+ZM71ES9FatBXfQQayMmc5yJlVMJvVhMz0I+bJ BpAjrez4ITe2+pNZsc/fyYe/z4aTIQ/+lgGTZpf/07Lhp2wHeXES5O+kWbEUsA+Le3xgHhbvqAHM 47XNO94C62gIjGM6co5oYBxvwGvrgad+Y/nlx9zJOn6eNw1PI5nhZXgbPkZyI4WR0vA1Uhl+RmrD 30hjpDXSGemNACODkdHIZGQ2shhZjWxGoJH9i9l28JfzrXRJTep/Kusu/n3elR7SUyb7Xfbdpe/W 92AO3v/FLHwK8vAZPV4/r1/8mI9lCpkSc/L9P8zKCb/Py9JXppJ+/1B2/iw3Gwn/gexcjTKaHIay fjQb8aE1aB2SEc+UZqNNaSuSg7ahbUg+GkbDSH7annYkBWhn2puE0D50AilLo+g00pSuoYdIKOvG wklf1pP1JQNYfzaQDGPfs6HkBzacjSJj2Gg2lkzAc56T2UQG0R7H+NO5wb1INPfhPmQuT8Gzk3k8 J89DNvAgXpZswYx/HDP+CRy9nVRilEPkjppMTUZ91RfqC5pKfaW+on7qG/UNTe0AuKi/Y7hjFE3j GO0YRzM4Jjgm0ayOKMc0msMR7VhI8zgWO1bTIo61jp20rGO34zCt6zjpOEmbOs444uk3jvOOizQU uEECbeV4D9wgUgSLInSdKCZK0E3OQGd2GufM6cxDtzmDnEF0lzPYGUx3Ows5C9E91vkzutdZ0lmS 7nOWdpam+53lneXpAWdFZ0V60FnFWYUectZx1qGHnfWd9ekRZyNnI3rU+Y2zBT3mDHOG0dMuGPbT M1qo1oKe1Vppbek5rZ0WTi9pPbWe9C7k2Sn0HuTZzfQ55NlXNFFn+tdM6E303qy5EW1cYf3NUWYU 2/bh+hYYjS7FMy5NaGt7ydokSygpTBw298gCnCY/rJ8DxaqXAiuYg9L6tNH+tBE+nYdiXWWTg+YA r8lNc0O6C6EhsM+v6FeQXCrTykShk+gkvMpmN2mu+qmpVX81jZpWTaemVwPUDGpGNZOaWc2iZlWz qYFqdjWHmlPNpeZW86huNUjNq+ajx+hxeoKepKfoaXqGnqXx9Bw9Ty/Qi/QSvUyv0Kv0Gr1Ob9Cb 9Ba9Te/Qu/SewhWFv+Av+Sv+mr/hb/k7nsAT+ft/ZpkCqigMZxoUvFshGZ7N8oXCiT8UBZDLCprm JNZ1aXmgOAHVwsATi0LRSHEoOilLyhGDVIYiSX0oHqQhaQT8sCkUL9ISijdpC8WHdCfhJDnpRXqT lKQ/lFTQOxnxox7Uk6SGPupH0tC0NC1Ji9c0pIP+WoOkh/7aiATgWd0M2FMz0g60A8mEVzlkpj1o T5KF9qV9oU8Pp8NJIP2BjiTZ6Rg6huSEHhxFckEPXkNy0y00juShO+kuEkT30/0kH8435ceeF4yc uhLOOjXFWadmOBfml2QuLBdeTVWENQbE0rAgFgTMMZgFW/eIsbKwphKrBMyxFqsFzLE+q09U4D+t iAOYT3tgjsO0EcSpjdTGEF2bq80jntoCbTHx0k5qp0gK7Yx2jvhqF7WrwKn76P1IAGSRQSSTlSFI IGSImSSHFc9JHojnJ0kQRPHzpABE8oskGGL5VVIQ4vl1EgJjrJukEMT026QwxPW7pAjE9vtgq7/V JTfqUpG1A13SfqZLIVYI1lgacVYDxjQKaqSiRg7geY2IQL2cwOK6EhfqpaFeJurlhXr5aEu15aDR Sm0tSY06pkcdM2g3tdski3ZXewh6WZrmRk2DUNNg1DQE8uAcGCfMg9FGCdS6HGr9FeSnF6QyZKcE GKF8OPtq3eXYEjXKY+loPWmPFLZ1zGNvkw167xg68dMyRhfS5fDJ59N20AO+gEFRBrghEgraVkU8 HIiHQDyciIcLeG8ToiEqOlrbQGxMraHWkEgYmfcjHjD6Ggs2H69NIf4wBltLMmnrtM0kGEZiD0lx 7bH2irQCDjGUdAS2MIb0BnawmERC7l9DJkCuP0Omoc3Xoc1/gQx+mfyKll+Plt+Alt+Ilt+Elt+M lt8Cmf0hiYPs/phshQyfQLZBPneQg8BxfMlJ4DUB5AJwmezkBrASnTwAdpGMPIYc7wcjAIiEMELq Sog1giSlrVkGUtO62obU1r8zypGD8J00dPKf3g6fdvlv2vqTP5BQtKobfb5GEn9w/+YPpA4p/mkZ I+Xx3L3Pp+0Y4dpUbTb85hZtN/j4a93qObAUR/kfjiQAj8FtH+XHYy0M0ewfiO7wzeQYCwnGQoqx kGMsVDAWqhgLHRgLBcZCJ8ZCF8ZCDWOhjrHQwFgoMRZ6YCz0xFjohbHQG2OhD8bC5BgLU2IstO5t 3goaGKwC/5WU/LvnghjVqBccZQaanealhWlpWonWgqMLpe1oF9oT+FMkHUZ/pOPhV2fQuXQxXUnX 0U10O91LDwM25wCHW/QBfUbfQAJyMIN5MV+WlmVi2QHjYJodtM8GWORC2QgysCWb0EIom9LCKL+h RVA2o0VRNqfFUIbS4ihb0BIoW9KSKFvRUihb07Iow2h5lB0gq1uyM62OMkpNaUllreqLMlZNZUn5 1qlbUvV2GpZ0zHaaKDc6JcpNTg+UCU5PlInOZCjfO70sCQzKG2UJD4q/044GQjTyAK7B4FNOqBsB 47D4C8Qk0BI8EXQMgroZzQt1c5oP6lAKXAZ0KwB1SxoMdStaEOrWtLR1/QktA3V7Wg7qDsBZGGhV AeoutCLUXWklqLvRKlBH0apQT6XVoJ6i+hAG+iaHOla1Zl/eOsEwoCl4NeipQL3RCZwHdHRYV1Q5 BdSJTifU750uwkA3YGDOEiQQ+lZjyPkdINf3IYPISDKeTCWzyWKymmwg28l+cpycI9fIPYgv9jlF 8CRf8PVM4EtuGkyLgjdVoNVoHUCjGWjVgS4EtKIAoUUom9DFKJvSJSi/oUtRNqPLUIZCdLdkC7oC ZXO6EmVLugplK7oaZWtnGkuCjmktCVqmQ7nRmR7lJmcAygRnBpSJzowo3zszWRI0zoyyBJ2O9otG y81Ay81Ey8Wg5WahzWajzeagFeei5eah5eaj5RZY9nD6IOLJEfEUiHhKRNwXEU+FiPsh4qkRcX9E nBLFg+CV5RxjBcGeTj2s20SspwlXw+v6s5G8yANwNoymQF9LiT7ia/22tRea6lOrreVJVuyFeDIR fQVr6ywd9YQIRWhyGFdRjEQM44uVV33JcFqX1qcNaQNaj7bVGkAGbPRhbpr1YP3YMDaBR/EFfKV8 JxNkonwPUXaaNl2L1mZoM7UYbZY2GyJunLZV26Zt13ZoO7Vd2m75UjLJpSJV6ZBCOrXX2hvtrfZO S9AStfc6hD39J32sPk4fr0/QJ+o/65P0yfpaPVZfp/+i/6qv1zfoG/VN+ln9nH5Bv6Rf0a/pN/Rb +h39nv5Af6Q/MYThNFyGZuiGYZiGNDyMHEZOI5eR28hjuI0gI6+Rz8hvFDCCjYJGiFHIKGwUMYoa xYziRgmjpFHKKG2UMcoa5aQhTSmll/SWPvKVfC3fyNTSX1rnQbPgyJPgaFMF1lUZclo71gGYQziM Kg3WF0aVJl43K3EM6YEjQ0+c/03GV/AVxMuxzLGceDtiHbEkueOl4yVwRhgvkZTWeAm41QXtOgm0 Rk3ApIYBfyisLwHmUAZG/GdIFRj1x5OqyB+qIX+ojvyhBvKHmsgfaiF/qI38oQ7yh7rIH+ohf6iP /KGBngjMoaHhCWwhFNlCX2QLA2RyYAvfg56/kkZ/xqL/mAX/LXb6aCEN0SSIpgtx9EIcUyOOmVDz XKh5MGpeEzWvgzyp/ofRp4pvG4R2JWLNLZcmaZP6/9968R/74wffgT0kQ08h6CkcLexAe0q0pwfa 0xPtmQzt6YX29EZ7+qA9k6M9U6A9U6I9fdGeqdCefmC3lCS1ffS6KpMcvQTOa/dYq8+jnxL0U4p+ ytBPuf1dQ/VI8l1fYCWfosDHno6RA3sBerKKnizQk50fRtL0MX1B39psIBlLwVKzjCyQV1RbqK3U NmqY2l3toUbIAJlRZpZZZaDMIXPJPDJI5pfBMkQWlkVlcVlSlpZlZQXZVLaUrWVb2VF2ll1lDxkh e8n+cqAcLIfJEXKUHC3HyvFyopwko+RUOV3OkDFytpwr58uFcrFcKlfIVXKNjJW/yPVyk4yT2+QO uUvukfvkAXlIHpHH5Al5Sp6R8fKivC8fySfymXzx150ef133+S+708MTOH9r1Vu+hZxf4k9d1w49 kbZznEtyFbLTukrn0zU+/4vrdD5d4QP7YMVY0yQzHdaSyhCBPs0X0GfkJXD0AiwEtigDy6qzmqwe a8gas5YQq7pA1OtrnVf7UrHOpSUtsJfPS8jvi3XmLWmxztN9sZT5m1LeOov3Wan++2Kd0UtaQJc/ KJAPPiug8+el4ZcK5I/PCqD0eWmK5bfPLf+mtIHS7g9Kly8VPfHzAlnr85Lqb0qGz4ut34fjxT38 NT/yB/MjlFyA/FkUcn0FYNl18FksH5/AYj2NZQQZQybC6CeGzCdLYfzzK9lCdsII6Cg5Dfi58Xzz /24d8g/V1f+R+ouzIB/mSAwQE61xDylljQUg16XA0YN1noXSQBhHM8j2E6A9kf4M7UnUeoP4dBh5 MbqGPrSeQksfw3jlCb6H4zl9Ae2X9DXmzLfQfkcTof2eWW9BYUwBn1OZA9qCWU9u1RmMv5mJ7xTx ZDDGZl7MB9rJWQpop7TeEQJ5NTW0/VkAtDMwGLmxTNbbRyDHBkI7O8sO7RwsB7RzspzEeqtKLmjn ZtbbgKawKdCeyqZCexqbBu3p/Ct8kmxFwnkl1dt6Vp0K+qp+ajnr6YrqV4SrFdTm1rPC1TBot7Pe TAy5OgLa31pPrVIHq4OhPUTdQqy3LMdBe6sTIrOTwSiSObO42hPq6uACpufqaC4g1FxowqjXXGTG QXuruQPaO4GpUpkWeAYHNvkeR3gQlT2YR8CH+6zRMoyE2ncH/8ZBKHIQihyEJrmLlSIHochBKHIQ ihyE4r0nFDkIRQ5CkYNQ5CAUOQhFDkKRg3w4QoZMhCITochEKDIRikyEIhOhyEQoMhGKTIQiE6HI RCgyEYpMhCITochEKDIRikyEIhOhyEQoMhGKTIQiE6HIRCgyEYpMhCITochEKDIRikyEIhOhyEQo MhGKTIQiE6HIRCgyEYpMhCITochEKDIRikyEIhOhyEQoMhGKTIQiE6HIRCgyEYpMhCITochEKDIR ikyEIhOhyEQoMhGKTIQiE6HIRCgyEYpMhCITochEKDIRikyEIhOhyEQoMhGKTIQiE6HIRCgyEYpM hCITochEKDIRikyEIhP5+IyST08sSd0dpA8uJanbuyNTt3G4sg+pMOSlSQWbEZm6ASyqwygN0t0u h5pDcuanEndzh5bDQRUaWZBRZUZtd013ziRL/GPSDvDHU0pFSXUSSrqTzhBEW5Fw+LdOMRV3ByTZ meKTVcyqHvI01/Dbpalv17sjzt4us/7wjMgU2d2Ripc7kr2ZwRllEBziyA9Fiw5LdqT4ixb3LpZ0 m5+OlCpwTF2CcrgDHbyuontnKNO5S69uYW3ahqfP1iIwfVChQgXTVw1r0a1z986tw9OX6dytS+6g tG7/Dxsn/3xN527Nw8M6dwoKcKez1nNv39/W1+rcOTx9qR7hbTt3Cwvv5U6b0ixU0B0U5HYXdMNf o5RmXndQ3nxB9sf/whFF0gxJYbHeVBUJYQWWayySUrKAbYzrcqPIk2qps0X//G1T952YBaMyf/Mq cUKVWbGJ02LSF+9TM2ZKzOhmedsfKd2y14PFPffUOfvk7tQh/qOjB7VetaN979CMJ9MUveBBx96a uH1zrtZRUW2zTD5cOOdmY02DLHHlb2rFQybmXJCt0Px7Fb8vfXWQx/qoDnWbL47sM7NZrogqtyev blkkqoZ/kDOTT/SCmz/l8L1RbFILn2YN1FbRaQrWGvpy3sPxbGfqY5vrlls1fMDmwvfqjK+2NGFe 747h1Zb57p/oyhZA6o9pFlZwfWUvUbTe+6/fzm6tOeceHViv/sO1RZqmGBihnH2xaemACYnLD/Q/ Oc+vW+Oiezc8cs7K4F7lGLxnVfoI78EXGQfHnzVwvnvgHPfAGEAzDVUGRrkH/jzA8+vDXR6GdZue sWY/n5VVf3y/b2a3/7z9Iv+Oj3PLhhNu6VtGPf3Zt8D9dTTT6YhkTxs3yxs9Xd9XXP1p2Og9hW8E PHlUf1zONTO+2h368N2p/UWKNFoQXCcsMVPHEnv2L7yg9jkfNKpYtGeXdusTvar7hm15d7jM1WSN 0le/E/rdsoWpducomDnXplYzvUZk9mgx62Ud/9cBe04mf1prcacyeUVCZMpX19t0MGu+2Pi41q6N N7e736UPcg1LMyHQr+qJNGzO4wGX+Oqvn604v7v+g1YVd9Wqs3Y1z+b1fszJR87R/db9vGNRwZzX el+bH3G15wxyuF2JuKPBIy6V8ppfoF3qdvEFLh/3V67NL6fsbpQvpFNVfzM0VosZeexEnRLlD/jX ndsl3qvw0HE9oucdnQFRoZk7klf5EBW03IuSnavxvvG0fVs+xpQ0/61gAP0+JC/8QQTIC8EgKC98 LPAxGPTCCAo7cXizurWDvN3JrA9Ob61+8+5twzq1CYef8XRLa6HwFrVatezYuVPLjwem/dGBZXQH fDgwv6TrW7ZKXzusTSfYa/oaZUr93agQ26vvySaryhWan39x0NnXmQtUjNjyNt30XeW6PjxS/tbx kdvaV6kV+mwy21b1dMUOeTIVb7X5YMZYvUJs/x7ny21cOFrW2JE5x5MZN82M6Y6UyvQmdPKhVOXm jKuUbvKBVXkybKuUq0/nM8nTFhlZyLPQ+Y2Bz1oXyUXzvk/MWmHumg506NS3v65s0T/ydeMZAwcN /nH5k3XjZx0KmVtjcMqsQ6udd78gxZ7tfF1s4KYh9zsUmpc7/4vVuZdpfUN/+rb11EndzSHLnmx/ mv6X6l6jWuzLeSZvuVQP1leaWKRGbd+DrWv2Wrhk6O56xaMjawzrpK4oEPddpo21WhebXG1/jn75 Og36ynFk+uFKQ1inIWT2lqEXa9tR4Y174Eu3txUUMiuGW3M4IaGpquD8/45Q4WEdo7f12knVzUG4 01gLpJJC8dmf5mBP0uXrZY/Pbq8WVbNs7lllWzxy69ZqD0WBbjQkSdfBGPPdoqX9KmV5cnBDtfCY BlnDs/dYNSRhUZXx35Kqt/fe9T0XtkPG9HnKyuzcO3T/q9r7t0ZvrNf5UYuyC8qSBxN3R53wX6dH pzLHnzqbdklg34f353ZfPPpCoR+LTWq3IaTj0WHLMiZcvH0yzPXTsI2Jl8n6/E9f9nnt6ZVbvRs4 cVzp9tm6xoaMviTMPU3aHtg4oFT71vPXx67/Mf/eJ9yzT+/nRy+Vvvhd4uXLixNfXDxhrupycuzV 6mtDYvrkOl4sPr8eWpBFD2yXcfiLxi1GL2+0vtCpZiPrDvLL97zIpBmRRsw3P6zKGTtzzr5FZ9Ov 3exONTi9j5l9Q61npS41dV8dmy1saFyXK0/nLTo4oHS3nhJiTDuIMbXsGNPc49uqyJB40n6kQpz5 L/bqjwEnn9sNEScfBBx3IXde62M+66M7/N9yaPZ6/gfr/26siYnXRh3aGldxyoGFhfMvydiwfXyH TQEZYsfvvrN0884TWbbmTfbDhrNNcr4Nrpc2eY6lo83zPrM6ZavSP0WJUotHlVxRfph5ZuD4JT87 Dtcv27Pxncfv5JX+4bPy7Qu//vBq85n9eGy59yeKe51Yvrepefi7J7He5rtm7bIN7jEydsmGwbdS rh6z6XmKtaFN7ie7WPhBwNc/LBvQfVu5qxOGRzSbcnNJRFzBUfl88njHh+5Z6reg+qQ2S46nL+Tu emlUm/JXdvo/M2uEl8pzS83ULqB9xeVjt68stKv0nI6NfSstGn3qx++Lf6t9dXr2ykEZt1158l3r FZXCN2YpVXlqc59m1dy7I58e1rv0eVC3asRRZ92eA+1Y88o98Dlin8bD6rHQCR1bknTYpwElf+xT 81WdypP+p1ozj4dq/eP4GDMhkq1sZSdZz4yxjGUQM4RQMxfdKIxtxJiYxr4OSrZIuebioqKSIcQk 7sgtS1fmqqtQWetmF5Kt8hvduqnc1/3jt/T6/Xe+z3Oe5Zzn+7y/z+d7znPRR75UBFRDaWRjNK1x Yqc8RAzYHrPxNjdfu0EaYgQYAMgC3QLtRC0fMpmkr6mJD/TT8P+4hhr4AH9N0lHCWqkmKTDA4zie HKRphmU7mga7CLD8OCT7HGII6AN6H20AnKj2ocPg4OCNOvQMXNcT+YsN9J42Jo4BWO98GSqCg/8P UWvDsvHu2OipLaHkYLtsC7E50DZC1GP300VvvQtznynvXv7uUc47e+ZhnqobxZNxcz9IBRxcnp8Z 5HuQzI3aLirT2XgdbcGt5OrIY531kru9bh/x5ZClkLJ2smxg/5GacoKQQtbUKILncRQxIHPzgbsq NnuvwNUSRwrbXZTq6w0HDlVSeeu0d9jFoy1Wb2YVHuS6fO5pSINj9MUS2/bZslya6dCvzgqoJ9EI C9vXrNbwvPGatly8CLa8jDb9iMkqKCw9ezdM9YRaY0vPGz/OXqZe2Uyns7jo1saFuzHFAtwST0/L v6gotEGNVQgqhfDfUrtx4WhLuiGbNnls2iR8pM3eiMn3tIF+O9rgCP6eQWQ3f9J62ugASJgOANPW hr8/3sDem3BgzQRii/8rc9sFKP4ZKKWIZgSSj2egjDkWLYPG2urDAHM9dW09hK662R6M3scbOYWl /uYhsJ6BFALe8x8BNVYHxbf2hNLjzVEXq25P2uQr9CMpUjwP4VZOIfdVey5ynZ5+YbTSoBRxfuV5 ZBSc1WOUjNSdXew2QGz/PTNuBTHhkxAokT7AsBlgJMxpbQbfKqIEadu4zNQOWkXuZGSFPF6VSti2 B3OsI3qXo1An1c6Atdz3OnnSGDTc1ee2JJpqfSHWcJ5gMjaYxOSyqyOHj/I9txgr9Zvp8o7lXtx+ N1L4ZtAQj82y+8pkAZKm/25csNVNyt2pezOO2mVgbT30XYOmq0RaJtSs12U8brN8Nk8BFOaZfMZW ylS2KPP0W7Q5OkD7Glq3jHDZcwlhdk20yQA5KJAyK3FiGGcvbZAHK1sPqE9Aigp8qWHssHtAccGH wfHGejCKNYz6jD0BI7bG2TcQpdaJ6fW5Y1cNTM2af/u32EMOIuHd/iPs+dgTeSOCcn9F4Q0ARQiL 4+Hb3tnHwiRpMDsRYbHRu5RNVeYeyGbyZ5cdwR7evTR5C2d1KXJB+DdekaV9s4nbQMRh6k5ldIka Ev40gKb7/ZT8gXQcZ6pxSa6H3mudVhGzGn3UD21bfjkWqzznVQIbcnZJXzpwYNB5/MzpPAKPTVJn J8UGscV3MMK8RPUQFReNVhBXvH0Kc0dxWDyGsFvktWjzSzm1WMxh1VdLxc3BKPmApWKPhLQi9y2X 1aUuPT+Nil6tSHuTPTHzFlJ+b2/H9+Sry3PC0pLIjvPVD+tfVU+1ls06SK0YzrQ+VDGvZ+YaR3qJ 3auUwW++a2LkCRePqGQY3VKytJUTzyGmALdmMj4HlIAvb45dI0ixVPAxWtopzLvoS0x9G/H1gU4A AqG7Rick2/wG4usrcP4Tb57oElfKW/dYHRNr7bBEYRuXS0Xq1OA3hewOtFInUVo9e2GZyjUZHgPS 9vF1Tdad0dDF6eM/J7dc6qITSF4hu7xGamqnE27cm7ryVugC70G53Zoskx4HiCTlur+HvxXu8dOZ PuZP1JaY/mgbsG7WfGM+t4OUj8W9nkaKs2ZkjSKk2uGQ7w78akyE4VQXRHEfMpjM5dLk3J2oq3a8 jX9MCskTQXmX50cMG5hApWfnH+M/omIn5u4Kz79PtVWVc/ZBJ/dpxgvYVy5dl0j1m1L8UXjxV4FH Cfyv4ihBOs1nw4raXTdNQCsStWoXsw7Fm8Y7JWQRK6TVLNsDcs0GfEeildKO/smbOA5l9htR2HiH /l/IL4FNPB8SoNs41jQVaB09N4Sj+F8NRMAQPqnNICzoOMgdZAYy/VyafaXrNgBU1j5BWFOE/U3B tEI3Lg7+FBI6dToI12DMA1VfZezHJuyYRGbUnnfg7UupMZDsXLla0lZ7bb+sZAA3IeooZ5EcZtKv 2j9CjoF5ED+XuvVnrlM6t8ajRkku6J8y77d3PE1rHGSq3IuYaKPDu07c+BV/W6dTTJZJ6TOgVUkG 5cue7K6uFsKlvMpt8rSiKSvlup7aatAi7BlieZNVRtW3q3B36gNGR5E7h5Nme5GxS8KyKR4x+E2Q c7M0sJlmOOZk3Sq4x3PJqq+Xk3ymCkrka897ouwWYTkjmisoqwfeceLqpjvn4IznJs1Yo4bLSX0j Xrqpr+TO5bZXBOP26z8MNK+Ufw2Lg5SzIVUK5uAAYk98Q1X2mVb8lOMuiO0FRP5ab2UOGBcn9P3f y2te8GExeThhfOvT6uzZfLJ4YfzA+tptgPynhhAY28cW0q24Yq0z+q5z0+wrkphvle0yrgMe65rw wRwAXIFKjDJoH4gAwoMCQQHvM/NeIDJIBoQDhYJIbMubXe7GvvIBhRYqxSj8bXglh5ICvAPdSD6h Ml/gDRLHAZJh/sE4KA7SF6FJnNzXMXe2IveMSdEYv5YjZEovCPPmzTV6zvQAMBx1an78FWf4fJfz 0jw5L4aXWNVL1+QkQkhjnA9fiyapN8af1b3IQsW7OPKHtnWLdzPfaiXnP6mSKarFjN+I+mmyvBHV PMY07+80rV8cFRE/ZT1zhgPNOqLFlxxNTzlvltr6xnYVX5b5yz3Yru+Cql1rMyALbVsodMsQOpgW c5eegdBRav7Dg68gDdzmLx1Jj3LQvv1AOKJyj9zZHFaYLYlynq56R+5FWNAjl4L0wmlHOxhYVYBi vpyF2eGeJRyeHvEsXn7g/I+2upBmG68rIxd7LzrJRyYBndIihXFgaSAOLPlpjTbB4sB87CLu/7mL fhmRPhMYXB9ctMAFEFvvibyfvgJxsMf8qwYK28oOtXowAM4OtHCklvb3XzkieFWBv7/GLdVF4whw Ei0xXz4wsfgFs9ZcpD/7Fytu9X5Gm2Rxjyy0hW/CK1FhdQ+YZfayobVQhnJuqH7wTJqQyZCSSlFx RrJbithSu8o1e4kTi+EZY9g7JiM31V3SO8wzPYgOrop7eFsSwTGmU3I54XfgYfZTfiefLeuIzjcn Z7rvxNF+fy4sVPgwj76w6qjPaTHaNeU054Uy9bY+XPtzQ0+C+jNHRmtGqfsxX+MSYe4mlmr78b6c U6EhJGoZhtZURU2ytdBXpWJl4ZfejbUYkyngRvqVQKwLw6clahxm5EPbFTNXvanixQOGoFrcfT9m ef+xyhGq+6UaDgrQy2+CrTwEnVuo1vGAYmW3JXtjiAK+/geFDxCrt4D+BX0uJAgNCmVuZHN0cmVh bQ0KZW5kb2JqDQo1NSAwIG9iag0KPDwvVHlwZS9YUmVmL1NpemUgNTUvV1sgMSA0IDJdIC9Sb290 IDEgMCBSL0luZm8gNTAgMCBSL0lEWzwzOEVBNDA3M0IyNjEyMTQzQThBQTgxNTE2RkZDQkI1RD48 MzhFQTQwNzNCMjYxMjE0M0E4QUE4MTUxNkZGQ0JCNUQ+XSAvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl bmd0aCAxNjA+Pg0Kc3RyZWFtDQp4nDXQSQ4BURDG8Xo02tizeUxbkHYkC3tncBortvYSXMABHENi 2V7Xn7eoXyqpr5J6IvblubE1ECk4wEMxd8W7Kv5eCXZK6MJHiW5KTC4lkL6V5UukZHcmMoYJTGEE v5GZDazW/85ACcrgQAWqUIM2uNCEOjSgBR3wwIc5BBBCBDEk0IUe9GEACxjaUzJHvyB7KptLgTlt lfNR5AucKBWTDQplbmRzdHJlYW0NCmVuZG9iag0KeHJlZg0KMCA1Ng0KMDAwMDAwMDAxNSA2NTUz NSBmDQowMDAwMDAwMDE3IDAwMDAwIG4NCjAwMDAwMDAxMjUgMDAwMDAgbg0KMDAwMDAwMDE5NSAw MDAwMCBuDQowMDAwMDAwNDUwIDAwMDAwIG4NCjAwMDAwMDQwMzAgMDAwMDAgbg0KMDAwMDAwNDIw MyAwMDAwMCBuDQowMDAwMDA0NDQ4IDAwMDAwIG4NCjAwMDAwMDQ2MTYgMDAwMDAgbg0KMDAwMDAw NDg1NSAwMDAwMCBuDQowMDAwMDA1MDU3IDAwMDAwIG4NCjAwMDAwMDUzMTUgMDAwMDAgbg0KMDAw MDAwOTE1MCAwMDAwMCBuDQowMDAwMDA5MjA0IDAwMDAwIG4NCjAwMDAwMDk0MzYgMDAwMDAgbg0K MDAwMDAwMDAxNiA2NTUzNSBmDQowMDAwMDAwMDE3IDY1NTM1IGYNCjAwMDAwMDAwMTggNjU1MzUg Zg0KMDAwMDAwMDAxOSA2NTUzNSBmDQowMDAwMDAwMDIwIDY1NTM1IGYNCjAwMDAwMDAwMjEgNjU1 MzUgZg0KMDAwMDAwMDAyMiA2NTUzNSBmDQowMDAwMDAwMDIzIDY1NTM1IGYNCjAwMDAwMDAwMjQg NjU1MzUgZg0KMDAwMDAwMDAyNSA2NTUzNSBmDQowMDAwMDAwMDI2IDY1NTM1IGYNCjAwMDAwMDAw MjcgNjU1MzUgZg0KMDAwMDAwMDAyOCA2NTUzNSBmDQowMDAwMDAwMDI5IDY1NTM1IGYNCjAwMDAw MDAwMzAgNjU1MzUgZg0KMDAwMDAwMDAzMSA2NTUzNSBmDQowMDAwMDAwMDMyIDY1NTM1IGYNCjAw MDAwMDAwMzMgNjU1MzUgZg0KMDAwMDAwMDAzNCA2NTUzNSBmDQowMDAwMDAwMDM1IDY1NTM1IGYN CjAwMDAwMDAwMzYgNjU1MzUgZg0KMDAwMDAwMDAzNyA2NTUzNSBmDQowMDAwMDAwMDM4IDY1NTM1 IGYNCjAwMDAwMDAwMzkgNjU1MzUgZg0KMDAwMDAwMDA0MCA2NTUzNSBmDQowMDAwMDAwMDQxIDY1 NTM1IGYNCjAwMDAwMDAwNDIgNjU1MzUgZg0KMDAwMDAwMDA0MyA2NTUzNSBmDQowMDAwMDAwMDQ0 IDY1NTM1IGYNCjAwMDAwMDAwNDUgNjU1MzUgZg0KMDAwMDAwMDA0NiA2NTUzNSBmDQowMDAwMDAw MDQ3IDY1NTM1IGYNCjAwMDAwMDAwNDggNjU1MzUgZg0KMDAwMDAwMDA0OSA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMTEwMTIgMDAwMDAgbg0KMDAwMDAxMTIxNiAwMDAwMCBuDQow MDAwMDExNDQzIDAwMDAwIG4NCjAwMDAxMDg4OTIgMDAwMDAgbg0KMDAwMDEwOTIxOSAwMDAwMCBu DQowMDAwMjAwNDIzIDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgNTYvUm9vdCAxIDAgUi9JbmZv IDUwIDAgUi9JRFs8MzhFQTQwNzNCMjYxMjE0M0E4QUE4MTUxNkZGQ0JCNUQ+PDM4RUE0MDczQjI2 MTIxNDNBOEFBODE1MTZGRkNCQjVEPl0gPj4NCnN0YXJ0eHJlZg0KMjAwNzg0DQolJUVPRg0KeHJl Zg0KMCAwDQp0cmFpbGVyDQo8PC9TaXplIDU2L1Jvb3QgMSAwIFIvSW5mbyA1MCAwIFIvSURbPDM4 RUE0MDczQjI2MTIxNDNBOEFBODE1MTZGRkNCQjVEPjwzOEVBNDA3M0IyNjEyMTQzQThBQTgxNTE2 RkZDQkI1RD5dIC9QcmV2IDIwMDc4NC9YUmVmU3RtIDIwMDQyMz4+DQpzdGFydHhyZWYNCjIwMjA2 Mg0KJSVFT0Y= --Apple-Mail-114-88509320-- From simon@josefsson.org Tue Aug 21 23:34:59 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E2411E80D5 for ; Tue, 21 Aug 2012 23:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 VPIbuflmEiza for ; Tue, 21 Aug 2012 23:34:59 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1620811E80DE for ; Tue, 21 Aug 2012 23:34:58 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7M6YmbW023769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Aug 2012 08:34:49 +0200 From: Simon Josefsson To: William Mills References: <1345612319.55458.YahooMailNeo@web31807.mail.mud.yahoo.com> <1345613079.48024.YahooMailNeo@web31810.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120822:kitten@ietf.org::UB9x6waVwt0EzpwP:3FyQ X-Hashcash: 1:22:120822:wmills@yahoo-inc.com::KOlGUrco4gDB2+O3:60SF X-Hashcash: 1:22:120822:cantor.2@osu.edu::w8Ha50i/zj2bbsyG:6FbC X-Hashcash: 1:22:120822:nico103@gmail.com::tmAnVESJ/MnQv9LX:Eg90 Date: Wed, 22 Aug 2012 08:34:44 +0200 In-Reply-To: <1345613079.48024.YahooMailNeo@web31810.mail.mud.yahoo.com> (William Mills's message of "Tue, 21 Aug 2012 22:24:39 -0700 (PDT)") Message-ID: <87393ffn97.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" , Nico Williams Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 06:35:00 -0000 I suggest using a separate field for the username hint. /Simon William Mills writes: > We want the username passed in the SASL message somewhere. > > > > > >>________________________________ >> From: "Cantor, Scott" >>To: William Mills ; Nico Williams >>Cc: "kitten@ietf.org" ; Simon Josefsson >>Sent: Tuesday, August 21, 2012 10:18 PM >>Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt >> >>On 8/22/12 1:11 AM, "William Mills" wrote: >> >>>OK, so to do what I want the user field needs to go back in the SASL >>>message, and the gs2-header becomes optional and only present in a GS2 >>>message? >> >>The latter yes, you can find boilerplate text on this in my SAML-EC mech. >> >>I don't understand the reasoning behind specially handling the user field >>and would defer to Simon on that. >> >>-- Scott >> >> >> >> From simon@josefsson.org Wed Aug 22 00:26:40 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CE221F8462 for ; Wed, 22 Aug 2012 00:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 rYoIwhECli1k for ; Wed, 22 Aug 2012 00:26:39 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6692921F8466 for ; Wed, 22 Aug 2012 00:26:38 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7M7QTms026661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Aug 2012 09:26:30 +0200 From: Simon Josefsson To: Hannes Tschofenig References: <1345163301.61508.YahooMailNeo@web31805.mail.mud.yahoo.com> <588B67DC-7788-49DF-B303-753D4B420D3C@gmx.net> <1345482606.17400.YahooMailNeo@web31801.mail.mud.yahoo.com> <02D60FA0-45E3-4331-837A-E049029D919B@gmx.net> <1345531034.66639.YahooMailNeo@web31805.mail.mud.yahoo.com> <1345531945.23279.YahooMailNeo@web31804.mail.mud.yahoo.com> <24E6B416-8953-49A9-BDB1-73E8B482906D@gmx.net> <1345563667.23360.YahooMailNeo__20929.0090752349$1345563689$gmane$org@web31811.mail.mud.yahoo.com> <87boi4gioe.fsf@latte.josefsson.org> <6C4F4A39-D2E1-485F-9418-5B7D68C80AF6__25669.6146367633$1345613813$gmane$org@gmx.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120822:kitten@ietf.org::mO7uZsZ3gc/1MEF2:n5C X-Hashcash: 1:22:120822:tjs@psaux.com::fWQOQPHfuFjrA1ER:1UIh X-Hashcash: 1:22:120822:jz@yahoo-inc.com::xm3BFDx+wyR6DrUo:21pJ X-Hashcash: 1:22:120822:gyehuda@yahoo-inc.com::1zFNcb+0FKvqz5sL:AhLd X-Hashcash: 1:22:120822:hannes.tschofenig@gmx.net::k8wf2r2miaddjm4q:JJn1 Date: Wed, 22 Aug 2012 09:26:25 +0200 In-Reply-To: <6C4F4A39-D2E1-485F-9418-5B7D68C80AF6__25669.6146367633$1345613813$gmane$org@gmx.net> (Hannes Tschofenig's message of "Wed, 22 Aug 2012 08:36:33 +0300") Message-ID: <87k3wre6am.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" , Jiangang Zhang , Gil Yehuda , Tim Showalter Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 07:26:40 -0000 I have a preference for having at least two mechanisms, one for OAuth 1.x and one for OAuth 2.x. The terminology and semantic differences between OAuth 1.x and 2.x are motivation enough for me. I believe the SASL mechanism selection is the most reliable place to have negotiation in SASL, for better or worse. We have tried SASL mechanisms that contain their own negotiation, and it always seem to become too complex. Further, one could argue that OAuth 2.x with bearer and OAuth 2.x with MAC are so completely different beasts that they deserve separate SASL mechanism names, and I would not object to that. I'd feel more comfortable knowing that if I negotiated OAUTH2MAC I would get a keyed authentication, whereas I would feel less confident when selecting OAUTH2BEARER. If both bearer and MAC are negotiated through OAUTH2 I would have to poke into the details of that mechanism negotiation, and that is less reliable and more difficult to write security policies for. >From a standards point of view, having separate SASL mechanisms seems benefecial: the OAUTH1 mech would only normatively reference the OAuth 1.x document, and could then be reviwed in isolation. The OAUTH2 mech(s) would only normatively reference the OAuth 2.x documents. Currently, when both 1.x and 2.x are referenced, the terminology becomes muddy as it is not clear what is the authorative reference for each term. /Simon Hannes Tschofenig writes: > There is no doubt that the protocol execution can fail for a number of reasons. > > The question I had was whether it is enough to register one SASL > method, namely "OAUTH", for two different security mechanisms, namely > for OAuth 1.0 MAC tokens, and for the OAuth 2.0 Bearer Token, or > whether these should rather be exposed as two separate > mechanisms. Using two separate SASL mechanisms allows us to use the > SASL negotiation mechanism. > > In an earlier discussion we had spoken about the difference between > the two mechanisms and Bill's argument was that he wanted both since > neither one of them covers the deployment nor the required > properties. Ultimately it boiled down to the question of how many > different OAuth variants one wants to implement in the SASL client and > the SASL server. > > So, Bill has this idea that we could figure out what functionality is > supported by trial-and-error. To put that to the extreme one could > argue that we only one SASL mechanism (without any negotiation) and > then after some failed exchanges the client and the server will find a > mechanism that works. > > I am, however, advocating for registering more SASL methods to > distinguish the different variants. I would, for example, if we finish > the work on the new OAuth security mechanism standardize that as a > SASL mechanism with a new id. > > On Aug 21, 2012, at 10:16 PM, Simon Josefsson wrote: > >> William Mills writes: >> >>> We have a question in play. Does a SASL mechanism have to have >>> guaranteed compatibility or is it OK for a mechanism to discover that >>> there are no shared capabilities like SSL might discover no shared >>> cipher suites? >> >> SASL mechanisms can fail for any reason. RFC 4422: >> >> The outcome is not successful if >> >> - the authentication exchange failed for any reason, >> >> The application can retry in this situation. However, this is not >> always well supported by applications, but if mechanisms starts to fail >> when attempted, those bugs will be noticed and fixed. >> >> /Simon From hannes.tschofenig@gmx.net Wed Aug 22 00:52:54 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060D821F8607 for ; Wed, 22 Aug 2012 00:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 S-JzBWq2jyd2 for ; Wed, 22 Aug 2012 00:52:53 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E06C521F8600 for ; Wed, 22 Aug 2012 00:52:52 -0700 (PDT) Received: (qmail invoked by alias); 22 Aug 2012 07:52:51 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp024) with SMTP; 22 Aug 2012 09:52:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/T21UmDszTr+l/FPoOEQLljxvAjZ83QijH1YyKOw u1vkuhORuU65J/ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <87k3wre6am.fsf@latte.josefsson.org> Date: Wed, 22 Aug 2012 10:52:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6638A010-8F30-4219-B1D7-45881EF13507@gmx.net> References: <1345163301.61508.YahooMailNeo@web31805.mail.mud.yahoo.com> <588B67DC-7788-49DF-B303-753D4B420D3C@gmx.net> <1345482606.17400.YahooMailNeo@web31801.mail.mud.yahoo.com> <02D60FA0-45E3-4331-837A-E049029D919B@gmx.net> <1345531034.66639.YahooMailNeo@web31805.mail.mud.yahoo.com> <1345531945.23279.YahooMailNeo@web31804.mail.mud.yahoo.com> <24E6B416-8953-49A9-BDB1-73E8B482906D@gmx.net> <1345563667.23360.YahooMailNeo__20929.0090752349$1345563689$gmane$org@web31811.mail.mud.yahoo.com> <87boi4gioe.fsf@latte.josefsson.org> <6C4F4A39-D2E1-485F-9418-5B7D68C80AF6__25669.6146367633$1345613813$gmane$org@gmx.net> <87k3wre6am.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" , Jiangang Zhang , Gil Yehuda , Tim Showalter Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 07:52:54 -0000 That's inline with my thinking as well.=20 And: I had also noticed the terminology issue; there is room for wording = changes here and there.=20 Ciao Hannes On Aug 22, 2012, at 10:26 AM, Simon Josefsson wrote: > I have a preference for having at least two mechanisms, one for OAuth > 1.x and one for OAuth 2.x. The terminology and semantic differences > between OAuth 1.x and 2.x are motivation enough for me. >=20 > I believe the SASL mechanism selection is the most reliable place to > have negotiation in SASL, for better or worse. We have tried SASL > mechanisms that contain their own negotiation, and it always seem to > become too complex. >=20 > Further, one could argue that OAuth 2.x with bearer and OAuth 2.x with > MAC are so completely different beasts that they deserve separate SASL > mechanism names, and I would not object to that. I'd feel more > comfortable knowing that if I negotiated OAUTH2MAC I would get a keyed > authentication, whereas I would feel less confident when selecting > OAUTH2BEARER. If both bearer and MAC are negotiated through OAUTH2 I > would have to poke into the details of that mechanism negotiation, and > that is less reliable and more difficult to write security policies > for. >=20 > =46rom a standards point of view, having separate SASL mechanisms = seems > benefecial: the OAUTH1 mech would only normatively reference the OAuth > 1.x document, and could then be reviwed in isolation. The OAUTH2 > mech(s) would only normatively reference the OAuth 2.x documents. > Currently, when both 1.x and 2.x are referenced, the terminology = becomes > muddy as it is not clear what is the authorative reference for each > term. >=20 > /Simon >=20 > Hannes Tschofenig writes: >=20 >> There is no doubt that the protocol execution can fail for a number = of reasons.=20 >>=20 >> The question I had was whether it is enough to register one SASL >> method, namely "OAUTH", for two different security mechanisms, namely >> for OAuth 1.0 MAC tokens, and for the OAuth 2.0 Bearer Token, or >> whether these should rather be exposed as two separate >> mechanisms. Using two separate SASL mechanisms allows us to use the >> SASL negotiation mechanism. >>=20 >> In an earlier discussion we had spoken about the difference between >> the two mechanisms and Bill's argument was that he wanted both since >> neither one of them covers the deployment nor the required >> properties. Ultimately it boiled down to the question of how many >> different OAuth variants one wants to implement in the SASL client = and >> the SASL server. >>=20 >> So, Bill has this idea that we could figure out what functionality is >> supported by trial-and-error. To put that to the extreme one could >> argue that we only one SASL mechanism (without any negotiation) and >> then after some failed exchanges the client and the server will find = a >> mechanism that works. >>=20 >> I am, however, advocating for registering more SASL methods to >> distinguish the different variants. I would, for example, if we = finish >> the work on the new OAuth security mechanism standardize that as a >> SASL mechanism with a new id. >>=20 >> On Aug 21, 2012, at 10:16 PM, Simon Josefsson wrote: >>=20 >>> William Mills writes: >>>=20 >>>> We have a question in play. Does a SASL mechanism have to have >>>> guaranteed compatibility or is it OK for a mechanism to discover = that >>>> there are no shared capabilities like SSL might discover no shared >>>> cipher suites? >>>=20 >>> SASL mechanisms can fail for any reason. RFC 4422: >>>=20 >>> The outcome is not successful if >>>=20 >>> - the authentication exchange failed for any reason, >>>=20 >>> The application can retry in this situation. However, this is not >>> always well supported by applications, but if mechanisms starts to = fail >>> when attempted, those bugs will be noticed and fixed. >>>=20 >>> /Simon From cantor.2@osu.edu Wed Aug 22 07:43:04 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5604621F855E for ; Wed, 22 Aug 2012 07:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 JEX2tiBP1jFa for ; Wed, 22 Aug 2012 07:43:03 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 577DD21F84D8 for ; Wed, 22 Aug 2012 07:43:00 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7MEgujr011877; Wed, 22 Aug 2012 10:42:56 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.02.0309.002; Wed, 22 Aug 2012 10:42:55 -0400 From: "Cantor, Scott" To: Hannes Tschofenig , Simon Josefsson Thread-Topic: [kitten] OAuth SASL draft -04 Thread-Index: AQHNgDdvN1JTjezS1kibSVyVSmou6ZdluN+AgAAvhQA= Date: Wed, 22 Aug 2012 14:42:54 +0000 Message-ID: In-Reply-To: <6638A010-8F30-4219-B1D7-45881EF13507@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.46] Content-Type: text/plain; charset="us-ascii" Content-ID: <175FA3AF8EF74A4BB78593720291A959@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "kitten@ietf.org" Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 14:43:04 -0000 On 8/22/12 3:52 AM, "Hannes Tschofenig" wrote: >That's inline with my thinking as well. > >And: I had also noticed the terminology issue; there is room for wording >changes here and there. There is, naturally, a similar issue in SAML-EC with the subject confirmation being the determinant. I did build in some degree of negotiation already, because some of it is inherited from the HTTP use case on which the message exchange is inherited, but it does have the problem that you have to dig into the exchange to know which one is involved. -- Scott From rtroll@google.com Wed Aug 22 09:23:42 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D855F21F84C4 for ; Wed, 22 Aug 2012 09:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 xmBmUlQEcoqw for ; Wed, 22 Aug 2012 09:23:42 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0043E21F849B for ; Wed, 22 Aug 2012 09:23:41 -0700 (PDT) Received: by qadz3 with SMTP id z3so916519qad.10 for ; Wed, 22 Aug 2012 09:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record; bh=j60n9Bq69D44L71jUHMDV5xRwgOKEKln72vPf1+17+w=; b=cBlV75otVDHc9H6WhND0MIJ2pa2rCwspDY+drCg21z8ngGNmwYfYX0Zq/IvpOm0zWJ t8uUycGe9yD53YPOkFaRuE5hWPshUYJYShLX35Ot7ZeyqDhhj5UCmfxr1k3M9+D9kaTk tMdw3l4zR9Ctis4bFT69rFlHe9gM0aVSCxROM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record:x-gm-message-state; bh=j60n9Bq69D44L71jUHMDV5xRwgOKEKln72vPf1+17+w=; b=pwbVINDZYWzcRVkfDqcDpjgrlkm9nRlnuRceu7uP0c9fGbKILPwP9tJsf253yHcMws cpd5Cz5/AcpOTWJj9FxjBoO5VrHbM457Y8JBTorVS7u7ZidkXbFatIhr3qx9Ruh0wC9o 3GTtdgEttm95UUIBzFTs3J0LEL224uv1+ji5hua3hTXeStuzhwB0Hm03dP3FMKJDuoBd mgZ2EVmSzlJ7/Zxqyg/Ma66GoM9uneIJSedCWYkLOovmT6RAr/buKo+4fPyDzFUd3ER7 Ks5EMZL/ikB2912ZQZq1SqUupPluWXNAi7SZRpqD3vpYFqyRdXbVpJILJQvsDo3spD5a JaVA== Received: by 10.229.136.15 with SMTP id p15mr13963836qct.38.1345652621374; Wed, 22 Aug 2012 09:23:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.136.15 with SMTP id p15mr13963766qct.38.1345652618623; Wed, 22 Aug 2012 09:23:38 -0700 (PDT) Received: by 10.49.6.74 with HTTP; Wed, 22 Aug 2012 09:23:38 -0700 (PDT) In-Reply-To: References: <6638A010-8F30-4219-B1D7-45881EF13507@gmx.net> Date: Wed, 22 Aug 2012 09:23:38 -0700 Message-ID: From: Ryan Troll To: "kitten@ietf.org" Content-Type: multipart/alternative; boundary=00248c71184b52fc0504c7dd2a1b X-System-Of-Record: true X-Gm-Message-State: ALoCoQl5g2Cb81NNdPRjd9uB316lYObyPuchT5JlkOPNbxa278/FlwEAnorH2Yu/iJ2DhDqp+8iuo3il8b2LhE5F/3yUMmLK1tOC/5u8BATMC8CAU5ZC01g9OFs+PKO3N5Qkt8UeyuIugntfOQsZ3gHGDosccMM2A6bLjgjLlI0jI3lloPhv6Fo+fT8MEORzzUOgGgtf3w2w Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 16:23:43 -0000 --00248c71184b52fc0504c7dd2a1b Content-Type: text/plain; charset=ISO-8859-1 I vote for having separate mechanisms for OAUTH2MAC, OAUTH2BEARER, channel-binding versions, etc. Negotiations within a SASL mechanism, which this is leading towards, doesn't sound good. By letting clients know exactly which tokens are supported up-front, clients are able to better choose, and understand the implications of those choices. This should also allow us to remove the error-message-in-server-challenge and subsequent empty-client-challenge-response upon failure. -R On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott wrote: > On 8/22/12 3:52 AM, "Hannes Tschofenig" wrote: > > >That's inline with my thinking as well. > > > >And: I had also noticed the terminology issue; there is room for wording > >changes here and there. > > There is, naturally, a similar issue in SAML-EC with the subject > confirmation being the determinant. I did build in some degree of > negotiation already, because some of it is inherited from the HTTP use > case on which the message exchange is inherited, but it does have the > problem that you have to dig into the exchange to know which one is > involved. > > -- Scott > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > --00248c71184b52fc0504c7dd2a1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I vote for having separate mechanisms for OAUTH2MAC, OAUTH2BEARER, channel-= binding versions, etc.

Negotiations within a SASL mechan= ism, which this is leading towards, doesn't sound good. =A0By letting c= lients know exactly which tokens are supported up-front, clients are able t= o better choose, and understand the implications of those choices.

This should also allow us to remove the error-message-i= n-server-challenge and subsequent empty-client-challenge-response upon fail= ure.

-R


On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott <cantor.2@osu.edu> wrote:
On 8/22/12 3:52 AM, "Hannes Tschofenig" <hannes.tschofenig@gmx.net>= wrote:

>That's inline with my thinking as well.
>
>And: I had also noticed the terminology issue; there is room for wordin= g
>changes here and there.

There is, naturally, a similar issue in SAML-EC with the subject
confirmation being the determinant. I did build in some degree of
negotiation already, because some of it is inherited from the HTTP use
case on which the message exchange is inherited, but it does have the
problem that you have to dig into the exchange to know which one is
involved.

-- Scott

_______________________________________________
Kitten mailing list
Kitten@ietf.org
= https://www.ietf.org/mailman/listinfo/kitten

--00248c71184b52fc0504c7dd2a1b-- From wmills@yahoo-inc.com Wed Aug 22 11:35:43 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E688121F849D for ; Wed, 22 Aug 2012 11:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.554 X-Spam-Level: X-Spam-Status: No, score=-17.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 c+pvlzymGk4y for ; Wed, 22 Aug 2012 11:35:43 -0700 (PDT) Received: from nm31-vm1.bullet.mail.bf1.yahoo.com (nm31-vm1.bullet.mail.bf1.yahoo.com [72.30.239.9]) by ietfa.amsl.com (Postfix) with SMTP id C1AB221F8498 for ; Wed, 22 Aug 2012 11:35:41 -0700 (PDT) Received: from [98.139.212.153] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 22 Aug 2012 18:35:40 -0000 Received: from [98.139.212.225] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 22 Aug 2012 18:34:20 -0000 Received: from [127.0.0.1] by omp1034.mail.bf1.yahoo.com with NNFMP; 22 Aug 2012 18:34:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 597971.88906.bm@omp1034.mail.bf1.yahoo.com Received: (qmail 30993 invoked by uid 60001); 22 Aug 2012 18:34:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345660459; bh=I6GZTQrhpyxucDWr6O1itX1kJatYydBDPKhM6PosPYk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=bNxnLheRpM1FRGVyuUCvriUfvd6HuG9bfyApD1B4A0OyBo9U+2Ftg7Nq221/bjNMXRDH/ZRVljhsRYWRA5/3taiapKZpKfcxNb2xpmhaF3xcngT1M45WaKjkeQ2Yu5bw2VyxVCLK87aQxvIBbDHC5ZgAodvvxFXz31lKW6oOVVA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Xp74bCtgIjGCgvnzYG6Q1cuQJsRulZu/eAnJAL78pLKTiwcig/dNUseZoLjdNIdw+ZF2N5p143kZd1yJURDv0KpiwZ7ifk2eZ2GefYoalt0iKsa2kfpFquh3nn6dBaO/aoyyRPeON55ujhfFWzkupnV7lqLMUkOKOKq3PIn3kD0=; X-YMail-OSG: PyvP15IVM1nP2wXRrtSUEn.vcK0eOWilB_tpqWLF1XW0eS9 qSkwbfrEwkLsbuFHFUxFbAiVaUIgUqK4bjDdN4i4lUlsiI61_rrsHA16q.1. 2dctR0mCeqM834RQguEEpI.mstceFSXyuVtWLHbzFV0c9u4NIlVHcbArsKR4 Y87xqJctb4Yqe13Ro9v2DpKzx.HE1__Dv3dlqCh77tTIdl1._pTl8u_CblDB BkhMttjhHM1XEgDl2KJfM3E3BVvnk3UNc4pCTLcG5QjxpEwG9aD2OMgjZbvC PN0BiAaDD6wvzeyqhfoiZOLHRmkUks_98hgmwptIzFWM0.AVG.awA_yT2mto Uc5AaBEV09u3.JHswR4zTAaXpdy5vS1mGfXEUISAAbvmo.ygn8V.TG3gyd5d nnjMGohN9tWFXh4Y2jbD4bUMtZv1c7xZrW89T8ksvgP1b6pQDW8Ya6WUimD6 AZf_YF2g- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Wed, 22 Aug 2012 11:34:19 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <6638A010-8F30-4219-B1D7-45881EF13507@gmx.net> Message-ID: <1345660459.90893.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Wed, 22 Aug 2012 11:34:19 -0700 (PDT) From: William Mills To: Ryan Troll , "kitten@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-2042616816-1345660459=:90893" Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 18:35:44 -0000 --258328648-2042616816-1345660459=:90893 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Removing the error response means no richer status code for the client and = no advertised scope.=A0=A0 I'll do that if that's what people want, but I t= hink it is useful.=0A=0AI'll make the changes to the draft:=0A=0A-=A0=A0=A0= we'll define OAUTHBEARER, OAUTH10A, and their -PLUS variants.=A0 =0A-=A0= =A0=A0 adding back in the user field=0A-=A0=A0=A0 fixing the language for t= he gs2 header and only sending it in the GS2 context.=0A=0ANew specificatio= ns compatible with the existing structure in the draft then need only defin= e a new SASL mechanism name.=0A=0A=0A=0A=0A=0A>____________________________= ____=0A> From: Ryan Troll =0A>To: "kitten@ietf.org" =0A>Sent: Wednesday, August 22, 2012 9:23 AM=0A>Subject: Re= : [kitten] OAuth SASL draft -04=0A> =0A>=0A>I vote for having separate mech= anisms for OAUTH2MAC, OAUTH2BEARER, channel-binding versions, etc.=0A>=0A>= =0A>Negotiations within a SASL mechanism, which this is leading towards, do= esn't sound good. =A0By letting clients know exactly which tokens are suppo= rted up-front, clients are able to better choose, and understand the implic= ations of those choices.=0A>=0A>=0A>This should also allow us to remove the= error-message-in-server-challenge and subsequent empty-client-challenge-re= sponse upon failure.=0A>=0A>=0A>-R=0A>=0A>=0A>=0A>=0A>On Wed, Aug 22, 2012 = at 7:42 AM, Cantor, Scott wrote:=0A>=0A>On 8/22/12 3:52 = AM, "Hannes Tschofenig" wrote:=0A>>=0A>>>That's= inline with my thinking as well.=0A>>>=0A>>>And: I had also noticed the te= rminology issue; there is room for wording=0A>>>changes here and there.=0A>= >=0A>>There is, naturally, a similar issue in SAML-EC with the subject=0A>>= confirmation being the determinant. I did build in some degree of=0A>>negot= iation already, because some of it is inherited from the HTTP use=0A>>case = on which the message exchange is inherited, but it does have the=0A>>proble= m that you have to dig into the exchange to know which one is=0A>>involved.= =0A>>=0A>>-- Scott=0A>>=0A>>=0A>>__________________________________________= _____=0A>>Kitten mailing list=0A>>Kitten@ietf.org=0A>>https://www.ietf.org/= mailman/listinfo/kitten=0A>>=0A>=0A>_______________________________________= ________=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/= mailman/listinfo/kitten=0A>=0A>=0A> --258328648-2042616816-1345660459=:90893 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Removing = the error response means no richer status code for the client and no advert= ised scope.   I'll do that if that's what people want, but I thin= k it is useful.

I'll make the changes to the draft:

-    we'll define OAUTHBEARER, OAUTH10A, a= nd their -PLUS variants. 
-    = adding back in the user field
-  &n= bsp; fixing the language for the gs2 header and only sending it in the GS2 = context.

New specifications compatible with the existing stru= cture in the draft then need only define a new SASL mechanism name.


= =20
From: Ryan Troll <rtroll@googlers.com>
To: "kitten@ietf.org" <kitten@ietf.org> Sent: Wednesday, August = 22, 2012 9:23 AM
Subject:<= /b> Re: [kitten] OAuth SASL draft -04

I vote for having separate mechanisms for OAUTH2MAC, OAUTH2BEARE= R, channel-binding versions, etc.

Negotiations within a = SASL mechanism, which this is leading towards, doesn't sound good.  By= letting clients know exactly which tokens are supported up-front, clients = are able to better choose, and understand the implications of those choices.
=0A<= div>
This should also allow us to remove the error-message-in= -server-challenge and subsequent empty-client-challenge-response upon failu= re.

-R


=0AOn Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott = <cantor.2@osu.edu&= gt; wrote:
=0A
On 8/22/12 3:52 AM, "Hannes Tschofenig" <hannes.tschofenig@gmx.net&g= t; wrote:
=0A
=0A>That's inline with my thinking as well.
=0A&g= t;
=0A>And: I had also noticed the terminology issue; there is room f= or wording
=0A>changes here and there.
=0A
=0A
There is, n= aturally, a similar issue in SAML-EC with the subject
=0Aconfirmation be= ing the determinant. I did build in some degree of
=0Anegotiation alread= y, because some of it is inherited from the HTTP use
=0Acase on which th= e message exchange is inherited, but it does have the
=0Aproblem that yo= u have to dig into the exchange to know which one is
=0Ainvolved.
=0A=
=0A-- Scott<= br>=0A

=0A_______________________________________________
=0AKitte= n mailing list
=0AKitten@ietf.org
= =0Ahttps://www.ietf.org/mailman/listinfo/kitten
=0A=

=0A

_____________________= __________________________
Kitten mailing list
Kitten@ietf.org
http= s://www.ietf.org/mailman/listinfo/kitten


--258328648-2042616816-1345660459=:90893-- From simon@josefsson.org Wed Aug 22 11:39:33 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDF721F865B for ; Wed, 22 Aug 2012 11:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 Ozo7iUtctYww for ; Wed, 22 Aug 2012 11:39:33 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 32F9821F8658 for ; Wed, 22 Aug 2012 11:39:31 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7MIdN3o030021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Aug 2012 20:39:25 +0200 From: Simon Josefsson To: William Mills References: <6638A010-8F30-4219-B1D7-45881EF13507@gmx.net> <1345660459.90893.YahooMailNeo__17674.0978997715$1345660555$gmane$org@web31808.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120822:wmills@yahoo-inc.com::gFJVn28S0jY308Sc:dNi X-Hashcash: 1:22:120822:rtroll@googlers.com::G6NB3ZedvD++gFCA:4zt1 X-Hashcash: 1:22:120822:kitten@ietf.org::CPXmDRSH542WXCKu:Liqt Date: Wed, 22 Aug 2012 20:39:19 +0200 In-Reply-To: <1345660459.90893.YahooMailNeo__17674.0978997715$1345660555$gmane$org@web31808.mail.mud.yahoo.com> (William Mills's message of "Wed, 22 Aug 2012 11:34:19 -0700 (PDT)") Message-ID: <87boi2ai08.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "kitten@ietf.org" Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 18:39:33 -0000 William Mills writes: > Removing the error response means no richer status code for the client > and no advertised scope.   I'll do that if that's what people want, > but I think it is useful. > > I'll make the changes to the draft: > > -    we'll define OAUTHBEARER, OAUTH10A, and their -PLUS variants.  > -    adding back in the user field Great! > -    fixing the language for the gs2 header and only sending it in the > GS2 context. It is the other way around: the gs2 header should only be sent in the initial client SASL response, not in the initial GSS-API context token. > New specifications compatible with the existing structure in the draft > then need only define a new SASL mechanism name. Yes. Thanks, /Simon > > > > >>________________________________ >> From: Ryan Troll >>To: "kitten@ietf.org" >>Sent: Wednesday, August 22, 2012 9:23 AM >>Subject: Re: [kitten] OAuth SASL draft -04 >> >> >>I vote for having separate mechanisms for OAUTH2MAC, OAUTH2BEARER, >> channel-binding versions, etc. >> >> >>Negotiations within a SASL mechanism, which this is leading towards, >> doesn't sound good.  By letting clients know exactly which tokens >> are supported up-front, clients are able to better choose, and >> understand the implications of those choices. >> >> >>This should also allow us to remove the >> error-message-in-server-challenge and subsequent >> empty-client-challenge-response upon failure. >> >> >>-R >> >> >> >> >>On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott wrote: >> >>On 8/22/12 3:52 AM, "Hannes Tschofenig" wrote: >>> >>>>That's inline with my thinking as well. >>>> >>>>And: I had also noticed the terminology issue; there is room for wording >>>>changes here and there. >>> >>>There is, naturally, a similar issue in SAML-EC with the subject >>>confirmation being the determinant. I did build in some degree of >>>negotiation already, because some of it is inherited from the HTTP use >>>case on which the message exchange is inherited, but it does have the >>>problem that you have to dig into the exchange to know which one is >>>involved. >>> >>>-- Scott >>> >>> >>>_______________________________________________ >>>Kitten mailing list >>>Kitten@ietf.org >>>https://www.ietf.org/mailman/listinfo/kitten >>> >> >>_______________________________________________ >>Kitten mailing list >>Kitten@ietf.org >>https://www.ietf.org/mailman/listinfo/kitten >> >> >> > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nico@cryptonector.com Wed Aug 22 11:43:17 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED45C21F8574 for ; Wed, 22 Aug 2012 11:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, 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 ps5xFLlaTOMG for ; Wed, 22 Aug 2012 11:43:17 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id BBFF021F854A for ; Wed, 22 Aug 2012 11:43:17 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 798CE58406A for ; Wed, 22 Aug 2012 11:43:17 -0700 (PDT) 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; s=cryptonector.com; bh=nnXb3EHD3TCtpACmCOW2 zNwLSW4=; b=MQampBUSCaj8rusCGbr4++cBplfXOSd4w8fCgVPJ9qLgLCVJ5DT3 EfPiCPGT9ZwbbyD+91SJXb5//jVttbQlVww0RaXa3xbuGKJP+M2+J5zIzLOpOVNI cqoiVicZlMkesGBMdTz+VUHkQkyRxljzMOovX4kLsSi2O9ohHbDituI= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 5F2EA584059 for ; Wed, 22 Aug 2012 11:43:17 -0700 (PDT) Received: by dadf8 with SMTP id f8so980260dad.31 for ; Wed, 22 Aug 2012 11:43:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.202 with SMTP id bi10mr48204694pab.10.1345660996896; Wed, 22 Aug 2012 11:43:16 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 22 Aug 2012 11:43:16 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Aug 2012 13:43:16 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 18:43:18 -0000 On Tue, Aug 21, 2012 at 9:53 PM, Cantor, Scott wrote: > On 8/21/12 10:47 PM, "Nico Williams" wrote: >> >>If that's not possible then the mechanism as specified might be a SASL >>mechanism, but not a GSS nor GS2 mechanism. > > There's no reason why that should be an issue here. Right, it's very difficult to design a mechanism that could work as SASL but never, no-how, could be adapted as a GSS mechanism. But in principle, if that were the case here, I'd be OK with it. >>It's possible to have a SASL mech that looks like a gs2 mech but >>isn't. The question is: do you care to have OAuth as a GSS mechanism? > > Well, I do. Again for the "if I get stuck with this, have it not suck" > reasoning. +1e6. Nico -- From cantor.2@osu.edu Wed Aug 22 11:44:39 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9BB21F8550 for ; Wed, 22 Aug 2012 11:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 cYtgdFm89SXn for ; Wed, 22 Aug 2012 11:44:38 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6F16821F854A for ; Wed, 22 Aug 2012 11:44:38 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7MIiRbs015145; Wed, 22 Aug 2012 14:44:37 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.02.0309.002; Wed, 22 Aug 2012 14:44:19 -0400 From: "Cantor, Scott" To: Simon Josefsson Thread-Topic: [kitten] OAuth SASL draft -04 Thread-Index: AQHNgJVwN1JTjezS1kibSVyVSmou6ZdmKxUA Date: Wed, 22 Aug 2012 18:44:18 +0000 Message-ID: In-Reply-To: <87boi2ai08.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.31] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 18:44:39 -0000 On 8/22/12 2:39 PM, "Simon Josefsson" wrote: >> >> - we'll define OAUTHBEARER, OAUTH10A, and their -PLUS variants. >> - adding back in the user field > >Great! Simon, would you suggest I do the same for SAML-EC? I don't think it's a great idea to go all the way into specific holder of key types, but it's not a big deal to split bearer out. -- Scott From simon@josefsson.org Wed Aug 22 11:50:18 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283EF21F866E for ; Wed, 22 Aug 2012 11:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 hdBgI5ozCLJq for ; Wed, 22 Aug 2012 11:50:17 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0B41921F866A for ; Wed, 22 Aug 2012 11:50:12 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7MIo6HW030976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Aug 2012 20:50:08 +0200 From: Simon Josefsson To: "Cantor\, Scott" References: <87boi2ai08.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120822:kitten@ietf.org::I5HPAa4LeaOjQKaV:/sr X-Hashcash: 1:22:120822:cantor.2@osu.edu::Cj8CvrjE9pqTomHE:3x7v Date: Wed, 22 Aug 2012 20:50:02 +0200 In-Reply-To: (Scott Cantor's message of "Wed, 22 Aug 2012 18:44:18 +0000") Message-ID: <874nnuahid.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "kitten@ietf.org" Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 18:50:18 -0000 "Cantor, Scott" writes: > On 8/22/12 2:39 PM, "Simon Josefsson" wrote: >>> >>> - we'll define OAUTHBEARER, OAUTH10A, and their -PLUS variants. >>> - adding back in the user field >> >>Great! > > Simon, would you suggest I do the same for SAML-EC? I don't think it's a > great idea to go all the way into specific holder of key types, but it's > not a big deal to split bearer out. How many different schemes would there typically be? My impression was that SAML is more flexible around this, and that the flexibility is also used in some environments, so there could potentially be a lot of schemes. But perhaps for Internet-wide use, there is only a handful of schemes that are relevant? Then it may make sense. The downside then, of course, is that people doing their own stuff would be left out in the cold. Generally, if it makes things less complex to move out sub-negotiation from SASL mechanisms into the SASL mechanism selection process, I believe that is a good idea. But there can be situations where that leads to lesser security (think downgrade attacks) so it has to be weighted carefully. /Simon From cantor.2@osu.edu Wed Aug 22 12:02:43 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4A921F84C4 for ; Wed, 22 Aug 2012 12:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 uGHNLbW83351 for ; Wed, 22 Aug 2012 12:02:43 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2681B21F84C5 for ; Wed, 22 Aug 2012 12:02:43 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7MJ2gBw029289; Wed, 22 Aug 2012 15:02:42 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.02.0309.002; Wed, 22 Aug 2012 15:02:41 -0400 From: "Cantor, Scott" To: Simon Josefsson Thread-Topic: SAML-EC mech negotiation Thread-Index: AQHNgJi0knxsPCL6P0K5HIzGuKzqQw== Date: Wed, 22 Aug 2012 19:02:40 +0000 Message-ID: In-Reply-To: <874nnuahid.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.31] Content-Type: text/plain; charset="us-ascii" Content-ID: <18FE29FC4BD5054EBEB14018FEE7CA12@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: [kitten] SAML-EC mech negotiation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 19:02:44 -0000 Renaming the thread since we're off-topic... On 8/22/12 2:50 PM, "Simon Josefsson" wrote: >> >> Simon, would you suggest I do the same for SAML-EC? I don't think it's a >> great idea to go all the way into specific holder of key types, but it's >> not a big deal to split bearer out. > >How many different schemes would there typically be? The only holder of key approach likely in the near term is RSA, X.509 certs, etc. Longer term, ECDSA (and ECDH) become possibilities. I don't see MAC approaches being used at all. >My impression was that SAML is more flexible around this, and that the >flexibility is also >used in some environments, so there could potentially be a lot of >schemes. But perhaps for Internet-wide use, there is only a handful of >schemes that are relevant? Then it may make sense. The downside then, >of course, is that people doing their own stuff would be left out in the >cold. I don't think much beyond RSA and ECDSA would be too likely, but since most keyed tokens are probably going to have similar security properties, it seems like combining those is an advantage. I don't know enough to say whether splitting bearer at all is worth doing, but if it's worth it for OAuth, the same logic would apply. SAML bearer tokens can still do channel binding, but any session keying is not going to be secure, obviously, unless it's pulled from TLS. -- Scott From cantor.2@osu.edu Wed Aug 22 12:06:18 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198E421F86AD for ; Wed, 22 Aug 2012 12:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 Q718Lar+lUeJ for ; Wed, 22 Aug 2012 12:06:17 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3322B21F86A1 for ; Wed, 22 Aug 2012 12:06:17 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7MJ62DG018755; Wed, 22 Aug 2012 15:06:15 -0400 Received: from CIO-KRC-HT03.osuad.osu.edu (164.107.81.43) by CIO-KRC-HT02.osuad.osu.edu (164.107.81.40) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 22 Aug 2012 15:05:48 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT03.osuad.osu.edu ([fe80::2572:c08d:8186:46a4%12]) with mapi id 14.02.0309.002; Wed, 22 Aug 2012 15:05:48 -0400 From: "Cantor, Scott" To: Simon Josefsson Thread-Topic: [kitten] SAML-EC mech negotiation Thread-Index: AQHNgJi0knxsPCL6P0K5HIzGuKzqQ5dmMREA Date: Wed, 22 Aug 2012 19:05:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.31] Content-Type: text/plain; charset="us-ascii" Content-ID: <892C65EF35294F4798B571AEDB48740D@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "kitten@ietf.org" Subject: Re: [kitten] SAML-EC mech negotiation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 19:06:18 -0000 On 8/22/12 3:02 PM, "Cantor, Scott" wrote: > >I don't think much beyond RSA and ECDSA would be too likely, but since >most keyed tokens are probably going to have similar security properties, >it seems like combining those is an advantage. One advantage is that it's tied one-to-one to the SAML subject confirmation method. If somebody wanted semantics more precise than those connoted by "holder of key", that could be spun into a separate mechanism relatively painlessly, and chances are they would have to be touching lots of deployed pieces anyway. -- Scott From simon@josefsson.org Wed Aug 22 13:57:23 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B4E21F86BE for ; Wed, 22 Aug 2012 13:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.98 X-Spam-Level: X-Spam-Status: No, score=-98.98 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 RIZuwkNBoBLI for ; Wed, 22 Aug 2012 13:57:22 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6B02121F85B1 for ; Wed, 22 Aug 2012 13:57:22 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7MKvG2X004803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 22 Aug 2012 22:57:18 +0200 X-Hashcash: 1:22:120822:kitten@ietf.org::f2z3QESTer8zwstU:10bt From: Simon Josefsson To: kitten@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Wed, 22 Aug 2012 22:57:12 +0200 Message-ID: <87zk5m8x1z.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: [kitten] SCRAM GSS-API mechanism implementations? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 20:57:23 -0000 Has anyone implemented SCRAM as a GSS-API mechanism? On the initiator side I'm using gss_acquire_cred_with_password (with authentication identity being fed from the desired_name, or defaulting to system username), but I'm struggling to find a good server-side solution. There is gss_add_cred_with_password which you in theory could iterate over and add all local users, but you would typically not want to store passwords in clear text. Further, you would also want to specify the number of PBKDF2 iterations and the salt. So the only options appear to do something that is hidden from the application (like a /etc/my-scram-secrets file), or furnish a new GSS-API interface. The GSS-API interface could be a callback-style interface, to allow the application to fetch # of PBKDF2 iterations, salt, and hash for a particular user. If someone has implemented either approach or has pointers to it, it would be useful to share experience. Thanks, /Simon From wmills@yahoo-inc.com Wed Aug 22 21:53:38 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AB421F853F for ; Wed, 22 Aug 2012 21:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.551 X-Spam-Level: X-Spam-Status: No, score=-17.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 U5nnCFE1Sm3W for ; Wed, 22 Aug 2012 21:53:37 -0700 (PDT) Received: from nm11.bullet.mail.ac4.yahoo.com (nm11.bullet.mail.ac4.yahoo.com [98.139.52.208]) by ietfa.amsl.com (Postfix) with SMTP id C9BD921F8551 for ; Wed, 22 Aug 2012 21:53:36 -0700 (PDT) Received: from [98.139.52.191] by nm11.bullet.mail.ac4.yahoo.com with NNFMP; 23 Aug 2012 04:53:29 -0000 Received: from [98.139.52.156] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 23 Aug 2012 04:53:29 -0000 Received: from [127.0.0.1] by omp1039.mail.ac4.yahoo.com with NNFMP; 23 Aug 2012 04:53:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 436450.11992.bm@omp1039.mail.ac4.yahoo.com Received: (qmail 57951 invoked by uid 60001); 23 Aug 2012 04:53:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345697608; bh=Z1nIP7dnu+/kyI1HEDUq1p3QRNx551zYtVhXlnqNsXU=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=EYply92LsnXlDB8KQ3zdQlYKgTxDllUurNNJZ+v7R9qB7MYFuYgM3t7+by4e0DbrjKyxl4VqmUcbnJJ4bVHCmVUnaybhmqVbw7Jb4cF429obQhzem/ARRmr37gX+ijigulysYiRfw16Ul3wbNMzcvNOn7W7Vpp36oliRqLzzUl4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tM8dvmRI9jmOt+Q9IwbZrKCsoFD7L7+y1BSSGSSpDB2uQI9FBhjAapUOrj0ynEkUGdULoEH7TuGrnPOu45H3vfchl5snKIhc4EIr1xif6m1+YM78dUPQwDRteSX00qH6DiMyfW7zg0DOVySEp1nn2MEAgxDc7/hzc1rs29/Ahq0=; X-YMail-OSG: 3nYSAVkVM1kP60z0i00wqx8pZNXM39NIaAii2gFdbbEyO.E aYU15Asekg8Yh.NxEDTpsy03fCNhkeK3H7BN._J_YBJFNs3xaijrYL8Dt15x laTFgeP4kGfjJmPsTfPsZDx5fkbqBgkYvZC2cMGhXPjrhEVwStae4aLtL48O mbMi.IHfQ1eUMY_Xv6qocV74NuIftdFCQ.cdtibcQ0QuIXhe.ekOX5icMY2_ 3bAQdNnuaxd3jKpjXkSryHAv.JSPayqtCIjekAs1iMajkiX4hC4WBuvBo1o1 qpxjhcCnr76UWMRDwL6SjBcVeQ1VeovqrGlgheB5Kyl0.eLim5a.5n3S4Upv mWHSf31T7ZapLzIHBjdaQsn5B.djt1L_IVeG9F11TUZWdt1OKxm6aNBSnXwp O12iLRbmPYnpHsB9Th6luUtqP2pdv4djHe..RcQGJP34- Received: from [99.31.212.42] by web31806.mail.mud.yahoo.com via HTTP; Wed, 22 Aug 2012 21:53:28 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> Message-ID: <1345697608.40758.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Wed, 22 Aug 2012 21:53:28 -0700 (PDT) From: William Mills To: Simon Josefsson , Scott Cantor In-Reply-To: <87fw7fg9cv.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: [kitten] gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 04:53:38 -0000 =0A=0A=0A=0AOK, I now have the following language, which I think does what = is being asked for.=0A=0A=A0=A0=A0 3.1.2.=A0Use of the gs2-header=0A=0A=A0= =A0=A0 The OAuth scheme related mechanisms are also GSS-API mechanisms, see= =A0Section 4=A0for =0A=0A=A0=A0=A0 further detail. The gs2-header is used a= s follows:=0A=A0=A0=A0=A0=A0=A0=A0 * The "gs2-nonstd-flag" MUST NOT be pres= ent.=0A=A0=A0=A0 =A0=A0=A0 * The "gs2-authzid" carries the authorization id= entity as specified in [RFC5801].=0A=A0=A0=A0 In the non "-PLUS" mechanisms= the "gs2-cb-flag" MUST be set to "n" because channel-binding =0A=0A=A0=A0= =A0 [RFC5056] data is not expected. In the OAUTH10A-PLUS mechanism (or othe= r -PLUS variants =0A=0A=A0=A0=A0 based on this specification) the "gs2-cb-f= lag" MUST be set appropriately by the client.=0A=0A=0Aand then...=0A=0A=A0= =A0=A0 4.=A0GSS-API OAuth Mechanism Specification=0A=0A=0A=A0=A0=A0 Note: T= he normative references in this section are informational for SASL implemen= ters, but =0A=0A=A0=A0=A0 they are normative for GSS-API implementers.=A0 T= he SASL OAuth mechanism is also a GSS-API =0A=0A=A0=A0=A0 mechanism and the= messages described in=A0Section 3=A0are the same, but=0A=0A=A0=A0=A0=A01. = the GS2 header on the client's first message and the following %x01 (contro= l A) are excluded when used as a GSS-API=A0=A0=A0=A0mechanism.=0A=A0=A0=A0= =A02. the initial context token header is prefixed to the client's first au= thentication message (context token), as described in Section 3.1 of RFC 27= 43,=0A=0A=0A
=0A=0ADoes this do what is needed?=0A=0ATh= anks,=0A=0A-bill=0A=0A>________________________________=0A> From: Simon Jos= efsson =0A>To: kitten@ietf.org =0A>Sent: Tuesday, Augu= st 21, 2012 3:37 PM=0A>Subject: Re: [kitten] I-D Action: draft-ietf-kitten-= sasl-oauth-04.txt=0A> =0A>Thanks for the update!=0A>=0A>=A0=A0=A0Client res= ponses are a key/value pair sequence.=A0 The initial client=0A>=A0=A0=A0res= ponse includes a gs2-header as defined in GSS-API [RFC5801], which=0A>=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 ^^^^^^^ <- should be GS2=0A>=A0=A0=A0carries the authoriza= tion ID as a hint.=A0 These key/value pairs carry=0A>=A0=A0=A0the equivalen= t values from an HTTP context in order to be able to=0A>=A0=A0=A0complete a= n OAuth style HTTP authorization.=A0 The client MUST send an=0A>=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0^^^^=0A>=A0=A0=A0authorization ID in t= he gs2-header.=A0 The server MAY use this as a=0A>=A0=A0=A0routing or datab= ase lookup hint.=A0 The server MUST NOT use this as=0A>=A0=A0=A0authoritati= ve, the user name MUST be asserted by the OAuth=0A>=A0=A0=A0credential.=0A>= =0A>This MUST seems unusual -- the authorization identity in SASL is=0A>typ= ically not related to the authentication process, it is a server=0A>applica= tion specific username like "admin" or "joe".=A0 Most SASL clients=0A>do no= t specify an authorization identity, but instead let the server map=0A>the = authentication identity to an authorization identity.=A0 Wouldn't be=0A>pos= sible to support this here too?=A0 Let the client leave the=0A>authorizatio= n identity field empty, and let the server compare the OAuth=0A>credential = to see if it permits access as the authorization identity.=0A>If you need t= o transfer an OAuth identity hint, I'm thinking that would=0A>belong in a s= eparate field rather than overloading the authorization=0A>identity.=A0 I d= on't think the OAuth 1.x "token" value is comparable to an=0A>authorization= identity.=0A>=0A>Further, in section 4 you need to describe how the gs2-he= ader is removed=0A>from the initial context token when the protocol is used= as a GSS-API=0A>mechanism.=A0 Compare text like this in RFC 6595:=0A>=0A>= =A0=A0=A0a)=A0 the GS2 header on the client's first message and channel-bin= ding=0A>=A0 =A0 =A0=A0=A0data are excluded when SAML is used as a GSS-API m= echanism, and=0A>=0A>/Simon=0A>____________________________________________= ___=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailm= an/listinfo/kitten=0A>=0A>=0A> From simon@josefsson.org Wed Aug 22 22:41:00 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E50E21F844F for ; Wed, 22 Aug 2012 22:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.872 X-Spam-Level: X-Spam-Status: No, score=-99.872 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 Qwte2casn0fk for ; Wed, 22 Aug 2012 22:40:59 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFB221F8443 for ; Wed, 22 Aug 2012 22:40:57 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7N5envW031184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Aug 2012 07:40:50 +0200 From: Simon Josefsson To: William Mills References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120823:wmills@yahoo-inc.com::W4+WO2yEyFO/wTYB:64Gn X-Hashcash: 1:22:120823:cantor.2@osu.edu::7cN+itxd6upIRTnE:9/j2 X-Hashcash: 1:22:120823:kitten@ietf.org::9L5NnKbs9qCsYXkU:YluZ Date: Thu, 23 Aug 2012 07:40:44 +0200 In-Reply-To: <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> (William Mills's message of "Wed, 22 Aug 2012 21:53:28 -0700 (PDT)") Message-ID: <87r4qy88tf.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 05:41:00 -0000 William Mills writes: > OK, I now have the following language, which I think does what is > being asked for. Thank you! >     mechanism and the messages described in Section 3 are the same, but > >     1. the GS2 header on the client's first message and the following > %x01 (control A) are excluded when used as a GSS-API    mechanism. I don't think the %x01 should be excluded -- only the gs2-header. The property that we want is that when the OAuth GSS-API mechanism is used through GS2, the messages on the wire should be identical. If the %x01 is removed from the initial GSS-API token, there is nothing that would add it back, is there? /Simon From wmills@yahoo-inc.com Wed Aug 22 23:17:13 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334DF11E808A for ; Wed, 22 Aug 2012 23:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.555 X-Spam-Level: X-Spam-Status: No, score=-17.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 jPBQG6SIhomt for ; Wed, 22 Aug 2012 23:17:12 -0700 (PDT) Received: from nm25-vm0.bullet.mail.sp2.yahoo.com (nm25-vm0.bullet.mail.sp2.yahoo.com [98.139.91.228]) by ietfa.amsl.com (Postfix) with SMTP id 4BC3611E809A for ; Wed, 22 Aug 2012 23:17:11 -0700 (PDT) Received: from [72.30.22.77] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 06:17:08 -0000 Received: from [98.139.91.39] by tm11.bullet.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 06:17:08 -0000 Received: from [127.0.0.1] by omp1039.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 06:17:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 406573.69918.bm@omp1039.mail.sp2.yahoo.com Received: (qmail 22002 invoked by uid 60001); 23 Aug 2012 06:17:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345702627; bh=lPSpM6KPVOimEr0+KB/iqfDsGBEaha1T6gOTYJYPQv0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IFd5kWK1GFwItO58cH37bqzq+d636JjsJ93NN7nuha49eS4rRp8uqOO34i3G/l6TyDVl4d/ljzi70BirJxnzw9KiEowPd3iLrYvF7d9uSsr79GsmKFY3WC6VCdlZSd3tmE/L3IDQ77dA11sKCNUZOW5oPzQIQxoJUAkB+cu8EyY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cmrWR5pwBXsyhrFJgSDezVmRbYnEnQnovZX9SVbVJCVvM3cfzGIPcRuvZd1/3RllTgRjdF+Lc6Zoo3ocWaf3CHrAUl2ul8o+HDdioW2JMGLGDmLsUJ9LfrVOOvF3rdgpGL+IAHpm8df/PSo/X8+Q3RmQEjsYwcZBWMNp9RZKYj4=; X-YMail-OSG: Wcnm.GsVM1lLpqHSbAiPJB8JoWs5rf7kOutAL2RBdsvSazk lyeZA4CaI2ptt0Mhd1eFRPGmNRLJBAPi13i1S5nW6bqLnajixMWKEBBdAHvU DF6eGe9WaVze7f60hmAHzY12s7zbhyVzgJh4fCoLlXHCDckkMRuC6vpdYyR. dkt5Yx0A9wEmrO8MVUJD3jfv.YIF8tzwWgQ4FRnKyo_X_g9GLwDWiaJaUzta XvYBPzEXF4SqQTf3mPMAzm5gIjGWb_wAaGf3lBAAApgzA96Ale_nFHI_w0NX PYboiGk6thwaskFtFp32CqdoXG.XsVzvUesbx.O5RKQul3cDZXeJYiIW11x. HR5xPH5_FY75xC6hzD3F5xFfDmvAyVTtY.nEBm0YYsO6EjASNjXbq7LgPmnW L8Swo1ZSyL2bI2LbqF1sXzw_3nlSHsFGIooB_LlOJUUBgT.NVyyv3yMg43Gc prEveeQ-- Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Wed, 22 Aug 2012 23:17:07 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> Message-ID: <1345702627.94418.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Wed, 22 Aug 2012 23:17:07 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87r4qy88tf.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1935884094-1356355488-1345702627=:94418" Cc: "kitten@ietf.org" Subject: Re: [kitten] gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 06:17:13 -0000 --1935884094-1356355488-1345702627=:94418 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The %x01 after the gs2 header could stay, but it would be better if it coul= d go away.=A0 It's only there to provide an easy terminator to the gs2-head= er.=A0 A leading %x01 here might confuse some implementers.=0A=0AIs it a pr= oblem?=A0 Nothing should add it back.=0A=0A=0A=0A=0A=0A>___________________= _____________=0A> From: Simon Josefsson =0A>To: Willia= m Mills =0A>Cc: Scott Cantor ; "ki= tten@ietf.org" =0A>Sent: Wednesday, August 22, 2012 10:40= PM=0A>Subject: Re: gs2-header language Re: I-D Action: draft-ietf-kitten-s= asl-oauth-04.txt=0A> =0A>William Mills writes:=0A>= =0A>> OK, I now have the following language, which I think does what is=0A>= > being asked for.=0A>=0A>Thank you!=0A>=0A>> =A0=A0=A0 mechanism and the m= essages described in=A0Section 3=A0are the same, but=0A>>=0A>> =A0=A0=A0=A0= 1. the GS2 header on the client's first message and the following=0A>> %x01= (control A) are excluded when used as a GSS-API=A0=A0=A0=A0mechanism.=0A>= =0A>I don't think the %x01 should be excluded -- only the gs2-header.=A0 Th= e=0A>property that we want is that when the OAuth GSS-API mechanism is used= =0A>through GS2, the messages on the wire should be identical.=A0 If the %x= 01=0A>is removed from the initial GSS-API token, there is nothing that woul= d=0A>add it back, is there?=0A>=0A>/Simon=0A>=0A>=0A> --1935884094-1356355488-1345702627=:94418 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The %x01 = after the gs2 header could stay, but it would be better if it could go away= .  It's only there to provide an easy terminator to the gs2-header.&nb= sp; A leading %x01 here might confuse some implementers.

Is it a pro= blem?  Nothing should add it back.


From: Simon Josefsson &l= t;simon@josefsson.org>
To: William Mills <wmills@yahoo-inc.com>
Cc: Scott Cantor <cantor.2@osu.edu>; "kitten@ie= tf.org" <kitten@ietf.org>
= Sent: Wednesday, August 22, 2012 10:40 PM
Subject: Re: gs2-header language Re: I-D Act= ion: draft-ietf-kitten-sasl-oauth-04.txt

William Mil= ls <wmills@yahoo-inc.com> writes:

> OK, I now have= the following language, which I think does what is
> being asked for= .

Thank you!

>     mechanism and the messag= es described in Section 3 are the same, but
>
>  = ;   1. the GS2 header on the client's first message and the = following
> %x01 (control A) are excluded when used as a GSS-API    mechanism.

I don't think the %x01 sh= ould be excluded -- only the gs2-header.  The
property that we want= is that when the OAuth GSS-API mechanism is used
through GS2, the messa= ges on the wire should be identical.  If the %x01
is removed from t= he initial GSS-API token, there is nothing that would
add it back, is th= ere?

/Simon


--1935884094-1356355488-1345702627=:94418-- From internet-drafts@ietf.org Thu Aug 23 00:00:23 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622C821E8041; Thu, 23 Aug 2012 00:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 On7BoDGR3geq; Thu, 23 Aug 2012 00:00:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B287621F8535; Thu, 23 Aug 2012 00:00:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120823070022.24576.99119.idtracker@ietfa.amsl.com> Date: Thu, 23 Aug 2012 00:00:22 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 07:00:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. Title : A set of SASL and GSS-API Mechanisms for OAuth Author(s) : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-05.txt Pages : 28 Date : 2012-08-22 Abstract: OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) or the Generic Security Service Application Program Interface (GSS-API) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. Clients typically store the user's long term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a token. Tokens typically provided limited access rights and can be managed and revoked separately from the user's long-term credential (password). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wmills@yahoo-inc.com Thu Aug 23 00:04:59 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE4311E80C5 for ; Thu, 23 Aug 2012 00:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.555 X-Spam-Level: X-Spam-Status: No, score=-17.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 I3-0Wrs+dqrp for ; Thu, 23 Aug 2012 00:04:58 -0700 (PDT) Received: from nm20-vm0.bullet.mail.sp2.yahoo.com (nm20-vm0.bullet.mail.sp2.yahoo.com [98.139.91.218]) by ietfa.amsl.com (Postfix) with SMTP id 7362E11E808A for ; Thu, 23 Aug 2012 00:04:57 -0700 (PDT) Received: from [72.30.22.78] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 07:04:52 -0000 Received: from [98.139.91.27] by tm12.bullet.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 07:04:52 -0000 Received: from [127.0.0.1] by omp1027.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 07:04:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 872119.77801.bm@omp1027.mail.sp2.yahoo.com Received: (qmail 33192 invoked by uid 60001); 23 Aug 2012 07:04:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345705492; bh=vOn0dQ48SuSnpwn49aiAHfQMNao/3qrJeOucAlQmtyY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nDuhunmeOHT8MKihY9Z9rZXf2S9u+zhOBUUZAOj2H1WB0xNeHyDV0FFVkPayS89KlWr5viLFD+6ZnfVt+ST+gpf1VyjucPdOGZ5x4rwe16ziZks6BAOLp/nKCTeQYVZQLvagEezlDxLDGO/ACsD9USi8B69RvRoYZukPoZQNOzI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Mv6j+vKfXCutnlviRHRCrYUBulDi2E2hfu0tgx1cKu5IDOnzxOwkJzRJn59kdnZxu9l2no4e+hd2RGo0Bz6Y3z1LKrWHB9rQDFdSL/QoAOStyMTdHyNceakK6fzjA3lnotNO7B7B5rV7b2PUJ3CQdceO1cGtBx2RZTg83J/ZAiM=; X-YMail-OSG: WDVgrFwVM1liSz09O5crRAt2GAoiq9ebQxDLHKjsEYRLNmw oaGoFxcWOBe8XUOzyy2SYGhVRUOK6gdgSs90d.5QRd5a47gr0V8sJlV0rcza vdW78RKoMMZDXGMq8RPTrj7Q_HjY3eIKhbvTxUIW_SEKqwkXSgjha6obUP4S yT87JT9J.uCcakdZTYeaG2dlMT_90FACbACqdiuNz3LnwoV513UHUyNeF2hf JT7r3IBUd0HP9.XNYpHrYJfXa_H7khkEP9k5B23QsPgd3xKFyNvlVRD3TqhD XL5l5eATwVA2Y5o6x9RYfb2CrFvhYFfeRLnQJuASD_XSKyGuyvKyFitpN0hr OfLA9eEqGIxcaUTI0efRvJHNzxCodMmkgIiID7sdvZObd6Gsacbu4Im_HOLu qFIKeWxpO0INsHTx3KT48SexO5q_LkBZgAYSwlrw4uJnnIJN2WOCGNAO9OjS _AUtSzg-- Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Thu, 23 Aug 2012 00:04:52 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> <1345702627.94418.YahooMailNeo@web31810.mail.mud.yahoo.com> Message-ID: <1345705492.21472.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Thu, 23 Aug 2012 00:04:52 -0700 (PDT) From: William Mills To: William Mills , Simon Josefsson In-Reply-To: <1345702627.94418.YahooMailNeo@web31810.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-48546308-1345705492=:21472" Cc: "kitten@ietf.org" Subject: [kitten] OAuth SASL new version -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 07:05:00 -0000 ---1055047407-48546308-1345705492=:21472 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I think the outstanding questions at this time are:=0A=0A1)=A0=A0=A0 does t= he error message form the server serve a useful enough purpose to keep?=0A= =0A2)=A0=A0=A0 is it a problem to be pulling out the gs2-header AND the %x0= 1 after it?=0A=0A3)=A0=A0=A0 are the examples right, specifically do I have= the gs2-headers correct in the examples?=A0 or should they not be there in= regular SASL?=0A=0A=0A4)=A0=A0=A0 what have I messed up due to lack of sle= ep?=0A=0A-bill=0A=0A=0A=0A=0A>________________________________=0A> From: Wi= lliam Mills =0A>To: Simon Josefsson =0A>Cc: "kitten@ietf.org" =0A>Sent: Wednesday, Augus= t 22, 2012 11:17 PM=0A>Subject: Re: [kitten] gs2-header language Re: I-D Ac= tion: draft-ietf-kitten-sasl-oauth-04.txt=0A> =0A>=0A>The %x01 after the gs= 2 header could stay, but it would be better if it could go away.=A0 It's on= ly there to provide an easy terminator to the gs2-header.=A0 A leading %x01= here might confuse some implementers.=0A>=0A>Is it a problem?=A0 Nothing s= hould add it back.=0A>=0A>=0A>=0A>=0A>=0A>=0A>>____________________________= ____=0A>> From: Simon Josefsson =0A>>To: William Mills= =0A>>Cc: Scott Cantor ; "kitten@i= etf.org" =0A>>Sent: Wednesday, August 22, 2012 10:40 PM= =0A>>Subject: Re: gs2-header language Re: I-D Action: draft-ietf-kitten-sas= l-oauth-04.txt=0A>> =0A>>William Mills writes:=0A>>= =0A>>> OK, I now have the following language, which I think does what is=0A= >>> being asked for.=0A>>=0A>>Thank you!=0A>>=0A>>> =A0=A0=A0 mechanism and= the messages described in=A0Section 3=A0are the same, but=0A>>>=0A>>> =A0= =A0=A0=A01. the GS2 header on the client's first message and the following= =0A>>> %x01 (control A) are excluded when used as a=0A GSS-API=A0=A0=A0=A0m= echanism.=0A>>=0A>>I don't think the %x01 should be excluded -- only the gs= 2-header.=A0 The=0A>>property that we want is that when the OAuth GSS-API m= echanism is used=0A>>through GS2, the messages on the wire should be identi= cal.=A0 If the %x01=0A>>is removed from the initial GSS-API token, there is= nothing that would=0A>>add it back, is there?=0A>>=0A>>/Simon=0A>>=0A>>=0A= >>=0A>_______________________________________________=0A>Kitten mailing lis= t=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/listinfo/kitten=0A>=0A= >=0A> ---1055047407-48546308-1345705492=:21472 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I think the outstanding questions at this time are:

1)    does the error message form the server s= erve a useful enough purpose to keep?

=
2)    is it a problem to be pulling o= ut the gs2-header AND the %x01 after it?
<= br>
3)    are the examples right, s= pecifically do I have the gs2-headers correct in the examples?  or sho= uld they not be there in regular SASL?

4)    what = have I messed up due to lack of sleep?
= -bill

=
From:<= /b> William Mills <wmills@yahoo-inc.com>
To: Simon Josefsson <simon@josefsson.org> Cc: "kitten@ietf.org" &l= t;kitten@ietf.org>
Sent: Wednesday, August 22, 2012 11:17 PM
Subject: Re: [kitten] gs2-header language Re: I-D Acti= on: draft-ietf-kitten-sasl-oauth-04.txt

The= %x01 after the gs2 header could stay, but it would be better if it could go away.  It's = only there to provide an easy terminator to the gs2-header.  A leading= %x01 here might confuse some implementers.

Is it a problem?  N= othing should add it back.


From: Simon Josefsson <simon@josefsson.org><= br> To:=0A William Mills &l= t;wmills@yahoo-inc.com>
Cc: Scott Cantor <cantor.2@osu.edu>; "kitten@ietf.org" <kitten= @ietf.org>
Sent: We= dnesday, August 22, 2012 10:40 PM
= Subject: Re: gs2-header language Re: I-D Action: draft-ietf-kitt= en-sasl-oauth-04.txt

William Mills <wmills@yahoo-inc.com> writes:

>= OK, I now have the following language, which I think does what is
> = being asked for.

Thank you!

>     mechanism= and the messages described in Section 3 are the same, but
>= ;
>     1. the GS2 header on the client's first m= essage and the following
> %x01 (control A) are excluded when used as a=0A GSS-API    mechanism.

I don't= think the %x01 should be excluded -- only the gs2-header.  The
pro= perty that we want is that when the OAuth GSS-API mechanism is used
thro= ugh GS2, the messages on the wire should be identical.  If the %x01is removed from the initial GSS-API token, there is nothing that would
= add it back, is there?

/Simon



___________________________________________= ____
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mai= lman/listinfo/kitten


---1055047407-48546308-1345705492=:21472-- From simon@josefsson.org Thu Aug 23 00:48:15 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4817D21F84A1 for ; Thu, 23 Aug 2012 00:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 dj7MogIUBRWi for ; Thu, 23 Aug 2012 00:48:14 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1CB21F854A for ; Thu, 23 Aug 2012 00:48:12 -0700 (PDT) Received: from latte (46.182.205.36.c.fiberdirekt.net [46.182.205.36]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7N7lnjq005433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Aug 2012 09:47:59 +0200 From: Simon Josefsson To: William Mills References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> <1345702627.94418.YahooMailNeo__39642.1274905608$1345702640$gmane$org@web31810.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120823:wmills@yahoo-inc.com::0iNNNSEFA8PK5WAs:Jdro X-Hashcash: 1:22:120823:kitten@ietf.org::ky543YalgX5R4Gh+:ii1Q Date: Thu, 23 Aug 2012 09:47:42 +0200 In-Reply-To: <1345702627.94418.YahooMailNeo__39642.1274905608$1345702640$gmane$org@web31810.mail.mud.yahoo.com> (William Mills's message of "Wed, 22 Aug 2012 23:17:07 -0700 (PDT)") Message-ID: <87wr0qcan5.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 07:48:15 -0000 William Mills writes: > The %x01 after the gs2 header could stay, but it would be better if it > could go away.  It's only there to provide an easy terminator to the > gs2-header.  A leading %x01 here might confuse some implementers. > > Is it a problem?  Nothing should add it back. I'd say remove it -- the gs2-header is self-contained and there is no ambiguity in when it ends. /Simon From simon@josefsson.org Thu Aug 23 01:05:20 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B60821F85C3 for ; Thu, 23 Aug 2012 01:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 QwyPqJC+gN1U for ; Thu, 23 Aug 2012 01:05:20 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 930A221F85BB for ; Thu, 23 Aug 2012 01:05:19 -0700 (PDT) Received: from latte (46.182.205.36.c.fiberdirekt.net [46.182.205.36]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7N85Drg006414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Aug 2012 10:05:15 +0200 From: Simon Josefsson To: William Mills References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> <1345702627.94418.YahooMailNeo@web31810.mail.mud.yahoo.com> <1345705492.21472.YahooMailNeo__3474.55460946566$1345705515$gmane$org@web31806.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120823:wmills@yahoo-inc.com::/DQ3DPuj3/pKiRzr:vCY X-Hashcash: 1:22:120823:kitten@ietf.org::a5aIP7T+6+3k6ZrE:2+FV Date: Thu, 23 Aug 2012 10:05:07 +0200 In-Reply-To: <1345705492.21472.YahooMailNeo__3474.55460946566$1345705515$gmane$org@web31806.mail.mud.yahoo.com> (William Mills's message of "Thu, 23 Aug 2012 00:04:52 -0700 (PDT)") Message-ID: <87sjbec9u4.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] OAuth SASL new version -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 08:05:20 -0000 Thanks for update, I think we are getting there... On error messages, the section reads: In the case where authorization fails the server sends an error result, then client MUST then send an additional message to the server in order to allow the server to finish the exchange. Some protocols and common SASL implementations do not support both sending a SASL message and finalizing a SASL negotiation, the additional client message in the error case deals with this problem. The reason is not lack of support in protocols/implementations, it is RFC 4422 that requires that behaviour, quoting it: The protocol may include an optional additional data field in this outcome message. This field can only include additional data when the outcome is successful. So I would rewrite the above paragraph into: Section 3.6 of [RFC4422] explicitly prohibits additional information in an unsuccessful authentication outcome. Therefor, the error message is sent in a normal message. The client MUST then send an additional empty message to the server in order to allow the server to finish the exchange. There may be some considerations for the GSS-API mechanism side here, I'm not sure if the client should return GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED on the first gss_init_sec_context call. Is it permitted for applications to call gss_init_sec_context again, with a new token from the server, if it has already returned GSS_S_COMPLETE? I suspect so, but I can't find the text in RFC 2743 now. In this case, gss_init_sec_context would then return GSS_S_FAILURE afterwards which is a bit odd but maybe fine. /Simon From simon@josefsson.org Thu Aug 23 01:08:07 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B33F21F84E7 for ; Thu, 23 Aug 2012 01:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 WklidJAB8Jq5 for ; Thu, 23 Aug 2012 01:08:06 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id A406A21F8466 for ; Thu, 23 Aug 2012 01:07:58 -0700 (PDT) Received: from latte (46.182.205.36.c.fiberdirekt.net [46.182.205.36]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7N87pqT006435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Aug 2012 10:07:53 +0200 From: Simon Josefsson To: William Mills References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> <1345702627.94418.YahooMailNeo@web31810.mail.mud.yahoo.com> <1345705492.21472.YahooMailNeo__3474.55460946566$1345705515$gmane$org@web31806.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120823:wmills@yahoo-inc.com::8xZVywI1qxfWMR+j:0zav X-Hashcash: 1:22:120823:kitten@ietf.org::RbsQm90gnSJwsHaA:0HTKk Date: Thu, 23 Aug 2012 10:07:46 +0200 In-Reply-To: <1345705492.21472.YahooMailNeo__3474.55460946566$1345705515$gmane$org@web31806.mail.mud.yahoo.com> (William Mills's message of "Thu, 23 Aug 2012 00:04:52 -0700 (PDT)") Message-ID: <87obm2c9pp.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] OAuth SASL new version -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 08:08:07 -0000 Another minor nit: If the client gets an error message from the server it MUST send an empty client response consisting of a single %x01 (control A) ^^^^^ character, which is a correctly formatted client response with no key/value pairs. The server then completes the SASL negotiation with a failure result. A message with a single %x01 in it is not an empty message. I suggest to remove the word "empty" from this paragraph (and, from the text I suggested in the last email). /Simon From simon@josefsson.org Thu Aug 23 01:12:43 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02A221F8468 for ; Thu, 23 Aug 2012 01:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 4E0GBb72i7rl for ; Thu, 23 Aug 2012 01:12:42 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id DEB4B21F8467 for ; Thu, 23 Aug 2012 01:12:41 -0700 (PDT) Received: from latte (46.182.205.36.c.fiberdirekt.net [46.182.205.36]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7N8CLUB006663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Aug 2012 10:12:33 +0200 From: Simon Josefsson To: "Cantor\, Scott" References: <874nnuahid.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120823:cantor.2@osu.edu::GgaWERB/iSWNiyLX:C9R6 X-Hashcash: 1:22:120823:kitten@ietf.org::gWOOMFS0JWaK1aFf:S2Lu Date: Thu, 23 Aug 2012 10:12:16 +0200 In-Reply-To: (Scott Cantor's message of "Wed, 22 Aug 2012 19:02:40 +0000") Message-ID: <87k3wqc9i7.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] SAML-EC mech negotiation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 08:12:43 -0000 "Cantor, Scott" writes: >>My impression was that SAML is more flexible around this, and that the >>flexibility is also >>used in some environments, so there could potentially be a lot of >>schemes. But perhaps for Internet-wide use, there is only a handful of >>schemes that are relevant? Then it may make sense. The downside then, >>of course, is that people doing their own stuff would be left out in the >>cold. > > I don't think much beyond RSA and ECDSA would be too likely, but since > most keyed tokens are probably going to have similar security properties, > it seems like combining those is an advantage. Yes, splitting the mechanism names on the RSA vs ECDSA level seems excessive. Presumably, servers will typically implement both anyway? > I don't know enough to say whether splitting bearer at all is worth doing, > but if it's worth it for OAuth, the same logic would apply. It is not completely comparable -- for OAuth there is 1.x and 2.x which are different protocols even if there is similarity. It makes sense to separate. Compare if we wanted to support SAML 1.x here, then it might make sense to have separate mechanism names. > SAML bearer tokens can still do channel binding, but any session > keying is not going to be secure, obviously, unless it's pulled from > TLS. Maybe that is still useful... I dunno. /Simon From alexey.melnikov@isode.com Thu Aug 23 02:18:48 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59A121F8550 for ; Thu, 23 Aug 2012 02:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.843 X-Spam-Level: X-Spam-Status: No, score=-102.843 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 aCXsaepw7AbO for ; Thu, 23 Aug 2012 02:18:47 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDA321F8533 for ; Thu, 23 Aug 2012 02:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1345713525; d=isode.com; s=selector; i=@isode.com; bh=1mP0bycE9z1+BdKBHVcUju0OVJ7kS3xw6anikIyvMkg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=oBP/PXRoTR8Xcb9FBD3g/Gl8pZW2OAUl9HLFMowXjZQ2aeFRmN7PpjNeOgkX4dpW87nc36 gOmtCqFN43e8SRXipXQSxSY9dHDGp7dWNac8WtceO1zGjwShhOPDw+wG1RyvaeA4R+tPvN G9jp/Glnv4Kf3cAfDUfoqwn1NhUTW1M=; Received: from [172.16.11.4] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 23 Aug 2012 10:18:45 +0100 Message-ID: <5035F5DF.3060901@isode.com> Date: Thu, 23 Aug 2012 10:20:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: kitten@ietf.org References: <6638A010-8F30-4219-B1D7-45881EF13507@gmx.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080104080307010004010203" Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 09:18:48 -0000 This is a multi-part message in MIME format. --------------080104080307010004010203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 22/08/2012 17:23, Ryan Troll wrote: > I vote for having separate mechanisms for OAUTH2MAC, OAUTH2BEARER, > channel-binding versions, etc. Just to clarify: I hope you are not recommending to have a separate OAUTH SASL mechanism for each channel binding type. That would make the list of SASL mechanisms unmanageable. (Having separate mechanisms for MAC and BEARER seem to make sense, IMHO. But no strong preferences.) > Negotiations within a SASL mechanism, which this is leading towards, > doesn't sound good. By letting clients know exactly which tokens are > supported up-front, clients are able to better choose, and understand > the implications of those choices. > > This should also allow us to remove the > error-message-in-server-challenge and subsequent > empty-client-challenge-response upon failure. > > -R > > > On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott > wrote: > > On 8/22/12 3:52 AM, "Hannes Tschofenig" > wrote: > > >That's inline with my thinking as well. > > > >And: I had also noticed the terminology issue; there is room for > wording > >changes here and there. > > There is, naturally, a similar issue in SAML-EC with the subject > confirmation being the determinant. I did build in some degree of > negotiation already, because some of it is inherited from the HTTP use > case on which the message exchange is inherited, but it does have the > problem that you have to dig into the exchange to know which one is > involved. > > -- Scott > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --------------080104080307010004010203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 22/08/2012 17:23, Ryan Troll wrote:
I vote for having separate mechanisms for OAUTH2MAC, OAUTH2BEARER, channel-binding versions, etc.
Just to clarify: I hope you are not recommending to have a separate OAUTH SASL mechanism for each channel binding type. That would make the list of SASL mechanisms unmanageable.
(Having separate mechanisms for MAC and BEARER seem to make sense, IMHO. But no strong preferences.)
Negotiations within a SASL mechanism, which this is leading towards, doesn't sound good.  By letting clients know exactly which tokens are supported up-front, clients are able to better choose, and understand the implications of those choices.

This should also allow us to remove the error-message-in-server-challenge and subsequent empty-client-challenge-response upon failure.

-R


On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott <cantor.2@osu.edu> wrote:
On 8/22/12 3:52 AM, "Hannes Tschofenig" <hannes.tschofenig@gmx.net> wrote:

>That's inline with my thinking as well.
>
>And: I had also noticed the terminology issue; there is room for wording
>changes here and there.

There is, naturally, a similar issue in SAML-EC with the subject
confirmation being the determinant. I did build in some degree of
negotiation already, because some of it is inherited from the HTTP use
case on which the message exchange is inherited, but it does have the
problem that you have to dig into the exchange to know which one is
involved.

-- Scott

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten



_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten


--------------080104080307010004010203-- From alexey.melnikov@isode.com Thu Aug 23 02:38:12 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF2B21F85A5 for ; Thu, 23 Aug 2012 02:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.841 X-Spam-Level: X-Spam-Status: No, score=-102.841 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 3MkNApQVKWYQ for ; Thu, 23 Aug 2012 02:38:11 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1120621F854D for ; Thu, 23 Aug 2012 02:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1345714690; d=isode.com; s=selector; i=@isode.com; bh=GowT6qXrl3+1NI/kjtF8qlAfoNf27VEqAuicuIWlI6U=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Y1SHrAis7XWzIiBcR900NJ7BCLOqj2df5uH+SqDyRqKkCvTG4CaJ3kD5YO/W3tBMMMeS3Y 1YfEeKNcMXr7PfC7kSdk0zxRLcrNzWh2e5tTXlsQ4/2COjoM9bl02ZZ1pNYMJpSHaleklG w38qRi4gDNFYD5lWDSWmRCHgUd9G5Os=; Received: from [172.16.11.4] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 23 Aug 2012 10:38:10 +0100 Message-ID: <5035FA6C.1070200@isode.com> Date: Thu, 23 Aug 2012 10:39:56 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: William Mills References: <1345612319.55458.YahooMailNeo@web31807.mail.mud.yahoo.com> In-Reply-To: <1345612319.55458.YahooMailNeo@web31807.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090106090407050801020505" Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 09:38:12 -0000 This is a multi-part message in MIME format. --------------090106090407050801020505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 22/08/2012 06:11, William Mills wrote: > OK, so to do what I want the user field needs to go back in the SASL > message, and the gs2-header becomes optional and only present in a GS2 > message? gs2-header is never optional on the wire. > ------------------------------------------------------------------------ > *From:* "Cantor, Scott" > *To:* Nico Williams > *Cc:* William Mills ; "kitten@ietf.org" > ; Simon Josefsson > *Sent:* Tuesday, August 21, 2012 7:53 PM > *Subject:* Re: [kitten] I-D Action: > draft-ietf-kitten-sasl-oauth-04.txt > > On 8/21/12 10:47 PM, "Nico Williams" > wrote: > > > >If that's not possible then the mechanism as specified might be a > SASL > >mechanism, but not a GSS nor GS2 mechanism. > > There's no reason why that should be an issue here. > > >It's possible to have a SASL mech that looks like a gs2 mech but > >isn't. The question is: do you care to have OAuth as a GSS > mechanism? > > Well, I do. Again for the "if I get stuck with this, have it not suck" > reasoning. > > -- Scott > --------------090106090407050801020505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 22/08/2012 06:11, William Mills wrote:
OK, so to do what I want the user field needs to go back in the SASL message, and the gs2-header becomes optional and only present in a GS2 message?

gs2-header is never optional on the wire.

From: "Cantor, Scott" <cantor.2@osu.edu>
To: Nico Williams <nico103@gmail.com>
Cc: William Mills <wmills@yahoo-inc.com>; "kitten@ietf.org" <kitten@ietf.org>; Simon Josefsson <simon@josefsson.org>
Sent: Tuesday, August 21, 2012 7:53 PM
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-04.txt

On 8/21/12 10:47 PM, "Nico Williams" <nico103@gmail.com> wrote:
>
>If that's not possible then the mechanism as specified might be a SASL
>mechanism, but not a GSS nor GS2 mechanism.

There's no reason why that should be an issue here.

>It's possible to have a SASL mech that looks like a gs2 mech but
>isn't.  The question is: do you care to have OAuth as a GSS mechanism?

Well, I do. Again for the "if I get stuck with this, have it not suck"
reasoning.

-- Scott


--------------090106090407050801020505-- From cantor.2@osu.edu Thu Aug 23 07:15:04 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029BF21F857E for ; Thu, 23 Aug 2012 07:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 hyBpmI4hojlx for ; Thu, 23 Aug 2012 07:15:03 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5F47F21F856C for ; Thu, 23 Aug 2012 07:15:00 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7NEEneY021584; Thu, 23 Aug 2012 10:14:57 -0400 Received: from CIO-KRC-HT03.osuad.osu.edu (164.107.81.43) by CIO-TNC-HT05.osuad.osu.edu (164.107.81.168) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 23 Aug 2012 10:14:09 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT03.osuad.osu.edu ([fe80::2572:c08d:8186:46a4%12]) with mapi id 14.02.0309.002; Thu, 23 Aug 2012 10:13:48 -0400 From: "Cantor, Scott" To: Simon Josefsson Thread-Topic: SAML-EC mech negotiation Thread-Index: AQHNgQcBknxsPCL6P0K5HIzGuKzqQ5dncPMA Date: Thu, 23 Aug 2012 14:13:47 +0000 Message-ID: In-Reply-To: <87k3wqc9i7.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.16] Content-Type: text/plain; charset="us-ascii" Content-ID: <2D32F070AAFB7D42A707E22BDE43DC35@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] SAML-EC mech negotiation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 14:15:04 -0000 On 8/23/12 4:12 AM, "Simon Josefsson" wrote: > >Yes, splitting the mechanism names on the RSA vs ECDSA level seems >excessive. Presumably, servers will typically implement both anyway? Depends more on their crypto support. EC for example is turned off in Red Hat 6. >It is not completely comparable -- for OAuth there is 1.x and 2.x which >are different protocols even if there is similarity. It makes sense to >separate. Compare if we wanted to support SAML 1.x here, then it might >make sense to have separate mechanism names. Agree, but I don't think that was the whole motivation to split them. The point specifically raised was the lack of keying from the bearer mechanism and that would be true with SAML also. I'll leave it for the moment pending more review. -- Scott From wmills@yahoo-inc.com Thu Aug 23 08:19:47 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7292D21F856F for ; Thu, 23 Aug 2012 08:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.556 X-Spam-Level: X-Spam-Status: No, score=-17.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 YXRzYM-9x4au for ; Thu, 23 Aug 2012 08:19:46 -0700 (PDT) Received: from nm3.bullet.mail.sp2.yahoo.com (nm3.bullet.mail.sp2.yahoo.com [98.139.91.73]) by ietfa.amsl.com (Postfix) with SMTP id B5EBE21F8564 for ; Thu, 23 Aug 2012 08:19:46 -0700 (PDT) Received: from [72.30.22.78] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 15:19:46 -0000 Received: from [98.139.91.47] by tm12.bullet.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 15:18:46 -0000 Received: from [127.0.0.1] by omp1047.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 15:18:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 440418.22955.bm@omp1047.mail.sp2.yahoo.com Received: (qmail 54040 invoked by uid 60001); 23 Aug 2012 15:18:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345735125; bh=A9MkdNIQ1QcaA5sDWu8+sMAkhXnc9tINtT+k1hCzVHI=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lfGEBLLvOVBrasvyT4MhVyVJvnK05uOKjJuRltEm28NkpqYHKIMLhB6wFGrfm2CGzgoz2dDUMgrlhBK3TGZhM8Org67Gq0/V44YAfX5zpmJ/HnzwlzQtBHyC3xAGaWAmV7gnCDekfm90cxY5QvF6BmDpkMBEA3c4euUPICShmXk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Z7Cit9WAqF23q6uJ40pcugFVKnxZ8lrWpJea2J2kvgAhIXnc8wzK8kHcxLWpNHV8vHwXLBNzHA67LsqxBoeoApb4y8KRGMcHN4bJ5hrieJwTdDuW2wcDCEzMOh9wUh5yasjwAfgHz9Ysv7BP82/l1/GWYGxvyHDIN5E2H9VVU/Y=; X-YMail-OSG: ynX.3gAVM1nyvlS6P3ZUDYQHq7N7dKiaF2WCwNftCx9WFUw iTBL_CMZjifNEEvriyoFXst.L9Jr7wUyNSxh17KBVNGkvT3mXx7k0RC3cvvV 6clzUP5W4PCm1spzfTK9KDwCBO2IydQ9thWiQ3I9UoIJmwREPa4D9JmwB4OF dBx3j24lQ1_c7sKJcWrl4emPqbOs1BHwn0i8GviqEN5N3h6P8hrheFjVfy91 _Cj5CAfxk2UQdrUKUZUXwEKR4kL1Vr0veVkON6sxqWR.XBWfvzfqATD_gLi_ 3gVKMjUGocTuoOLQjtVc6uFxeB00NHhS7BE5rc6jPXlZXu9dFGKE3yHB8jGy U0iEJLCret604skhxf.iV3tGSiVPG60F1joOKhWEbUHjCR.5T9AU8OUB9Dh2 MAdd3.ETVc8NCcqGgY1YL7F4PVHG2Mzv_jGtjMOs_nO2JfLzp2WURbKMpOFX Spl2qXw-- Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Thu, 23 Aug 2012 08:18:45 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> <1345702627.94418.YahooMailNeo__39642.1274905608$1345702640$gmane$org@web31810.mail.mud.yahoo.com> <87wr0qcan5.fsf@latte.josefsson.org> Message-ID: <1345735125.16938.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Thu, 23 Aug 2012 08:18:45 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87wr0qcan5.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1935884094-1387597082-1345735125=:16938" Cc: "kitten@ietf.org" Subject: Re: [kitten] gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 15:19:47 -0000 --1935884094-1387597082-1345735125=:16938 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable To be honest, the gs2-header looks really annoying to parse.=A0 It's 2 or 3= fields and the termination of the second field is either the comma or just= the end of an authz ID.=A0 It needs some boundary between that and the fir= st key name.=0A=0A=0A=0A=0A=0A>________________________________=0A> From: S= imon Josefsson =0A>To: William Mills =0A>Cc: "kitten@ietf.org" =0A>Sent: Thursday, Augus= t 23, 2012 12:47 AM=0A>Subject: Re: gs2-header language Re: I-D Action: dra= ft-ietf-kitten-sasl-oauth-04.txt=0A> =0A>William Mills writes:=0A>=0A>> The %x01 after the gs2 header could stay, but it would = be better if it=0A>> could go away.=A0 It's only there to provide an easy t= erminator to the=0A>> gs2-header.=A0 A leading %x01 here might confuse some= implementers.=0A>>=0A>> Is it a problem?=A0 Nothing should add it back.=0A= >=0A>I'd say remove it -- the gs2-header is self-contained and there is no= =0A>ambiguity in when it ends.=0A>=0A>/Simon=0A>=0A>=0A> --1935884094-1387597082-1345735125=:16938 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --1935884094-1387597082-1345735125=:16938-- From wmills@yahoo-inc.com Thu Aug 23 08:26:05 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3D821F855E for ; Thu, 23 Aug 2012 08:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.557 X-Spam-Level: X-Spam-Status: No, score=-17.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 a8SzlcF1asZK for ; Thu, 23 Aug 2012 08:26:04 -0700 (PDT) Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by ietfa.amsl.com (Postfix) with ESMTP id 958C121F8559 for ; Thu, 23 Aug 2012 08:26:04 -0700 (PDT) Received: from [98.139.212.152] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 23 Aug 2012 15:26:04 -0000 Received: from [98.139.212.240] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 23 Aug 2012 15:26:03 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 23 Aug 2012 15:26:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 980677.18118.bm@omp1049.mail.bf1.yahoo.com Received: (qmail 99096 invoked by uid 60001); 23 Aug 2012 15:26:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345735563; bh=46BQnwYXGdYppd8ge22/WYxurFbKsmTUsPBHuVvRLuI=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VAQkFeni+uBJoSgRODGIlKfahgvoU4aPhZGcvEt+QOlE2jXDATk7W2waQZqwqVsguO6lxrz3O5V9ZCe9tjebpAxj0C7cmNAPdoPznHXL4adZEF0g8yWIzSbfynAXXWSngrdBSy3WtKVqW0txO1Omp6O1nTVARGleNt9wuYzehVI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PMNyoGvsqyKmbtxW4cxyADrjNvo3mAicXv+WhLDabfIOwPRwPtyLHlPTgpqccnykZ0Uc1KudJ7k+HFghD369qQWKP8zs7fgoXyW5MAl/IIvojhpEpae8o4vH3asNfqa0Wul9Xh3XaXN829c20DmqzDFwkaYVfpePTfGomSplYwI=; X-YMail-OSG: MkO3q5YVM1kWkIvNT.6dRsI_5vYkOtx_LBB7A72KT_qEOTW mLug1XcYH8VJvjZ_QKrlyGdQ7HkMvVnaagip_XyZ86TuT2OcLFPCM67h8CPh 2eLOQsRjfPjYmphUl9BOZWF.kRMZSgXewQApofLUpefOmmBbG0hsXSR6c9e6 JcmWw1BwIx2CSwcDhzfz6Tvybwy4S8WzIOf88eUsqOkgEOMKEnmXCw6UKa61 oVeZ0skkl6FsFNb4adF0nLnS7mYiUHQOC0lLQ.Oo7HxzQvxz9g2W4dWZOIhl CaxDWNF.pMpyJZ_EEuR7SPzghj6vuxQ51LRinKjFIh0rjZx5subNmqN.dmav CYopxgM4WF02pNEeFBAURIjfa2fKS1RZ_AZJYCrRAPpC.rqeX6juyrK8i1qm 2Ofdfj._ocjYIAYx748WPLTkU1IC.D0gR0o15z_L0E_sOi72xS74AZuvYaf8 CsgopqMs- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Thu, 23 Aug 2012 08:26:02 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> <1345702627.94418.YahooMailNeo@web31810.mail.mud.yahoo.com> <1345705492.21472.YahooMailNeo__3474.55460946566$1345705515$gmane$org@web31806.mail.mud.yahoo.com> <87sjbec9u4.fsf@latte.josefsson.org> Message-ID: <1345735562.80665.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Thu, 23 Aug 2012 08:26:02 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87sjbec9u4.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-866156998-1345735562=:80665" Cc: "kitten@ietf.org" Subject: Re: [kitten] OAuth SASL new version -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 15:26:05 -0000 --1458549034-866156998-1345735562=:80665 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Fixed the error sequence language, thank you.=0A=0A=0A=0A=0A=0A>___________= _____________________=0A> From: Simon Josefsson =0A>To= : William Mills =0A>Cc: "kitten@ietf.org" =0A>Sent: Thursday, August 23, 2012 1:05 AM=0A>Subject: Re: OAuth S= ASL new version -05=0A> =0A>Thanks for update, I think we are getting there= ...=0A>=0A>On error messages, the section reads:=0A>=0A>=A0 In the case wh= ere authorization fails the server sends an error=0A>=A0 result, then clie= nt MUST then send an additional message to the=0A>=A0 server in order to a= llow the server to finish the exchange.=A0 Some=0A>=A0 protocols and commo= n SASL implementations do not support both sending=0A>=A0 a SASL message a= nd finalizing a SASL negotiation, the additional=0A>=A0 client message in = the error case deals with this problem.=0A>=0A>The reason is not lack of su= pport in protocols/implementations, it is=0A>RFC 4422 that requires that be= haviour, quoting it:=0A>=0A>=A0 The protocol may include an optional addit= ional data field in this=0A>=A0 outcome message.=A0 This field can only in= clude additional data when=0A>=A0 the outcome is successful.=0A>=0A>So I w= ould rewrite the above paragraph into:=0A>=0A>=A0 Section 3.6 of [RFC4422]= explicitly prohibits additional information=0A>=A0 in an unsuccessful aut= hentication outcome.=A0 Therefor, the error=0A>=A0 message is sent in a no= rmal message.=A0 The client MUST then send an=0A>=A0 additional empty mess= age to the server in order to allow the server=0A>=A0 to finish the exchan= ge.=0A>=0A>There may be some considerations for the GSS-API mechanism side = here,=0A>I'm not sure if the client should return GSS_S_COMPLETE or=0A>GSS_= S_CONTINUE_NEEDED on the first gss_init_sec_context call.=A0 Is it=0A>permi= tted for applications to call gss_init_sec_context again, with a=0A>new tok= en from the server, if it has already returned GSS_S_COMPLETE?=A0 I=0A>susp= ect so, but I can't find the text in RFC 2743 now.=A0 In this case,=0A>gss_= init_sec_context would then return GSS_S_FAILURE afterwards which is=0A>a b= it odd but maybe fine.=0A>=0A>/Simon=0A>=0A>=0A> --1458549034-866156998-1345735562=:80665 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Fixed the= error sequence language, thank you.

= From: Simon Josefsson <s= imon@josefsson.org>
To:= William Mills <wmills@yahoo-inc.com>
Cc: "kitten@ietf.org" <kitten@ietf.org> Sent: Thursday, August 2= 3, 2012 1:05 AM
Subject: Re: OAuth= SASL new version -05

Thanks for update, I think we = are getting there...

On error messages, the section reads:

&n= bsp; In the case where authorization fails the server sends an error
&n= bsp; result, then client MUST then send an additional message to the
&n= bsp; server in order to allow the server to finish the exchange.  Som= e
  protocols and common SASL implementations do not support both = sending
  a SASL message and finalizing a SASL negotiation, the ad= ditional
  client message in the error case deals with this proble= m.

The reason is not lack of support in protocols/implementations, i= t is
RFC 4422 that requires that behaviour, quoting it:

  T= he protocol may include an optional additional data field in this
 = outcome message.  This field can only include additional data when
  the outcome is successful.

So I would rewrite the a= bove paragraph into:

  Section 3.6 of [RFC4422] explicitly pro= hibits additional information
  in an unsuccessful authentication = outcome.  Therefor, the error
  message is sent in a normal m= essage.  The client MUST then send an
  additional empty mess= age to the server in order to allow the server
  to finish the exc= hange.

There may be some considerations for the GSS-API mechanism si= de here,
I'm not sure if the client should return GSS_S_COMPLETE or
G= SS_S_CONTINUE_NEEDED on the first gss_init_sec_context call.  Is itpermitted for applications to call gss_init_sec_context again, with a
n= ew token from the server, if it has already returned GSS_S_COMPLETE?  = I
suspect so, but I can't find the text in RFC 2743 now.  In this c= ase,
gss_init_sec_context would then return GSS_S_FAILURE afterwards which is
a bit odd but maybe fine.

/Simon


=
--1458549034-866156998-1345735562=:80665-- From wmills@yahoo-inc.com Thu Aug 23 08:27:05 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5760021F855B for ; Thu, 23 Aug 2012 08:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.557 X-Spam-Level: X-Spam-Status: No, score=-17.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 vMvwWOXrUr8H for ; Thu, 23 Aug 2012 08:27:04 -0700 (PDT) Received: from nm27.bullet.mail.sp2.yahoo.com (nm27.bullet.mail.sp2.yahoo.com [98.139.91.97]) by ietfa.amsl.com (Postfix) with SMTP id CA46A21F8559 for ; Thu, 23 Aug 2012 08:27:04 -0700 (PDT) Received: from [98.139.91.70] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 15:26:56 -0000 Received: from [98.139.91.53] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 15:26:56 -0000 Received: from [127.0.0.1] by omp1053.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 15:26:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 826311.76925.bm@omp1053.mail.sp2.yahoo.com Received: (qmail 58852 invoked by uid 60001); 23 Aug 2012 15:26:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345735616; bh=KHz5JawVfwo4YCVOGYwn5Jt3rHW4OOfW8adlAz+oc7s=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mkby8Avmufew9D0Y6QJbGeUyhFeegAo5Hq0qeI1kkd3USnv5ID+43Amm7Pk3ERiNR9IJcgPbuigPiMQnzILO8S/acbMJqwLOo6jOpajIBFdE0D7Nfi0xFoEVtQM4v1wXcvZWWO6gaCkBKPG6KBfMrN8Ff6tUzQa9RMWTtxxKn8o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QBQ+CU+dah38ygmzNR8V5slqoFz+zjiB5NTifU8L+YjfLtPprkTJrPoeIBATKkut5uCLYntoYt08zCC/Dew4KPd4LaNOiYzxSDrPJd/bVyNKDjY2BxAKHPugLjImjkCiNVjM+HlLmHzajYrTLs8zAf6YfBBOpJ6pzjaOFwVTyPc=; X-YMail-OSG: aSDm9IsVM1lBBfbBqJVpK1epMwE6M1swg0_jG3Mbgypzij8 for1mw5WtgAFedW05OjBsKklYpD_CoTpL5XsbEtKatHeNZff5nwmHfqsNQb9 ajVFJq6JBDMh2y._7nm1e.0bGmjGMxMH9S4PP4nRMME.IpgBRlGByWqBimX. P7ns9M8.jmLG9g2GoE7vjL2jSoX3nni.7TomQxDazNs_DrkFfHJH6JP_eMV8 L8hX55QBhYfbZT0tXcFUG4ymMf8pF8p2xFmeBEsEuB6i5CHxB_BkPuXxxiJl YKZr0pLrBDVZAHhaA0D4H0aZrmghmvbbo3sqADaEC0BLggRduMxKldqziU4x idjG37UXUximMzG2i0TVw1GFBkPnn2SVOxTvtPmuuYVWI4uQ74MHM5qZWmVJ Mcm5Tp51Js09SirwGN7MFLl5XCwaMJxudBPSsGELy9D6W55LJA4ltLf8xzJN meYE96w-- Received: from [209.131.62.115] by web31809.mail.mud.yahoo.com via HTTP; Thu, 23 Aug 2012 08:26:55 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> <1345702627.94418.YahooMailNeo@web31810.mail.mud.yahoo.com> <1345705492.21472.YahooMailNeo__3474.55460946566$1345705515$gmane$org@web31806.mail.mud.yahoo.com> <87obm2c9pp.fsf@latte.josefsson.org> Message-ID: <1345735615.58775.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Thu, 23 Aug 2012 08:26:55 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87obm2c9pp.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-286915340-1345735615=:58775" Cc: "kitten@ietf.org" Subject: Re: [kitten] OAuth SASL new version -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 15:27:05 -0000 ---1395015409-286915340-1345735615=:58775 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OK=0A=0A=0A=0A=0A>________________________________=0A> From: Simon Josefsso= n =0A>To: William Mills =0A>Cc:= "kitten@ietf.org" =0A>Sent: Thursday, August 23, 2012 1:= 07 AM=0A>Subject: Re: OAuth SASL new version -05=0A> =0A>Another minor nit:= =0A>=0A>=A0 If the client gets an error message from the server it MUST se= nd an=0A>=A0 empty client response consisting of a single %x01 (control A)= =0A>=A0 ^^^^^=0A>=A0 character, which is a correctly formatted client res= ponse with no=0A>=A0 key/value pairs.=A0 The server then completes the SAS= L negotiation with=0A>=A0 a failure result.=0A>=0A>A message with a single= %x01 in it is not an empty message.=A0 I suggest=0A>to remove the word "em= pty" from this paragraph (and, from the text I=0A>suggested in the last ema= il).=0A>=0A>/Simon=0A>=0A>=0A> ---1395015409-286915340-1345735615=:58775 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OK

From:<= /b> Simon Josefsson <simon@josefsson.org>
To: William Mills <wmills@yahoo-inc.com> Cc: "kitten@ietf.org" &l= t;kitten@ietf.org>
Sent: Thursday, August 23, 2012 1:07 AM
Subject: Re: OAuth SASL new version -05
Another minor nit:

  If the client gets an error messag= e from the server it MUST send an
  empty client response consisti= ng of a single %x01 (control A)
  ^^^^^
  character, whic= h is a correctly formatted client response with no
  key/value pai= rs.  The server then completes the SASL negotiation with
  a = failure result.

A message with a single %x01 in it is not an empty m= essage.  I suggest
to remove the word "empty" from this paragraph (= and, from the text I
suggested in the last email).

/Simon

=
---1395015409-286915340-1345735615=:58775-- From rtroll@google.com Thu Aug 23 09:39:02 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7730A21F84C5 for ; Thu, 23 Aug 2012 09:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.916 X-Spam-Level: X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 tQTzGmtOlHc2 for ; Thu, 23 Aug 2012 09:39:01 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2353021F84B2 for ; Thu, 23 Aug 2012 09:39:00 -0700 (PDT) Received: by qcac10 with SMTP id c10so693203qca.31 for ; Thu, 23 Aug 2012 09:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=pNpNv1dIGN/o119IttaMmA9kohZtsjBmyN2lKQS7IRk=; b=ImmrRTTAshrUNtb/EXIgPjv6fqO2/ZB/maMG0dIM40yvV5E4HGqwE2GOStCUSOXtxH HlfffTnUnS2gkzcRTGGeg6BjlFieTNRJsFCwNCC6KEwYm50W45JY+B8yClFK4SMkbu1c DKwQI7PP1jhvu65oAIAD+7qvHNnj9AT2lIKfk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=pNpNv1dIGN/o119IttaMmA9kohZtsjBmyN2lKQS7IRk=; b=I+jzuJl8fOZtIp/OrtUpoLbHGz/DBVml25W7vQvy0UTNIDs2sxZrZShA9Y30L9611q pRgGeZz4M8bMXUDNW6aZZASYAI9lzDbe9Jr+l0G4rkvXlPRW29kgKPYfJMCpSqzqra1a /t+MRKRYf2mwQRQoqwNbG/HkdNw58Izr7UzBWq02c3LxPKGsURi9n5Vzc21ZYqSwQVu1 ZeDNppqoOtkFCYQyUXj0iaKABfC+2HxM5z4wIoTF8UD0yaSaMPNauSOzNE52owJiBEse 1kpzLuSLZ8f19ygEXcetrJBbFpYmkjKbTCB4ZWoea/TtbJSYhxTAZ/28G0DAm7JQe6iY F96A== Received: by 10.229.137.141 with SMTP id w13mr954438qct.102.1345739940299; Thu, 23 Aug 2012 09:39:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.137.141 with SMTP id w13mr954428qct.102.1345739940005; Thu, 23 Aug 2012 09:39:00 -0700 (PDT) Received: by 10.49.6.74 with HTTP; Thu, 23 Aug 2012 09:38:59 -0700 (PDT) In-Reply-To: <5035F5DF.3060901@isode.com> References: <6638A010-8F30-4219-B1D7-45881EF13507@gmx.net> <5035F5DF.3060901@isode.com> Date: Thu, 23 Aug 2012 09:38:59 -0700 Message-ID: From: Ryan Troll To: Alexey Melnikov Content-Type: multipart/alternative; boundary=00235452f5bc1586a004c7f17f7b X-System-Of-Record: true X-Gm-Message-State: ALoCoQkmS5FEuXONzWs7wq1trGtXirJjoa4uzW7aqJfN3+UuajMIKjGuaSHZIBOQOcfccIRtKjsaEEAfdpNzYGtBp6JmL2iP3gjPs2C1sL0LLyoDtvrLMs8Geg7O0PezxRi09g0HVcjqRGX7I7ssQNWsTYrjVjmpSak4oQ8N1jcsN37GzUzQraZ2glc05oYmvMJsMyYPDDWn Cc: kitten@ietf.org Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 16:39:02 -0000 --00235452f5bc1586a004c7f17f7b Content-Type: text/plain; charset=ISO-8859-1 No, I was alluding to a channel-binding enabled version of each previous token. For example "OAUTH2MAC", "OAUTH2MAC-PLUS", "OAUTH2BEARER", and "OAUTH2BEARER-PLUS", as draft -05 outlines. -R On Thu, Aug 23, 2012 at 2:20 AM, Alexey Melnikov wrote: > On 22/08/2012 17:23, Ryan Troll wrote: > > I vote for having separate mechanisms for OAUTH2MAC, OAUTH2BEARER, > channel-binding versions, etc. > > Just to clarify: I hope you are not recommending to have a separate OAUTH > SASL mechanism for each channel binding type. That would make the list of > SASL mechanisms unmanageable. > (Having separate mechanisms for MAC and BEARER seem to make sense, IMHO. > But no strong preferences.) > > Negotiations within a SASL mechanism, which this is leading towards, > doesn't sound good. By letting clients know exactly which tokens are > supported up-front, clients are able to better choose, and understand the > implications of those choices. > > This should also allow us to remove the > error-message-in-server-challenge and subsequent > empty-client-challenge-response upon failure. > > -R > > > On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott wrote: > >> On 8/22/12 3:52 AM, "Hannes Tschofenig" >> wrote: >> >> >That's inline with my thinking as well. >> > >> >And: I had also noticed the terminology issue; there is room for wording >> >changes here and there. >> >> There is, naturally, a similar issue in SAML-EC with the subject >> confirmation being the determinant. I did build in some degree of >> negotiation already, because some of it is inherited from the HTTP use >> case on which the message exchange is inherited, but it does have the >> problem that you have to dig into the exchange to know which one is >> involved. >> >> -- Scott >> >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten >> > > > > _______________________________________________ > Kitten mailing listKitten@ietf.orghttps://www.ietf.org/mailman/listinfo/kitten > > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > --00235452f5bc1586a004c7f17f7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No, I was alluding to a channel-binding enabled version of each previous to= ken. =A0For example "OAUTH2MAC", "OAUTH2MAC-PLUS", &quo= t;OAUTH2BEARER", and "OAUTH2BEARER-PLUS", as draft -05 outli= nes.

-R

On Thu, Aug 23, 2012 at= 2:20 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
=20 =20 =20
On 22/08/2012 17:23, Ryan Troll wrote:
I vote for having separate mechanisms for OAU= TH2MAC, OAUTH2BEARER, channel-binding versions, etc.
Just to clarify: I hope you are not recommending to have a separate OAUTH SASL mechanism for each channel binding type. That would make the list of SASL mechanisms unmanageable.
(Having separate mechanisms for MAC and BEARER seem to make sense, IMHO. But no strong preferences.)

Negotiations within a SASL mechanism, which this is leading towards, doesn't sound good. =A0By letting clients know exactly which tokens are supported up-front, clients are able to better choose, and understand the implications of those choices.

This should also allow us to remove the error-message-in-server-challenge and subsequent empty-client-challenge-response upon failure.

-R


On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott = <cantor.2@osu.edu<= /a>> wrote:
On 8/22/12 3:52 AM, "Hannes Tschofenig" <hannes.tschofeni= g@gmx.net> wrote:

>That's inline with my thinking as well.
>
>And: I had also noticed the terminology issue; there is room for wording
>changes here and there.

There is, naturally, a similar issue in SAML-EC with the subject
confirmation being the determinant. I did build in some degree of
negotiation already, because some of it is inherited from the HTTP use
case on which the message exchange is inherited, but it does have the
problem that you have to dig into the exchange to know which one is
involved.

-- Scott

_______________________________________________
Kitten mailing list
Kitten= @ietf.org
https://www.ietf.org/mailman/listinfo/kitten



_______________________________________________
Kitten mailing list
Kitten@ietf.org
=
https://www.ietf.org/mailman/listinfo/kitten



_______________________________________________
Kitten mailing list
Kitten@ietf.org
= https://www.ietf.org/mailman/listinfo/kitten


--00235452f5bc1586a004c7f17f7b-- From hannes.tschofenig@nsn.com Thu Aug 23 10:04:40 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3645621F853B for ; Thu, 23 Aug 2012 10:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.783 X-Spam-Level: X-Spam-Status: No, score=-105.783 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 yKLk1c80Nxu6 for ; Thu, 23 Aug 2012 10:04:38 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id AF16B21F84A0 for ; Thu, 23 Aug 2012 10:04:37 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7NH4WiS018966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Aug 2012 19:04:32 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7NH4U6A009249; Thu, 23 Aug 2012 19:04:32 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Aug 2012 19:04:11 +0200 Received: from 10.144.251.166 ([10.144.251.166]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.35]) with Microsoft Exchange Server HTTP-DAV ; Thu, 23 Aug 2012 17:04:10 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Thu, 23 Aug 2012 20:04:08 +0300 From: Hannes Tschofenig To: ext Ryan Troll , Alexey Melnikov Message-ID: Thread-Topic: [kitten] OAuth SASL draft -04 Thread-Index: Ac2BUU7rSvL6kLjuvU+Vtu5jkO23Vw== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3428597049_997656" X-OriginalArrivalTime: 23 Aug 2012 17:04:11.0058 (UTC) FILETIME=[50BE1120:01CD8151] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8909 X-purgate-ID: 151667::1345741472-00006F5F-BC380AE9/0-0/0-0 Cc: kitten@ietf.org Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 17:04:40 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3428597049_997656 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I think it is useful to have this list (CB and non-CB-based variants) to avoid the trial-and-error approach. On 8/23/12 7:38 PM, "ext Ryan Troll" wrote: > No, I was alluding to a channel-binding enabled version of each previous > token. =A0For example "OAUTH2MAC", "OAUTH2MAC-PLUS", "OAUTH2BEARER", and > "OAUTH2BEARER-PLUS", as draft -05 outlines. >=20 > -R >=20 > On Thu, Aug 23, 2012 at 2:20 AM, Alexey Melnikov > wrote: >> =20 >> =20 >> On 22/08/2012 17:23, Ryan Troll wrote: >> =20 >> =20 >>> I vote for having separate mechanisms for OAUTH2MAC, OAUTH2BEARER, >>> channel-binding versions, etc. >> Just to clarify: I hope you are not recommending to have a separate OAU= TH >> SASL mechanism for each channel binding type. That would make the list o= f >> SASL mechanisms unmanageable. >> (Having separate mechanisms for MAC and BEARER seem to make sense, IMHO= . But >> no strong preferences.) >>=20 >> =20 >>> =20 >>> Negotiations within a SASL mechanism, which this is leading towards, do= esn't >>> sound good. =A0By letting clients know exactly which tokens are supported >>> up-front, clients are able to better choose, and understand the implica= tions >>> of those choices. >>> =20 >>>=20 >>> =20 >>> =20 >>> This should also allow us to remove the error-message-in-server-challen= ge >>> and subsequent empty-client-challenge-response upon failure. >>> =20 >>>=20 >>> =20 >>> =20 >>> -R >>> =20 >>>=20 >>> =20 >>> =20 >>>=20 >>> =20 >>> On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott wrot= e: >>> =20 >>>> =20 >>>> On 8/22/12 3:52 AM, "Hannes Tschofenig" wr= ote: >>>> =20 >>>>> >That's inline with my thinking as well. >>>>> > >>>>> >And: I had also noticed the terminology issue; there is room for wo= rding >>>>> >changes here and there. >>>> =20 >>>> =20 >>>> There is, naturally, a similar issue in SAML-EC with the subject >>>> confirmation being the determinant. I did build in some degree of >>>> negotiation already, because some of it is inherited from the HTTP us= e >>>> case on which the message exchange is inherited, but it does have the >>>> problem that you have to dig into the exchange to know which one is >>>> involved. >>>> =20 >>>> -- Scott >>>> =20 >>>> =20 >>>>=20 >>>> _______________________________________________ >>>> Kitten mailing list >>>> Kitten@ietf.org >>>> https://www.ietf.org/mailman/listinfo/kitten >>>> =20 >>>> =20 >>>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> _______________________________________________ >>> Kitten mailing list >>> Kitten@ietf.org >>> https://www.ietf.org/mailman/listinfo/kitten >>> =20 >> =20 >> =20 >> =20 >>=20 >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten >>=20 >=20 >=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --B_3428597049_997656 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [kitten] OAuth SASL draft -04 I think it is useful to have this list (CB and non-CB-based variants) to a= void the trial-and-error approach.

On 8/23/12 7:38 PM, "ext Ryan Troll" <rtroll@googlers.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>No, I was alluding to a channel-binding enabled = version of each previous token. =A0For example "OAUTH2MAC", "OA= UTH2MAC-PLUS", "OAUTH2BEARER", and "OAUTH2BEARER-PLUS&qu= ot;, as draft -05 outlines.

-R

On Thu, Aug 23, 2012 at 2:20 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>    
 
On 22/08/2012 17:23, Ryan Troll wrote:
 
 
<= SPAN STYLE=3D'font-size:11pt'>I vote for having separate mechanisms for OAUTH2= MAC, OAUTH2BEARER, channel-binding versions, etc.
= Just to clarify: I hope you are not recommendi= ng to have a separate OAUTH SASL mechanism for each channel binding type. Th= at would make the list of SASL mechanisms unmanageable.
 (Having separate mechanisms for MAC and BEARER seem to make sense, IM= HO. But no strong preferences.)

 
<= SPAN STYLE=3D'font-size:11pt'>
Negotiations within a SASL mechanism, which this is leading towards, doesn'= t sound good. =A0By letting clients know exactly which tokens are supported up= -front, clients are able to better choose, and understand the implications o= f those choices.
 

 
 
This should also allow us to remove the error-message-in-server-challenge a= nd subsequent empty-client-challenge-response upon failure.
 

 
 
-R
 

 
 

 
 On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott <cantor.2@osu.edu> wrote:
 
<= SPAN STYLE=3D'font-size:11pt'>
On 8/22/12 3:52 AM, "Hannes Tschofenig" <hannes.tschofenig@gmx.net> wrote:
 
 >That's inline with my thinking as well.
 >
 >And: I had also noticed the terminology issue; there is room for = wording
 >changes here and there.
 
 
 There is, naturally, a similar issue in SAML-EC with the subject
 confirmation being the determinant. I did build in some degree of
 negotiation already, because some of it is inherited from the HTTP us= e
 case on which the message exchange is inherited, but it does have the=
 problem that you have to dig into the exchange to know which one is  involved.
 
-- Scott
 
 

 _______________________________________________
 Kitten mailing list
 Kitten@ietf.org
 https://www.ie= tf.org/mailman/listinfo/kitten
 
 
 
=
 
 
 
  
 
_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org= /mailman/listinfo/kitten
 
=
 
 

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org= /mailman/listinfo/kitten

=

___________= ____________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org= /mailman/listinfo/kitten
--B_3428597049_997656-- From wmills@yahoo-inc.com Thu Aug 23 16:00:15 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E77121F8549 for ; Thu, 23 Aug 2012 16:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.558 X-Spam-Level: X-Spam-Status: No, score=-17.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 yz9RggdRNJHZ for ; Thu, 23 Aug 2012 16:00:14 -0700 (PDT) Received: from nm30.bullet.mail.sp2.yahoo.com (nm30.bullet.mail.sp2.yahoo.com [98.139.91.100]) by ietfa.amsl.com (Postfix) with SMTP id 6AD8921F853D for ; Thu, 23 Aug 2012 16:00:13 -0700 (PDT) Received: from [98.139.91.61] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 23:00:10 -0000 Received: from [98.139.91.18] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 23:00:10 -0000 Received: from [127.0.0.1] by omp1018.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 23:00:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 640252.24482.bm@omp1018.mail.sp2.yahoo.com Received: (qmail 67922 invoked by uid 60001); 23 Aug 2012 23:00:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345762810; bh=hBV7xAL8iRDWLjCkNVBM0GA/YtyBS0Hqi3oJeMFjA5Y=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=eWXyqSxv+WlAYvUtU/xiszrQn77CGzA8IcsoMAzQ/O9yXgss4QDG39HJIBBYOS2KXSsSxeHayd2jw8M0Zfat7ugm/xb3D2UwIGaBCbNA9jozEi76CghN1NQZWcRFqex559CiE2Pakj5hfnRGMMuwtnvYQytRN8nRGqkn1uGbGIA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rGj5z/C3euOVeYkWCfpWwhKZE4FqPS+s030x3oWtF4sWY4YYmvTAq80cRnU6bW4W8EekZa9gT3cYx74ELn+9pMa7CG1ATWBYDwTCmAPLADw+DFNNrWcN6ORVey20TzSE6m1FKrFD4x11QvA+JkaxsD6i4H5qjJv3oCxGY55roiI=; X-YMail-OSG: lShVyC0VM1l1j1bGUjI3E65f_7RTGbuYlW7xZrMVtpZFWOH 5i6es9DNYzFLaD2Uwx8C9dOUYBbbVJ.pZ10uPVIb0BcepZCt1iJ02qXvEvAG HI2_Dv9Rn69wGZk7i6JvelXDR30o.NgXcoDojAFC6usSfxNJmtmLdIEI95c2 uDitx2OZMqQ9SMMdGarDkmZgE4R4FYajv3qSTLnudkJBULqvxriXWnXQhCeP WA0AlrUjVbpVrudlkVXDKTWfmjteZy_UKdzMIXPT8wEVoNd62z1Jumt.58td m1DI529zmBbks2JKOtTRFAwcM2fq7VPYZh8t0FVrNp0pduinRokxcPkP14zE doJKDZ9Oe1mTXZc4C4XsSBExZc5YOCPpzOu4EAlsapEqHwaOqx9rsn6UChm6 lu59Jq79DRwFwGQExsxdGqewm8bxaImsF1nHrwUMZ43VNmOisZXIcNhQ6GeS II1EzOg-- Received: from [209.131.51.116] by web31801.mail.mud.yahoo.com via HTTP; Thu, 23 Aug 2012 16:00:10 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> <1345702627.94418.YahooMailNeo__39642.1274905608$1345702640$gmane$org@web31810.mail.mud.yahoo.com> <87wr0qcan5.fsf@latte.josefsson.org> <1345735125.16938.YahooMailNeo@web31810.mail.mud.yahoo.com> Message-ID: <1345762810.5747.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Thu, 23 Aug 2012 16:00:10 -0700 (PDT) From: William Mills To: William Mills , Simon Josefsson In-Reply-To: <1345735125.16938.YahooMailNeo@web31810.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-368338466-920807497-1345762810=:5747" Cc: "kitten@ietf.org" Subject: Re: [kitten] gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:00:15 -0000 ---368338466-920807497-1345762810=:5747 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I've decided I don't care whether the control A following the gs2-eader is = removed or not.=A0 I'm going to strike that text in the GS2 section.=0A=0A= =0A=0A=0A=0A>________________________________=0A> From: William Mills =0A>To: Simon Josefsson =0A>Cc: "kit= ten@ietf.org" =0A>Sent: Thursday, August 23, 2012 8:18 AM= =0A>Subject: Re: [kitten] gs2-header language Re: I-D Action: draft-ietf-ki= tten-sasl-oauth-04.txt=0A> =0A>=0A>To be honest, the gs2-header looks reall= y annoying to parse.=A0 It's 2 or 3 fields and the termination of the secon= d field is either the comma or just the end of an authz ID.=A0 It needs som= e boundary between that and the first key name.=0A>=0A>=0A>=0A>=0A>=0A>=0A>= >________________________________=0A>> From: Simon Josefsson =0A>>To: William Mills =0A>>Cc: "kitten@ietf.= org" =0A>>Sent: Thursday, August 23, 2012 12:47 AM=0A>>Su= bject: Re: gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth= -04.txt=0A>> =0A>>William Mills writes:=0A>>=0A>>> T= he %x01 after the gs2 header could stay, but it would be better if it=0A>>>= could go away.=A0 It's only there to provide an easy terminator to the=0A>= >> gs2-header.=A0 A leading %x01 here might confuse some implementers.=0A>>= >=0A>>> Is it a problem?=A0 Nothing should add it back.=0A>>=0A>>I'd say re= move it -- the gs2-header is self-contained and there is no=0A>>ambiguity i= n when it ends.=0A>>=0A>>/Simon=0A>>=0A>>=0A>>=0A>_________________________= ______________________=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https:/= /www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> ---368338466-920807497-1345762810=:5747 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I've deci= ded I don't care whether the control A following the gs2-eader is removed o= r not.  I'm going to strike that text in the GS2 section.


From:= William Mills <wmills@yahoo-inc.com>
To: Simon Josefsson <simon@josefsson.org> <= br>Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Thursday, August 23, 2012 8:18 AM
Subject: Re: [kitten] gs2-header language Re: I-D Act= ion: draft-ietf-kitten-sasl-oauth-04.txt

To= be honest, the gs2-header looks really annoying to parse.  It's 2 or = 3 fields and the termination of the second field is either the comma or jus= t the end of an authz ID.  It needs some boundary between that and the= first key name.


Fro= m: Simon Josefsson <simon@josefsson.org>
To: William Mills=0A <wmills@yahoo-in= c.com>
Cc: "kitten@i= etf.org" <kitten@ietf.org>
= Sent: Thursday, August 23, 2012 12:47 AM
Subject: Re: gs2-header language Re: I-D Actio= n: draft-ietf-kitten-sasl-oauth-04.txt

William Mills= <wmills@yahoo-inc.com> w= rites:

> The %x01 after the gs2 header could stay, but it would b= e better if it
> could go away.  It's only there to provide an e= asy terminator to the
> gs2-header.  A leading %x01 here might c= onfuse some implementers.
>
> Is it a problem?  Nothing sh= ould add it back.

I'd say remove it -- the gs2-header is self-contai= ned and there is no
ambiguity in when it ends.

/Simon


=0A

_______________________________________________
Kitte= n mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/k= itten


---368338466-920807497-1345762810=:5747-- From nico@cryptonector.com Thu Aug 23 16:19:10 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9874E21F8574 for ; Thu, 23 Aug 2012 16:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 9+IwM5-Y3DgA for ; Thu, 23 Aug 2012 16:19:10 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 114EF21F856D for ; Thu, 23 Aug 2012 16:19:10 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 7D2782AC06A for ; Thu, 23 Aug 2012 16:19:09 -0700 (PDT) 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; s=cryptonector.com; bh=l9OGj/Dyv/nG3RlzDW+y 2adpuBo=; b=clPglctq2tFplcfIAgtMLruzpKcvAsQxzHGRTNkl3ytw+s0AVaRY 8HUTy4S3Ey7xY2uuWyI/7dkq+KBiHDPxYs7XPJLwpu2jMALnfzZ1kEJFzqlOqE2H /NVt7o4I2ZA+qUGz6Deq8ixut/O8y8di0dLaqd9kU6qK1GEfxH6iEag= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 5AA622AC05D for ; Thu, 23 Aug 2012 16:19:09 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so2261509pbb.31 for ; Thu, 23 Aug 2012 16:19:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.75.97 with SMTP id b1mr6690544paw.15.1345763949065; Thu, 23 Aug 2012 16:19:09 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 23 Aug 2012 16:19:08 -0700 (PDT) In-Reply-To: <1345762810.5747.YahooMailNeo@web31801.mail.mud.yahoo.com> References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> <1345702627.94418.YahooMailNeo__39642.1274905608$1345702640$gmane$org@web31810.mail.mud.yahoo.com> <87wr0qcan5.fsf@latte.josefsson.org> <1345735125.16938.YahooMailNeo@web31810.mail.mud.yahoo.com> <1345762810.5747.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Thu, 23 Aug 2012 18:19:08 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:19:10 -0000 On Thu, Aug 23, 2012 at 6:00 PM, William Mills wrote: > I've decided I don't care whether the control A following the gs2-eader is > removed or not. I'm going to strike that text in the GS2 section. Only the gs2 header needs to be removed. The rest needs to stay. That's because that's how a SASL/GS2 w/ GSS implementation will work: strip out the gs2 header from the message, prefix the gs2 header to the CB data, pass to GSS. Nico -- From wmills@yahoo-inc.com Thu Aug 23 16:22:53 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4E921F848F for ; Thu, 23 Aug 2012 16:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.558 X-Spam-Level: X-Spam-Status: No, score=-17.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 ea9Adlx4wIMb for ; Thu, 23 Aug 2012 16:22:52 -0700 (PDT) Received: from nm27.bullet.mail.bf1.yahoo.com (nm27.bullet.mail.bf1.yahoo.com [98.139.212.186]) by ietfa.amsl.com (Postfix) with SMTP id 52EBD21F8466 for ; Thu, 23 Aug 2012 16:22:52 -0700 (PDT) Received: from [98.139.212.149] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 23 Aug 2012 23:22:51 -0000 Received: from [98.139.215.249] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 23 Aug 2012 23:22:51 -0000 Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP; 23 Aug 2012 23:22:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 748551.24498.bm@omp1062.mail.bf1.yahoo.com Received: (qmail 82868 invoked by uid 60001); 23 Aug 2012 23:22:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345764171; bh=ILnyFEfR+38h4Q2Cs8qLx14yHf2Af0Gg0DF9ZlrLncA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VE2F6bcxVDXg4GIOB/Tx4NrYrj+pvR4+tCKFcDIRkhC1AZ6SUKpb/vM0l4qdmpHub19sHsz4dn3iaY4mgtwBtdl1YJukR1d4jfrGyntH+/cJZHrTG59Hes6LtwP/pgKfiVfNYVNhXKjoWMQ1i7qY4lwu1JTLGppL6plvyRXrjH0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Q23zzM/f55S4AHqqXRepEkUuPw6GL12Qyh4KoORbHxKxyLM7i7nPOd0jXz5agm2vOfn0ESsQJOlt+HiGZTcP2LH4NXUTvfEl3CUb7Yf576HJTakEWaAWEiOQWR9JhWdcAS8IND/U4dmwcAgReQYu2ofvNb2w6zGHmkZg70IdFVc=; X-YMail-OSG: vbRfiu4VM1lkBP7uSPmI8EBR3mfFYebSZAmEnN5X5CFAg5p NuZnBu8HjEVi_TZNcAKT8iMFPDwlcNhSwSNGYLhQOxNI_sY8Ekq6XZIDPzOY sEYrW.rGerVm3fGzNBoTOJCGhMgl4cww7Kl5D0H5Nz2qrVAjuvEV7R8qvCaO Fd2TDJDRTNQ3wenACHWyjwIyrKk8xh1pxcSR9IZSrk.HrpxkISTToU5TyRjW UexqtHPewVkA1FM2ojf62Jo.28pdQEZQ2ohwPSnFgJ5MKbMH9J9_8hUI0pLi QNB7Fo3g1eAJWime6KPFWEYemGbAjEMULtR6cMjDDVlrbJxfxGXrTMzDiB9B aXmTAgLwMm7qYhBJuBvZWBd3LiQKVhcx0rAwj_Co8r6nXhamzj54UpnoNy4o aJQVwFTLbrj0W40t0idXUYgF9LKF9A0wKJ1Sg_Q2jQl0HGzGLq0Vs8qrabzX 429MxfA-- Received: from [209.131.51.116] by web31804.mail.mud.yahoo.com via HTTP; Thu, 23 Aug 2012 16:22:50 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> <1345702627.94418.YahooMailNeo__39642.1274905608$1345702640$gmane$org@web31810.mail.mud.yahoo.com> <87wr0qcan5.fsf@latte.josefsson.org> <1345735125.16938.YahooMailNeo@web31810.mail.mud.yahoo.com> <1345762810.5747.YahooMailNeo@web31801.mail.mud.yahoo.com> Message-ID: <1345764170.82245.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Thu, 23 Aug 2012 16:22:50 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-781506659-1345764170=:82245" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:22:53 -0000 --835683298-781506659-1345764170=:82245 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks.=0A=0ANow my only remaining question for the moment is "did I do any= thing silly in the examples?"=0A=0A=0A=0A=0A=0A>___________________________= _____=0A> From: Nico Williams =0A>To: William Mills = =0A>Cc: Simon Josefsson ; "kitt= en@ietf.org" =0A>Sent: Thursday, August 23, 2012 4:19 PM= =0A>Subject: Re: [kitten] gs2-header language Re: I-D Action: draft-ietf-ki= tten-sasl-oauth-04.txt=0A> =0A>On Thu, Aug 23, 2012 at 6:00 PM, William Mil= ls wrote:=0A>> I've decided I don't care whether the= control A following the gs2-eader is=0A>> removed or not.=A0 I'm going to = strike that text in the GS2 section.=0A>=0A>Only the gs2 header needs to be= removed.=A0 The rest needs to stay.=0A>That's because that's how a SASL/GS= 2 w/ GSS implementation will work:=0A>strip out the gs2 header from the mes= sage, prefix the gs2 header to=0A>the CB data, pass to GSS.=0A>=0A>Nico=0A>= --=0A>=0A>=0A> --835683298-781506659-1345764170=:82245 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks.
Now my only remaining question for the moment is "did I do anything s= illy in the examples?"


From: Nico Williams <nico@cryptonector= .com>
To: William M= ills <wmills@yahoo-inc.com>
Cc: Simon Josefsson <simon@josefsson.org>; "kitten@ietf.o= rg" <kitten@ietf.org>
Sent: Thursday, August 23, 2012 4:19 PM
Subject: Re: [kitten] gs2-header language Re: I-D Act= ion: draft-ietf-kitten-sasl-oauth-04.txt

On Thu, Aug= 23, 2012 at 6:00 PM, William Mills <wmills@yahoo-inc.com> w= rote:
> I've decided I don't care whether the control A following the= gs2-eader is
> removed or not.  I'm going to strike that text i= n the GS2 section.

Only the gs2 header needs to be removed.  Th= e rest needs to stay.
That's because that's how a SASL/GS2 w/ GSS implem= entation will work:
strip out the gs2 header from the message, prefix th= e gs2 header to
the CB data, pass to GSS.

Nico
--


=
--835683298-781506659-1345764170=:82245-- From lukeh@padl.com Thu Aug 23 23:41:41 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12CB21E803F for ; Thu, 23 Aug 2012 23:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] 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 Osn2NURQja5o for ; Thu, 23 Aug 2012 23:41:41 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id F0EBB21E8034 for ; Thu, 23 Aug 2012 23:41:40 -0700 (PDT) Received: by us.padl.com with ESMTP id q7O6fJbg001134; Fri, 24 Aug 2012 02:41:22 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: Date: Fri, 24 Aug 2012 16:41:25 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> <1345702627.94418.YahooMailNeo__39642.1274905608$1345702640$gmane$org@web31810.mail.mud.yahoo.com> <87wr0qcan5.fsf@latte.josefsson.org> <1345735125.16938.YahooMailNeo@web31810.mail.mud.yahoo.com> <1345762810.5747.YahooMailNeo@web31801.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: kitten@ietf.org, Simon Josefsson Subject: Re: [kitten] gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 06:41:41 -0000 If it helps, look at the GS2 plugin in Cyrus SASL. -- Luke On 24/08/2012, at 9:19 AM, Nico Williams wrote: > On Thu, Aug 23, 2012 at 6:00 PM, William Mills = wrote: >> I've decided I don't care whether the control A following the = gs2-eader is >> removed or not. I'm going to strike that text in the GS2 section. >=20 > Only the gs2 header needs to be removed. The rest needs to stay. > That's because that's how a SASL/GS2 w/ GSS implementation will work: > strip out the gs2 header from the message, prefix the gs2 header to > the CB data, pass to GSS. >=20 > Nico > -- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com From simon@josefsson.org Fri Aug 24 00:12:06 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AE621F867A for ; Fri, 24 Aug 2012 00:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.129 X-Spam-Level: X-Spam-Status: No, score=-99.129 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 6xQQU2T46xZm for ; Fri, 24 Aug 2012 00:12:05 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2662D21F868A for ; Fri, 24 Aug 2012 00:12:03 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7O7BuIZ012398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Aug 2012 09:11:57 +0200 From: Simon Josefsson To: "Cantor\, Scott" References: <87k3wqc9i7.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120824:cantor.2@osu.edu::HKJxuofDbICvBuN6:NQS3 X-Hashcash: 1:22:120824:kitten@ietf.org::jHIQGvcm5Lb/uLJ9:Y0kU Date: Fri, 24 Aug 2012 09:11:55 +0200 In-Reply-To: (Scott Cantor's message of "Thu, 23 Aug 2012 14:13:47 +0000") Message-ID: <87sjbcahms.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] SAML-EC mech negotiation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 07:12:06 -0000 "Cantor, Scott" writes: > I'll leave it for the moment pending more review. That sounds good to me. /Simon From simon@josefsson.org Fri Aug 24 00:19:00 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B8F21F86B7 for ; Fri, 24 Aug 2012 00:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.547 X-Spam-Level: X-Spam-Status: No, score=-99.547 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] 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 8DpzPocLL3FE for ; Fri, 24 Aug 2012 00:19:00 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 178A521F86B3 for ; Fri, 24 Aug 2012 00:18:56 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7O7ImSM012731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Aug 2012 09:18:50 +0200 From: Simon Josefsson To: William Mills References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> <1345702627.94418.YahooMailNeo__39642.1274905608$1345702640$gmane$org@web31810.mail.mud.yahoo.com> <87wr0qcan5.fsf@latte.josefsson.org> <1345735125.16938.YahooMailNeo__16984.8681115129$1345735192$gmane$org@web31810.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120824:wmills@yahoo-inc.com::7yV+wda1ocOpE43+:7fzZ X-Hashcash: 1:22:120824:kitten@ietf.org::z10jJIH2+GWlnZ9Q:8mLN Date: Fri, 24 Aug 2012 09:18:48 +0200 In-Reply-To: <1345735125.16938.YahooMailNeo__16984.8681115129$1345735192$gmane$org@web31810.mail.mud.yahoo.com> (William Mills's message of "Thu, 23 Aug 2012 08:18:45 -0700 (PDT)") Message-ID: <87obm0ahbb.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 07:19:00 -0000 William Mills writes: > To be honest, the gs2-header looks really annoying to parse.  It's 2 > or 3 fields and the termination of the second field is either the > comma or just the end of an authz ID.  It needs some boundary between > that and the first key name. I don't think it is difficult to parse. There is no ambiguity wheter 2 or 3 fields are present: just check whether the first character is F or p/n/y and you know. Btw, the gs2-nonstd-flag part is not relevant here, as it would never be used by this SASL/GSSAPI mechanism. I suggest using a simpler gs2-header like this: simple-gs2-header = gs2-cb-flag "," [gs2-authzid] "," Btw, you could consider using "," instead of %x01 as the separator for other fields, then you could reuse the parser for the gs2-header part for the rest of the fields. Compare how SCRAM looks: C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096 C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= S: v=rmF9pqV8S7suAoZWja4dJRkFsKQ= Here the gs2-header part is "n,," and the rest of the fields are SCRAM fields. /Simon From simon@josefsson.org Fri Aug 24 00:20:55 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E1821F86A4 for ; Fri, 24 Aug 2012 00:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.839 X-Spam-Level: X-Spam-Status: No, score=-99.839 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 klqdLB8xUJBS for ; Fri, 24 Aug 2012 00:20:54 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2168921F8494 for ; Fri, 24 Aug 2012 00:20:52 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7O7KdJY012961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Aug 2012 09:20:41 +0200 From: Simon Josefsson To: Luke Howard References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> <1345702627.94418.YahooMailNeo__39642.1274905608$1345702640$gmane$org@web31810.mail.mud.yahoo.com> <87wr0qcan5.fsf@latte.josefsson.org> <1345735125.16938.YahooMailNeo@web31810.mail.mud.yahoo.com> <1345762810.5747.YahooMailNeo@web31801.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120824:lukeh@padl.com::/q8Iw2M8p7NansgB:7non X-Hashcash: 1:22:120824:kitten@ietf.org::P73cYdF5XifFdqFI:JqX8 X-Hashcash: 1:22:120824:wmills@yahoo-inc.com::QmzT1jBXeCO/4PVf:Mn/a Date: Fri, 24 Aug 2012 09:20:33 +0200 In-Reply-To: (Luke Howard's message of "Fri, 24 Aug 2012 16:41:25 +1000") Message-ID: <87k3woah8e.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 07:20:55 -0000 Luke Howard writes: > If it helps, look at the GS2 plugin in Cyrus SASL. Or for those allergic to GSS-API, presumably, the SCRAM plugin in Cyrus SASL. Or the GS2/SCRAM mechanisms in GNU SASL for that matter. :-) /Simon From simon@josefsson.org Fri Aug 24 00:24:12 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2156521F8494 for ; Fri, 24 Aug 2012 00:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.841 X-Spam-Level: X-Spam-Status: No, score=-99.841 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 LvFq4jV17dnK for ; Fri, 24 Aug 2012 00:24:11 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3D55921F84DD for ; Fri, 24 Aug 2012 00:24:11 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7O7O0OA012991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Aug 2012 09:24:01 +0200 From: Simon Josefsson To: Hannes Tschofenig References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120824:alexey.melnikov@isode.com::ADgqESbRDh1FWKdC:BCEl X-Hashcash: 1:22:120824:hannes.tschofenig@nsn.com::D9Sro89eli6TlI6b:FYyQ X-Hashcash: 1:22:120824:rtroll@googlers.com::smkjqidkOQUZ+wn+:0H9ya X-Hashcash: 1:22:120824:kitten@ietf.org::QtvmHSEM53qjzlzp:09R1W Date: Fri, 24 Aug 2012 09:23:59 +0200 In-Reply-To: (Hannes Tschofenig's message of "Thu, 23 Aug 2012 20:04:08 +0300") Message-ID: <87fw7cah2o.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 07:24:12 -0000 I have a mild preference for trying this approach too. However, doesn't this suggest that there should be a separate OID for the GSS-API mechanism side of each SASL mechanism? I think so. Further, the -05 document just specify OAUTHBEARER, OAUTH10A, and OAUTH10A-PLUS right now. /Simon Hannes Tschofenig writes: > I think it is useful to have this list (CB and non-CB-based variants) to > avoid the trial-and-error approach. > > On 8/23/12 7:38 PM, "ext Ryan Troll" wrote: > >> No, I was alluding to a channel-binding enabled version of each previous >> token.  For example "OAUTH2MAC", "OAUTH2MAC-PLUS", "OAUTH2BEARER", and >> "OAUTH2BEARER-PLUS", as draft -05 outlines. >> >> -R >> >> On Thu, Aug 23, 2012 at 2:20 AM, Alexey Melnikov >> wrote: >>> >>> >>> On 22/08/2012 17:23, Ryan Troll wrote: >>> >>> >>>> I vote for having separate mechanisms for OAUTH2MAC, OAUTH2BEARER, >>>> channel-binding versions, etc. >>> Just to clarify: I hope you are not recommending to have a separate OAUTH >>> SASL mechanism for each channel binding type. That would make the list of >>> SASL mechanisms unmanageable. >>> (Having separate mechanisms for MAC and BEARER seem to make sense, IMHO. But >>> no strong preferences.) >>> >>> >>>> >>>> Negotiations within a SASL mechanism, which this is leading towards, doesn't >>>> sound good.  By letting clients know exactly which tokens are supported >>>> up-front, clients are able to better choose, and understand the implications >>>> of those choices. >>>> >>>> >>>> >>>> >>>> This should also allow us to remove the error-message-in-server-challenge >>>> and subsequent empty-client-challenge-response upon failure. >>>> >>>> >>>> >>>> >>>> -R >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott wrote: >>>> >>>>> >>>>> On 8/22/12 3:52 AM, "Hannes Tschofenig" wrote: >>>>> >>>>>> >That's inline with my thinking as well. >>>>>> > >>>>>> >And: I had also noticed the terminology issue; there is room for wording >>>>>> >changes here and there. >>>>> >>>>> >>>>> There is, naturally, a similar issue in SAML-EC with the subject >>>>> confirmation being the determinant. I did build in some degree of >>>>> negotiation already, because some of it is inherited from the HTTP use >>>>> case on which the message exchange is inherited, but it does have the >>>>> problem that you have to dig into the exchange to know which one is >>>>> involved. >>>>> >>>>> -- Scott >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Kitten mailing list >>>>> Kitten@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/kitten >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Kitten mailing list >>>> Kitten@ietf.org >>>> https://www.ietf.org/mailman/listinfo/kitten >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Kitten mailing list >>> Kitten@ietf.org >>> https://www.ietf.org/mailman/listinfo/kitten >>> >> >> >> >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From hannes.tschofenig@gmx.net Fri Aug 24 00:34:25 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D675121F867A for ; Fri, 24 Aug 2012 00:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 FXx68D38xSOC for ; Fri, 24 Aug 2012 00:34:25 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id B932521F86A1 for ; Fri, 24 Aug 2012 00:34:24 -0700 (PDT) Received: (qmail invoked by alias); 24 Aug 2012 07:34:23 -0000 Received: from unknown (EHLO [10.255.134.220]) [194.251.119.201] by mail.gmx.net (mp041) with SMTP; 24 Aug 2012 09:34:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18wUDtOqkswGIh7TfDrDJkAy4G4Gahy0Y4k6fYwOG 9TQsJYxvOF9A4R Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <87fw7cah2o.fsf@latte.josefsson.org> Date: Fri, 24 Aug 2012 10:34:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87fw7cah2o.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: kitten@ietf.org Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 07:34:25 -0000 > Further, the -05 document just specify OAUTHBEARER, OAUTH10A, and > OAUTH10A-PLUS right now. >=20 True. Depending on the group consensus the draft will change.=20 Ciao Hannes > /Simon >=20 > Hannes Tschofenig writes: >=20 >> I think it is useful to have this list (CB and non-CB-based variants) = to >> avoid the trial-and-error approach. >>=20 >> On 8/23/12 7:38 PM, "ext Ryan Troll" wrote: >>=20 >>> No, I was alluding to a channel-binding enabled version of each = previous >>> token. For example "OAUTH2MAC", "OAUTH2MAC-PLUS", "OAUTH2BEARER", = and >>> "OAUTH2BEARER-PLUS", as draft -05 outlines. >>>=20 >>> -R >>>=20 >>> On Thu, Aug 23, 2012 at 2:20 AM, Alexey Melnikov = >>> wrote: >>>>=20 >>>>=20 >>>> On 22/08/2012 17:23, Ryan Troll wrote: >>>>=20 >>>>=20 >>>>> I vote for having separate mechanisms for OAUTH2MAC, OAUTH2BEARER, >>>>> channel-binding versions, etc. >>>> Just to clarify: I hope you are not recommending to have a separate = OAUTH >>>> SASL mechanism for each channel binding type. That would make the = list of >>>> SASL mechanisms unmanageable. >>>> (Having separate mechanisms for MAC and BEARER seem to make sense, = IMHO. But >>>> no strong preferences.) >>>>=20 >>>>=20 >>>>>=20 >>>>> Negotiations within a SASL mechanism, which this is leading = towards, doesn't >>>>> sound good. By letting clients know exactly which tokens are = supported >>>>> up-front, clients are able to better choose, and understand the = implications >>>>> of those choices. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> This should also allow us to remove the = error-message-in-server-challenge >>>>> and subsequent empty-client-challenge-response upon failure. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -R >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott = wrote: >>>>>=20 >>>>>>=20 >>>>>> On 8/22/12 3:52 AM, "Hannes Tschofenig" = wrote: >>>>>>=20 >>>>>>>> That's inline with my thinking as well. >>>>>>>>=20 >>>>>>>> And: I had also noticed the terminology issue; there is room = for wording >>>>>>>> changes here and there. >>>>>>=20 >>>>>>=20 >>>>>> There is, naturally, a similar issue in SAML-EC with the subject >>>>>> confirmation being the determinant. I did build in some degree of >>>>>> negotiation already, because some of it is inherited from the = HTTP use >>>>>> case on which the message exchange is inherited, but it does have = the >>>>>> problem that you have to dig into the exchange to know which one = is >>>>>> involved. >>>>>>=20 >>>>>> -- Scott >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Kitten mailing list >>>>>> Kitten@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/kitten >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Kitten mailing list >>>>> Kitten@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/kitten >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Kitten mailing list >>>> Kitten@ietf.org >>>> https://www.ietf.org/mailman/listinfo/kitten >>>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Kitten mailing list >>> Kitten@ietf.org >>> https://www.ietf.org/mailman/listinfo/kitten >>=20 >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From alexey.melnikov@isode.com Fri Aug 24 02:33:21 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DB921F868A for ; Fri, 24 Aug 2012 02:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] 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 GmCHENCsTWJM for ; Fri, 24 Aug 2012 02:33:20 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD7E21F8687 for ; Fri, 24 Aug 2012 02:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1345800798; d=isode.com; s=selector; i=@isode.com; bh=icq10s9qAn+tsS7T3qc6xHigx1m3NzVG8d/yPJ5Wz0s=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=OeqpZFbabt7K6zmose74N3iAYWPlSUW3a8SDact9H2ur9OcbL7VeJGCeRn25Z/Sml2LAJg 7jEJHC23peWKkXkvq64/aFVA2xqGEMIuKfSaym86g1L+7gtT2c9KRL5meKQiuP6c98jCKJ irFNB9ACJOzGoKSZvpJjOEcGagOtFsE=; Received: from [172.16.11.4] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 24 Aug 2012 10:33:18 +0100 Message-ID: <50374B05.1070802@isode.com> Date: Fri, 24 Aug 2012 10:36:05 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Simon Josefsson References: <20120820180545.30254.90003.idtracker__29406.8157127642$1345485973$gmane$org@ietfa.amsl.com> <87fw7fg9cv.fsf@latte.josefsson.org> <1345697608.40758.YahooMailNeo__3696.68543939969$1345697627$gmane$org@web31806.mail.mud.yahoo.com> <87r4qy88tf.fsf@latte.josefsson.org> <1345702627.94418.YahooMailNeo__39642.1274905608$1345702640$gmane$org@web31810.mail.mud.yahoo.com> <87wr0qcan5.fsf@latte.josefsson.org> <1345735125.16938.YahooMailNeo__16984.8681115129$1345735192$gmane$org@web31810.mail.mud.yahoo.com> <87obm0ahbb.fsf@latte.josefsson.org> In-Reply-To: <87obm0ahbb.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] gs2-header language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 09:33:21 -0000 (Speaking as a potential implementor.) On 24/08/2012 08:18, Simon Josefsson wrote: > William Mills writes: >> To be honest, the gs2-header looks really annoying to parse. It's 2 >> or 3 fields and the termination of the second field is either the >> comma or just the end of an authz ID. It needs some boundary between >> that and the first key name. > I don't think it is difficult to parse. There is no ambiguity wheter 2 > or 3 fields are present: just check whether the first character is F or > p/n/y and you know. Right. > Btw, the gs2-nonstd-flag part is not relevant here, as it would never be > used by this SASL/GSSAPI mechanism. I suggest using a simpler > gs2-header like this: > > simple-gs2-header = gs2-cb-flag "," [gs2-authzid] "," If this is used, I would like to see a comment saying that this still complies with the more generic syntax specified for GS2. > Btw, you could consider using "," instead of %x01 as the separator for > other fields, then you could reuse the parser for the gs2-header part > for the rest of the fields. I like that! > Compare how SCRAM looks: > > C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL > S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096 > C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= > S: v=rmF9pqV8S7suAoZWja4dJRkFsKQ= > > Here the gs2-header part is "n,," and the rest of the fields are SCRAM > fields. From alexey.melnikov@isode.com Fri Aug 24 02:45:10 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFFB21F86D0 for ; Fri, 24 Aug 2012 02:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.834 X-Spam-Level: X-Spam-Status: No, score=-102.834 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ocfhOHuF+13X for ; Fri, 24 Aug 2012 02:45:09 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4990B21F86EA for ; Fri, 24 Aug 2012 02:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1345801508; d=isode.com; s=selector; i=@isode.com; bh=zke7Apgz4sldPMYoRFVaOYDZI1Mpp0xw+G+xt7ZKmU0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Xvk7ES6rtGoibobOKsOiSbCoj23ljDHVOv6+Orgb+pBfFNMbWBLsz1BbJcFSNRT4BuUdZG 2mcSM5NVDjIMhQDRCuIgslNjmx1ldL9NlRjEbUtMaU0aEFxB5amBBW7yYzm+TqwX/treO/ ZZT6fEPSPPUnePPPhJh1+fGYgp4rQG8=; Received: from [172.16.11.4] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 24 Aug 2012 10:45:08 +0100 Message-ID: <50374DCB.5090100@isode.com> Date: Fri, 24 Aug 2012 10:47:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Simon Josefsson References: <87fw7cah2o.fsf@latte.josefsson.org> In-Reply-To: <87fw7cah2o.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 09:45:10 -0000 On 24/08/2012 08:23, Simon Josefsson wrote: > I have a mild preference for trying this approach too. However, doesn't > this suggest that there should be a separate OID for the GSS-API > mechanism side of each SASL mechanism? I think so. Yes. > Further, the -05 document just specify OAUTHBEARER, OAUTH10A, and > OAUTH10A-PLUS right now. > > /Simon > > Hannes Tschofenig writes: > >> I think it is useful to have this list (CB and non-CB-based variants) to >> avoid the trial-and-error approach. >> >> On 8/23/12 7:38 PM, "ext Ryan Troll" wrote: >> >>> No, I was alluding to a channel-binding enabled version of each previous >>> token. For example "OAUTH2MAC", "OAUTH2MAC-PLUS", "OAUTH2BEARER", and >>> "OAUTH2BEARER-PLUS", as draft -05 outlines. >>> >>> -R >>> >>> On Thu, Aug 23, 2012 at 2:20 AM, Alexey Melnikov >>> wrote: >>>> >>>> >>>> On 22/08/2012 17:23, Ryan Troll wrote: >>>> >>>> >>>>> I vote for having separate mechanisms for OAUTH2MAC, OAUTH2BEARER, >>>>> channel-binding versions, etc. >>>> Just to clarify: I hope you are not recommending to have a separate OAUTH >>>> SASL mechanism for each channel binding type. That would make the list of >>>> SASL mechanisms unmanageable. >>>> (Having separate mechanisms for MAC and BEARER seem to make sense, IMHO. But >>>> no strong preferences.) >>>> >>>> >>>>> >>>>> Negotiations within a SASL mechanism, which this is leading towards, doesn't >>>>> sound good. By letting clients know exactly which tokens are supported >>>>> up-front, clients are able to better choose, and understand the implications >>>>> of those choices. >>>>> >>>>> >>>>> >>>>> >>>>> This should also allow us to remove the error-message-in-server-challenge >>>>> and subsequent empty-client-challenge-response upon failure. >>>>> >>>>> >>>>> >>>>> >>>>> -R >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott wrote: >>>>> >>>>>> >>>>>> On 8/22/12 3:52 AM, "Hannes Tschofenig" wrote: >>>>>> >>>>>>> >That's inline with my thinking as well. >>>>>>> > >>>>>>> >And: I had also noticed the terminology issue; there is room for wording >>>>>>> >changes here and there. >>>>>> >>>>>> >>>>>> There is, naturally, a similar issue in SAML-EC with the subject >>>>>> confirmation being the determinant. I did build in some degree of >>>>>> negotiation already, because some of it is inherited from the HTTP use >>>>>> case on which the message exchange is inherited, but it does have the >>>>>> problem that you have to dig into the exchange to know which one is >>>>>> involved. >>>>>> >>>>>> -- Scott >>>>>> From wmills@yahoo-inc.com Fri Aug 24 10:29:51 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867E621F8713 for ; Fri, 24 Aug 2012 10:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.559 X-Spam-Level: X-Spam-Status: No, score=-17.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 87X5wJHiq3Np for ; Fri, 24 Aug 2012 10:29:50 -0700 (PDT) Received: from nm4-vm0.bullet.mail.ac4.yahoo.com (nm4-vm0.bullet.mail.ac4.yahoo.com [98.139.53.206]) by ietfa.amsl.com (Postfix) with SMTP id 3DA0F21F86CB for ; Fri, 24 Aug 2012 10:29:50 -0700 (PDT) Received: from [98.139.52.194] by nm4.bullet.mail.ac4.yahoo.com with NNFMP; 24 Aug 2012 17:29:46 -0000 Received: from [98.139.52.138] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 24 Aug 2012 17:29:46 -0000 Received: from [127.0.0.1] by omp1021.mail.ac4.yahoo.com with NNFMP; 24 Aug 2012 17:29:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 520756.18061.bm@omp1021.mail.ac4.yahoo.com Received: (qmail 41052 invoked by uid 60001); 24 Aug 2012 17:29:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345829385; bh=ykB627gnsjvm3e1x+KK5BhhCICSW81FU2Hmt2MBMG50=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YFX5WBbYVMaLQ1ob3Xv9lSLIFqXaJKTzl14q/sd4VC2h43fBP1tGyNvIa3HjmH7CdUe4kfECisKJ8tfrYU6/a5+X4oTljTEh1l4gQllhNDaH0VSkS4GikjEjbHDSaaEnVA2q2uTXxRfXDQb7uV0grtxDzNlPdxqwGk0XQFpOYi0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tLAwv9WlScoKQVCYmipaBFXKM3CwjX0hawF2x7VcEXtik6JIK+hX3+cV4i9Gc2AYnji7x/hA/SLrih4u2Ir21cg4D/lXcUkg3UlmPeud+XQa7CDs/nmzGnuP6VRyltBMfYlPtW2SoFTTcHtWoDLSHJ/pjR3tIu+2/rjuwxSNsUQ=; X-YMail-OSG: o3.FsAoVM1mcTb3X2XjEHgYDiuAFBYPvFNCeIDUANxtehbo rwnA7CbyTKMN47Cyud.kqSmnVmvnH5ahvd1GmTXE1A0uMjt0OwlKSsyswbak 7DaIGf3DCs8wqFWRGXWSNsLV610H.vyIXpwp7Chr8JP.UeZzMbi3ZYRE6r6I aXsvT8Gz2RoCSU3ZfXJAsR2WHHKc8T9kBYQk84Y.b1mrtjyqIbjSbRIhjPpL QFoaiADLFcz6YEafryJg60fRKntAVxP_io9UxWCURhdBaest5ILi2kmkJwqQ .7QdcekurwjBQDve4bd1MYRiLWck2OhvWKCYmHxSVfshjxR_7BmR34sqI9ul cbs3HAldSiOm9_8q6yqU7LG4J1Uz6.tRcfsbyGGJ7OwH6VmDCQGerNV3_Mka owCU_CC4iFBQ5foErMHGUJ0VCYjAP8CDyV7sRg0BmWqYaEXYkqciypJuUkTj IRS1S Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Fri, 24 Aug 2012 10:29:45 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <87fw7cah2o.fsf@latte.josefsson.org> Message-ID: <1345829385.29688.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Fri, 24 Aug 2012 10:29:45 -0700 (PDT) From: William Mills To: Simon Josefsson , Hannes Tschofenig In-Reply-To: <87fw7cah2o.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-2137945564-1345829385=:29688" Cc: "kitten@ietf.org" Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:29:51 -0000 ---551393103-2137945564-1345829385=:29688 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Updated to 3 OID's required, thank you.=A0 Is there a specific registry pro= cess, or does the RFC editor take care of that?=0A=0A=0A=0A=0A=0A>_________= _______________________=0A> From: Simon Josefsson =0A>= To: Hannes Tschofenig =0A>Cc: kitten@ietf.org = =0A>Sent: Friday, August 24, 2012 12:23 AM=0A>Subject: Re: [kitten] OAuth S= ASL draft -04=0A> =0A>I have a mild preference for trying this approach too= .=A0 However, doesn't=0A>this suggest that there should be a separate OID f= or the GSS-API=0A>mechanism side of each SASL mechanism?=A0 I think so.=0A>= =0A>Further, the -05 document just specify OAUTHBEARER, OAUTH10A, and=0A>OA= UTH10A-PLUS right now.=0A>=0A>/Simon=0A>=0A>Hannes Tschofenig writes:=0A>=0A>> I think it is useful to have this list (CB = and non-CB-based variants) to=0A>> avoid the trial-and-error approach.=0A>>= =0A>> On 8/23/12 7:38 PM, "ext Ryan Troll" wrote:=0A>= >=0A>>> No, I was alluding to a channel-binding enabled version of each pre= vious=0A>>> token. =A0For example "OAUTH2MAC", "OAUTH2MAC-PLUS", "OAUTH2BEA= RER", and=0A>>> "OAUTH2BEARER-PLUS", as draft -05 outlines.=0A>>> =0A>>> -R= =0A>>> =0A>>> On Thu, Aug 23, 2012 at 2:20 AM, Alexey Melnikov =0A>>> wrote:=0A>>>>=A0 =A0 =0A>>>>=A0 =0A>>>> On 22/08/2012= 17:23, Ryan Troll wrote:=0A>>>>=A0 =0A>>>>=A0 =0A>>>>> I vote for having s= eparate mechanisms for OAUTH2MAC, OAUTH2BEARER,=0A>>>>> channel-binding ver= sions, etc.=0A>>>>=A0 Just to clarify: I hope you are not recommending to h= ave a separate OAUTH=0A>>>> SASL mechanism for each channel binding type. T= hat would make the list of=0A>>>> SASL mechanisms unmanageable.=0A>>>>=A0 (= Having separate mechanisms for MAC and BEARER seem to make sense, IMHO. But= =0A>>>> no strong preferences.)=0A>>>> =0A>>>>=A0 =0A>>>>>=A0 =0A>>>>> Nego= tiations within a SASL mechanism, which this is leading towards, doesn't=0A= >>>>> sound good. =A0By letting clients know exactly which tokens are suppo= rted=0A>>>>> up-front, clients are able to better choose, and understand th= e implications=0A>>>>> of those choices.=0A>>>>>=A0 =0A>>>>> =0A>>>>>=A0 = =0A>>>>>=A0 =0A>>>>> This should also allow us to remove the error-message-= in-server-challenge=0A>>>>> and subsequent empty-client-challenge-response = upon failure.=0A>>>>>=A0 =0A>>>>> =0A>>>>>=A0 =0A>>>>>=A0 =0A>>>>> -R=0A>>>= >>=A0 =0A>>>>> =0A>>>>>=A0 =0A>>>>>=A0 =0A>>>>> =0A>>>>>=A0 =0A>>>>>=A0 On = Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott wrote:=0A>>>= >>=A0 =0A>>>>>>=A0 =0A>>>>>> On 8/22/12 3:52 AM, "Hannes Tschofenig" wrote:=0A>>>>>>=A0 =0A>>>>>>>=A0 >That's inline with = my thinking as well.=0A>>>>>>>=A0 >=0A>>>>>>>=A0 >And: I had also noticed t= he terminology issue; there is room for wording=0A>>>>>>>=A0 >changes here = and there.=0A>>>>>>=A0 =0A>>>>>>=A0 =0A>>>>>>=A0 There is, naturally, a sim= ilar issue in SAML-EC with the subject=0A>>>>>>=A0 confirmation being the d= eterminant. I did build in some degree of=0A>>>>>>=A0 negotiation already, = because some of it is inherited from the HTTP use=0A>>>>>>=A0 case on which= the message exchange is inherited, but it does have the=0A>>>>>>=A0 proble= m that you have to dig into the exchange to know which one is=0A>>>>>>=A0 i= nvolved.=0A>>>>>>=A0 =0A>>>>>>=A0 -- Scott=0A>>>>>>=A0 =0A>>>>>>=A0 =0A>>>>= >> =0A>>>>>>=A0 _______________________________________________=0A>>>>>>=A0= Kitten mailing list=0A>>>>>>=A0 Kitten@ietf.org=0A>>>>>>=A0 https://www.ie= tf.org/mailman/listinfo/kitten=0A>>>>>>=A0 =0A>>>>>>=A0 =0A>>>>>>=A0 =0A>>>= >>=A0 =0A>>>>>=A0 =0A>>>>>=A0 =0A>>>>>=A0 =0A>>>>>=A0 =0A>>>>>=A0 =0A>>>>> = _______________________________________________=0A>>>>> Kitten mailing list= =0A>>>>> Kitten@ietf.org=0A>>>>> https://www.ietf.org/mailman/listinfo/kitt= en=0A>>>>>=A0 =0A>>>>=A0 =0A>>>>=A0 =0A>>>>=A0 =0A>>>> =0A>>>> ____________= ___________________________________=0A>>>> Kitten mailing list=0A>>>> Kitte= n@ietf.org=0A>>>> https://www.ietf.org/mailman/listinfo/kitten=0A>>>> =0A>>= > =0A>>> =0A>>> =0A>>> _______________________________________________=0A>>= > Kitten mailing list=0A>>> Kitten@ietf.org=0A>>> https://www.ietf.org/mail= man/listinfo/kitten=0A>>=0A>> _____________________________________________= __=0A>> Kitten mailing list=0A>> Kitten@ietf.org=0A>> https://www.ietf.org/= mailman/listinfo/kitten=0A>_______________________________________________= =0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/= listinfo/kitten=0A>=0A>=0A> ---551393103-2137945564-1345829385=:29688 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Updated t= o 3 OID's required, thank you.  Is there a specific registry process, = or does the RFC editor take care of that?


=
From: Simon Josefsson = <simon@josefsson.org>
To: Hannes Tschofenig <Hannes.Tschofenig@nsn.com>
Cc: kitten@ietf.org
Sent: Friday, August 24, 2012 12:2= 3 AM
Subject: Re: [kit= ten] OAuth SASL draft -04

I have a mild preference f= or trying this approach too.  However, doesn't
this suggest that th= ere should be a separate OID for the GSS-API
mechanism side of each SASL= mechanism?  I think so.

Further, the -05 document just specify= OAUTHBEARER, OAUTH10A, and
OAUTH10A-PLUS right now.

/Simon
Hannes Tschofenig <Hannes.Tschofenig@nsn.com> wr= ites:

> I think it is useful to have this list (CB and non-CB-bas= ed variants) to
> avoid the trial-and-error approach.
>
>= On 8/23/12 7:38 PM, "ext Ryan Troll" <rtroll@googlers.com> wrote:
>
>> No, I was alluding to a channel-binding enabled= version of each previous
>> token.  For example "OAUTH2MAC",= "OAUTH2MAC-PLUS", "OAUTH2BEARER", and
>> "OAUTH2BEARER-PLUS", as = draft -05 outlines.
>>
>> -R
>>
>> On= Thu, Aug 23, 2012 at 2:20 AM, Alexey Melnikov <alexey.me= lnikov@isode.com>
>> wrote:
>>>    <= br>>>> 
>>> On 22/08/2012 17:23, Ryan Troll wrot= e:
>>> 
>>> 
>>>> I vote= for having separate mechanisms for OAUTH2MAC, OAUTH2BEARER,
>>>= ;> channel-binding versions, etc.
>>>  Just to clarify:= I hope you are not recommending to have a separate OAUTH
>>> S= ASL mechanism for each channel binding type. That would make the list of
>>> SASL mechanisms unmanageable.
>>>  (Ha= ving separate mechanisms for MAC and BEARER seem to make sense, IMHO. But>>> no strong preferences.)
>>>
>>>&nbs= p;
>>>> 
>>>> Negotiations within a SA= SL mechanism, which this is leading towards, doesn't
>>>> so= und good.  By letting clients know exactly which tokens are supported<= br>>>>> up-front, clients are able to better choose, and unders= tand the implications
>>>> of those choices.
>>>= > 
>>>>
>>>> 
>>>= > 
>>>> This should also allow us to remove the err= or-message-in-server-challenge
>>>> and subsequent empty-cli= ent-challenge-response upon failure.
>>>> 
>>= >>
>>>> 
>>>> 
>>>> -R
>>>> 
>>>> >>>> 
>>>> 
>>>> >>>> 
>>>>  On Wed, Aug 22, 2012 at = 7:42 AM, Cantor, Scott <cantor.2@osu.edu> wrote:
>>>>=  
>>>>> 
>>>>> On 8/22/12 3= :52 AM, "Hannes Tschofenig" <hannes.tschofenig@gmx.net> wrote:
>>>>> 
>>>>>>&nbs= p; >That's inline with my thinking as well.
>>>>>>&= nbsp; >
>>>>>>  >And: I had also noticed th= e terminology issue; there is room for wording
>>>>>>&= nbsp; >changes here and there.
>>>>> 
>>>>> 
>>>>>  There is, na= turally, a similar issue in SAML-EC with the subject
>>>>>= ;  confirmation being the determinant. I did build in some degree of>>>>>  negotiation already, because some of it is inh= erited from the HTTP use
>>>>>  case on which the me= ssage exchange is inherited, but it does have the
>>>>>&n= bsp; problem that you have to dig into the exchange to know which one is>>>>>  involved.
>>>>> 
>= ;>>>>  -- Scott
>>>>> 
>>= ;>>> 
>>>>>
>>>>> = _______________________________________________
>>>>>&nb= sp; Kitten mailing list
>>>>>  Kitten@ietf.org
>>>>>= ;  https://www.ietf.org/mailman/listinfo/kitten
>>>>= ;> 
>>>>> 
>>>>>  <= br>>>>> 
>>>> 
>>>>&n= bsp;
>>>> 
>>>> 
>>>= ;> 
>>>> __________________________________________= _____
>>>> Kitten mailing list
>>>> Kitten@ietf.or= g
>>>> https://www.ietf.org/mailman/listinfo/kitten<= br>>>>> 
>>> 
>>>  >>> 
>>>
>>> _______________________________________________
>>> Kitten mai= ling list
>>> Kitten@ietf.org
>>> https://www.ietf.o= rg/mailman/listinfo/kitten
>>>
>>
>> >>
>> _______________________________________________
= >> Kitten mailing list
>> Kitten@ietf.org
>> https:/= /www.ietf.org/mailman/listinfo/kitten
>
> _________________= ______________________________
> Kitten mailing list
> Kitten@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/kitten
____= ___________________________________________
Kitten mailing list
Kitten@iet= f.org
https://www.ietf.org/mailman/listinfo/kitten


<= /div>
To be hon= est, the gs2-header looks really annoying to parse.  It's 2 or 3 field= s and the termination of the second field is either the comma or just the e= nd of an authz ID.  It needs some boundary between that and the first = key name.


From: Simon Josefsson <simon@josefsson.org>
= To: William Mills <wmills@yahoo-inc.com>
Cc:= "kitten@ietf.org" <kitten@ietf.org>
Sent: Thursday, August 23, 2012 12:47 AM=
Subject: Re: gs2-head= er language Re: I-D Action: draft-ietf-kitten-sasl-oauth-04.txt
=

William Mills <wmills@yahoo-inc.com> writes:
=
> The %x01 after the gs2 header could stay, but it would be better i= f it
> could go away.  It's only there to provide an easy termin= ator to the
> gs2-header.  A leading %x01 here might confuse som= e implementers.
>
> Is it a problem?  Nothing should add i= t back.

I'd say remove it -- the gs2-header is self-contained and th= ere is no
ambiguity in when it ends.

/Simon


---551393103-2137945564-1345829385=:29688-- From wmills@yahoo-inc.com Fri Aug 24 10:49:02 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3CB21F86C7 for ; Fri, 24 Aug 2012 10:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.559 X-Spam-Level: X-Spam-Status: No, score=-17.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 TmueQgPKm36F for ; Fri, 24 Aug 2012 10:49:01 -0700 (PDT) Received: from nm12.bullet.mail.sp2.yahoo.com (nm12.bullet.mail.sp2.yahoo.com [98.139.91.82]) by ietfa.amsl.com (Postfix) with SMTP id 88C2521F86BE for ; Fri, 24 Aug 2012 10:49:01 -0700 (PDT) Received: from [72.30.22.93] by nm12.bullet.mail.sp2.yahoo.com with NNFMP; 24 Aug 2012 17:48:58 -0000 Received: from [72.30.22.202] by tm15.bullet.mail.sp2.yahoo.com with NNFMP; 24 Aug 2012 17:48:58 -0000 Received: from [127.0.0.1] by omp1064.mail.sp2.yahoo.com with NNFMP; 24 Aug 2012 17:48:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 359202.69102.bm@omp1064.mail.sp2.yahoo.com Received: (qmail 52796 invoked by uid 60001); 24 Aug 2012 17:48:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345830537; bh=63l/BLla4h7z1DE7BNX9t1ihtCRukDhrZ6F+K1mEYUU=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=pdVFuPv3+aJJrWza5yNmNkb0pGDQlSymR/hHk+V5dGmOSTi6tgydWHzi4QchwJ9qGrS5ZwTQQVRM0vXTF6J2gFlIclNfTJCpm23Z+1Y96Pilu4N1SMwA70u+h0y34dmjJDMg8LmuR5E9hcBuAMYPck7OG5aBouf+hNhlVvciaos= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=WQjhtwq9YnOEbFLbuO4dPeH3Q4Pevy5hxn+aajt0SDAWBZ6rx4G+gp/dLUFGP+mtLsI+pmDvoyU0uzNN6VYu1+caSj6eim35SFvT3CSG+/42zq47Ge0cIcbS3qBOqenuzMxVNNBErOTpYzMCM8XxfIMcSp1xieKAdt+5qjYXpuE=; X-YMail-OSG: ieFuRjkVM1mjxk29dPm6ty8jNBYfxc3FjUMod82IqLBZ959 HUZzNXiH7Prn5g79S3L6ucVIrrvNM3JLE4VtEXoUNb0ewz8MICUnl5qlzC_B uC3OBK9Fr1TvSLymYCuocA_JPXPChOvKpjL9vHJX1JNvAD92XhxiafbbH_KS Rgv2sRaTPRoJ5hEdyQNDSUgsFfHZSLkb8ZBgJzk23I0sgeXqpU5n3l6ZvpY0 oODwaTN1PqhDl6QywPw_G1Z7RY1Mu_7coB0Ql8RR.lGfiV185yAEDhQfqcPy AddRREO5_Utoc21RyGUpigZhNCDBurKNcDTKAJ5Z48eFh3wzMX4BrUNjiflR NnxzWvmBkVopZt2uNbSOdcxDFNjjGk3f2W5skdAD_DBRxnlD88u2xsc7dRhS U..EYTXlpt._QbXo_E15DkhxoBO9qQffr9a1LYCWPmi8y6G0SKFUCwYMG0v5 SMlsIGzoSerViHQ-- Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Fri, 24 Aug 2012 10:48:57 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <87fw7cah2o.fsf@latte.josefsson.org> <1345829385.29688.YahooMailNeo@web31805.mail.mud.yahoo.com> Message-ID: <1345830537.36750.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Fri, 24 Aug 2012 10:48:57 -0700 (PDT) From: William Mills To: "kitten@ietf.org" In-Reply-To: <1345829385.29688.YahooMailNeo@web31805.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-541554169-1345830537=:36750" Subject: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:49:02 -0000 ---551393103-541554169-1345830537=:36750 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable A new question in play, should the kv separator be converted from %x01 to "= ," which makes it more compatible with the GS2 parsers out there?=0A=0AI am= not in favor of this, because one of the data elements to be carried is th= e HTTP authentication header payload in which comma might apprear, but cont= rol characters are not allowed.=A0 I picked a control character specificall= y for this reason.=0A=0ARegards,=0A=0A-bill=0A ---551393103-541554169-1345830537=:36750 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --764183289-97885750-1346212158=:26772-- From lukeh@padl.com Tue Aug 28 20:50:33 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1619211E80D3 for ; Tue, 28 Aug 2012 20:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] 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 LYuMka1D0qF4 for ; Tue, 28 Aug 2012 20:50:32 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6D61A11E80A4 for ; Tue, 28 Aug 2012 20:50:32 -0700 (PDT) Received: by us.padl.com with ESMTP id q7T3oQeY011417; Tue, 28 Aug 2012 23:50:28 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: Date: Wed, 29 Aug 2012 13:50:22 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <23FE94E4-0B7A-449B-BE36-6551E9E0940D@padl.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> To: Nico Williams X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 03:50:33 -0000 > I'm confused. As a SASL/GS2 mechanism this would be definition carry > an [optional] authz-id: it's in the gs2-header. >=20 > So, of course the OAuth SASL/GS2 mechanism supports an authz-id > assertion. It must. I think the question has reframed itself as: is this a SASL mechanism = that looks a bit like a GS2 mechanism but isn't; or are we just not yet = on the same page in terms of understanding what a GS2 mechanism is? -- Luke= From nico@cryptonector.com Tue Aug 28 20:54:24 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8EE21F853A for ; Tue, 28 Aug 2012 20:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.009 X-Spam-Level: X-Spam-Status: No, score=-3.009 tagged_above=-999 required=5 tests=[AWL=-1.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 PujaQz5Pmedr for ; Tue, 28 Aug 2012 20:54:24 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1F83C21F8535 for ; Tue, 28 Aug 2012 20:54:24 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id A8B942F4059 for ; Tue, 28 Aug 2012 20:54:23 -0700 (PDT) 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; s=cryptonector.com; bh=A/y8agRFf98INcUQz1iG M5ZWKnY=; b=jAmp95TB8kiLGWG7HN+M9hv5YrCqrEbC2kX4iQIst11IQwY3yFj+ f6wMcnZcDCgQxd+HEZO/7N83LIC0sP+vs5YinUM8GTnOoMYAA9BV4qt1emdPf/V/ W5kQLXXCey/tkY6nBmtdWBf1cFIypk4b4cRX8MAp8RoMFSrj7fL8Ed0= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 8E8852F401D for ; Tue, 28 Aug 2012 20:54:23 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so354821pbb.31 for ; Tue, 28 Aug 2012 20:54:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.87.227 with SMTP id bb3mr662103pab.3.1346212463255; Tue, 28 Aug 2012 20:54:23 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 28 Aug 2012 20:54:23 -0700 (PDT) In-Reply-To: <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Tue, 28 Aug 2012 22:54:23 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 03:54:25 -0000 On Tue, Aug 28, 2012 at 10:49 PM, William Mills wrote: > Yes, what you are asking for is something I explicitly avoided and think we > should continue to avoid, because for things like OAuth 1.0a you have to > define a URI that can be signed which includes the name, and deciding the > correct URI format for an arbitrary resource to be authenticate with SASL > isn't solved. > > It also would require is to be able to present those URIs to an OAuth > authorization endpoint to be explicitly approved. > > I'm avoiding having to try to define a URI for POP, IMAP, and SMTP-send-mail > like the plague. OK, let's say that there is a GSS mechanism such that it makes no sense to assert an authz-id when using it as a SASL/GS2 mechanism. What's the problem? Well, we need to say what happens if an authz-id is asserted nonetheless. We can say that the server "MUST fail the authentication attempt", or that it "MUST ignore the authz-id assertion", or perhaps something else. Nico -- From lukeh@padl.com Tue Aug 28 20:59:00 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7106D21F8552 for ; Tue, 28 Aug 2012 20:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 N9zpM8L1Tqn9 for ; Tue, 28 Aug 2012 20:58:59 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3F51721F8551 for ; Tue, 28 Aug 2012 20:58:59 -0700 (PDT) Received: by us.padl.com with ESMTP id q7T3wsRC011582; Tue, 28 Aug 2012 23:58:57 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_773B786C-0212-4950-9F73-2998A0AC4ABC" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Wed, 29 Aug 2012 13:58:50 +1000 Message-Id: <078CCB8F-903D-463D-AC2A-ACC48821E9ED@padl.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 03:59:00 -0000 --Apple-Mail=_773B786C-0212-4950-9F73-2998A0AC4ABC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I probably don't understand enough about OAuth, but in my experience = with SASL, whether a given authentication identity can act as a = particular authorisation identity is decided by the application, and = typically the authorisation identities look like local system = identifiers (e.g. "u:lukeh") or DNs (e.g. "dn:cn=3DLuke Howard,o=3DPADL").= The authentication mechanism itself does not do anything beyond = securely transport the authorisation identity, and make it available to = the SASL layer/application. However I may be conflating implementation experience with a more = abstract perspective. On 29/08/2012, at 1:49 PM, William Mills wrote: > Yes, what you are asking for is something I explicitly avoided and = think we should continue to avoid, because for things like OAuth 1.0a = you have to define a URI that can be signed which includes the name, and = deciding the correct URI format for an arbitrary resource to be = authenticate with SASL isn't solved. >=20 > It also would require is to be able to present those URIs to an OAuth = authorization endpoint to be explicitly approved. >=20 -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com --Apple-Mail=_773B786C-0212-4950-9F73-2998A0AC4ABC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = probably don't understand enough about OAuth, but in my experience with = SASL, whether a given authentication identity can act as a particular = authorisation identity is decided by the application, and typically the = authorisation identities look like local system identifiers (e.g. = "u:lukeh") or DNs (e.g. "dn:cn=3DLuke Howard,o=3DPADL"). The = authentication mechanism itself does not do anything beyond securely = transport the authorisation identity, and make it available to the SASL = layer/application.

However I may be conflating = implementation experience with a more abstract = perspective.

On 29/08/2012, at 1:49 PM, = William Mills <wmills@yahoo-inc.com> = wrote:

Yes, what you are asking for is something I explicitly avoided = and think we should continue to avoid, because for things like OAuth = 1.0a you have to define a URI that can be signed which includes the = name, and deciding the correct URI format for an arbitrary resource to = be authenticate with SASL isn't solved.

It also would require is to be = able to present those URIs to an OAuth authorization endpoint to be = explicitly approved.



= --Apple-Mail=_773B786C-0212-4950-9F73-2998A0AC4ABC-- From cantor.2@osu.edu Tue Aug 28 20:59:06 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423C421E8037 for ; Tue, 28 Aug 2012 20:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 SUF5lZo8bCwI for ; Tue, 28 Aug 2012 20:59:05 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7F611E80C5 for ; Tue, 28 Aug 2012 20:59:05 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7T3x2Y4004463; Tue, 28 Aug 2012 23:59:03 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.02.0309.002; Tue, 28 Aug 2012 23:59:02 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNhZn9rryqe/0SvUidbPxlBohQlJdwKgaA Date: Wed, 29 Aug 2012 03:59:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.74.80.179] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 03:59:06 -0000 On 8/28/12 11:54 PM, "Nico Williams" wrote: > >OK, let's say that there is a GSS mechanism such that it makes no >sense to assert an authz-id when using it as a SASL/GS2 mechanism. I don't think there's any obvious reason for that here. >What's the problem? Well, we need to say what happens if an authz-id >is asserted nonetheless. We can say that the server "MUST fail the >authentication attempt", or that it "MUST ignore the authz-id >assertion", or perhaps something else. As I suspected, and Simon/Luke noted, you can't mandate that without breaking existing GS2 code. -- Scott From cantor.2@osu.edu Tue Aug 28 21:00:56 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9F021F855A for ; Tue, 28 Aug 2012 21:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 KxCzTxokD2iH for ; Tue, 28 Aug 2012 21:00:56 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id EA00121F8557 for ; Tue, 28 Aug 2012 21:00:55 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7T40rCt005062; Wed, 29 Aug 2012 00:00:54 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.02.0309.002; Wed, 29 Aug 2012 00:00:54 -0400 From: "Cantor, Scott" To: William Mills , Simon Josefsson Thread-Topic: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNhXExPPnDfIQILk6pd6AQN0mLIJdwarMA///AJYA= Date: Wed, 29 Aug 2012 04:00:52 +0000 Message-ID: In-Reply-To: <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.74.80.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <03EAECEF108F284C8A2C3E64EC62EC7A@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:00:56 -0000 On 8/28/12 11:49 PM, "William Mills" wrote: > >Yes, what you are asking for is something I explicitly avoided and think >we should continue to avoid, because for things like OAuth 1.0a you have >to define a URI that can be signed which includes the name, and deciding >the correct URI format for an arbitrary > resource to be authenticate with SASL isn't solved. Can you explain why? That sounds like you're talking about the server's identity, and this is about the client's claimed identity. >I'm avoiding having to try to define a URI for POP, IMAP, and >SMTP-send-mail like the plague. I don't see why that is needed here. I agree that that's bad. I almost ended up with that problem and worked to avoid it. -- Scott From nico@cryptonector.com Tue Aug 28 21:05:16 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E5B11E80BA for ; Tue, 28 Aug 2012 21:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[AWL=-1.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 cBphBA4AkQgA for ; Tue, 28 Aug 2012 21:05:16 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 06FBF11E808A for ; Tue, 28 Aug 2012 21:05:16 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id BAD16594062 for ; Tue, 28 Aug 2012 21:05:15 -0700 (PDT) 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; s=cryptonector.com; bh=a983I5jA2nTGaeg2cgr0 oaC18Q8=; b=bbBTIknKRqcoA8oH3WIAe03rT42dh2mwb5TZ+dPvqP13dfqlsHx6 jBBfJCh0eHUPS/HazMyo4B/MjXgWXDhQcwWjOkpFxcI/zPDHPTKk9EHk3pBoW1zc ZbNZ0tuxXw222AdkYFjXxxYBFPNbAGhUtPwwYxHL5Cnbp4Xi0KZJgVw= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 9EF1B594061 for ; Tue, 28 Aug 2012 21:05:15 -0700 (PDT) Received: by dadf8 with SMTP id f8so92362dad.31 for ; Tue, 28 Aug 2012 21:05:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.73 with SMTP id ra9mr1489253pbc.85.1346213115186; Tue, 28 Aug 2012 21:05:15 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 28 Aug 2012 21:05:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Aug 2012 23:05:15 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:05:16 -0000 On Tue, Aug 28, 2012 at 10:59 PM, Cantor, Scott wrote: > On 8/28/12 11:54 PM, "Nico Williams" wrote: >> >>OK, let's say that there is a GSS mechanism such that it makes no >>sense to assert an authz-id when using it as a SASL/GS2 mechanism. > > I don't think there's any obvious reason for that here. I don't see that either. Just trying to think this through. >>What's the problem? Well, we need to say what happens if an authz-id >>is asserted nonetheless. We can say that the server "MUST fail the >>authentication attempt", or that it "MUST ignore the authz-id >>assertion", or perhaps something else. > > As I suspected, and Simon/Luke noted, you can't mandate that without > breaking existing GS2 code. Good point. I think the best thing to do is to say that this is a SASL/GS2 (and therefore GSS) mechanism and then say *noting* about the SASL authz-id. Nico -- From lukeh@padl.com Tue Aug 28 21:07:27 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB15A11E80FE for ; Tue, 28 Aug 2012 21:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] 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 NEfJTPllvogx for ; Tue, 28 Aug 2012 21:07:27 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 290B011E80E7 for ; Tue, 28 Aug 2012 21:07:27 -0700 (PDT) Received: by us.padl.com with ESMTP id q7T46KNT011784; Wed, 29 Aug 2012 00:07:21 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: Date: Wed, 29 Aug 2012 14:07:19 +1000 Content-Transfer-Encoding: 7bit Message-Id: References: To: Nico Williams X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:07:27 -0000 On 29/08/2012, at 2:05 PM, Nico Williams wrote: > I think the best thing to do is to say that this is a SASL/GS2 (and > therefore GSS) mechanism and then say *noting* about the SASL > authz-id. Agreed. -- Luke From nico@cryptonector.com Tue Aug 28 21:08:32 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4742E11E80E7 for ; Tue, 28 Aug 2012 21:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.991 X-Spam-Level: X-Spam-Status: No, score=-2.991 tagged_above=-999 required=5 tests=[AWL=-1.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 h0PV8CnsKQ+Q for ; Tue, 28 Aug 2012 21:08:31 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE6211E80BA for ; Tue, 28 Aug 2012 21:08:31 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 445E43B805C for ; Tue, 28 Aug 2012 21:08:31 -0700 (PDT) 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; s=cryptonector.com; bh=NPOCGqVVgNx9tyx7y3Wc CS1dDG4=; b=uvyDyX+8kxgKHvyxr2Y7bZIAWCAodwNqOgDmazcPlalZunf3Mfeo P5GDdPJ/dMGeZfJxAfDHh1oyuD3fKF7QzpRMoalT7ZBL75i4VMBSlfh2+SihSa3d RuJnPy0YqUHtWJtEleKZaYkeLdpuYYv9sJL+YS8ZFJtmksx8QZSTREA= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 25D6C3B805B for ; Tue, 28 Aug 2012 21:08:31 -0700 (PDT) Received: by dadf8 with SMTP id f8so93847dad.31 for ; Tue, 28 Aug 2012 21:08:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.73 with SMTP id ra9mr1506406pbc.85.1346213310779; Tue, 28 Aug 2012 21:08:30 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 28 Aug 2012 21:08:30 -0700 (PDT) In-Reply-To: <078CCB8F-903D-463D-AC2A-ACC48821E9ED@padl.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <078CCB8F-903D-463D-AC2A-ACC48821E9ED@padl.com> Date: Tue, 28 Aug 2012 23:08:30 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:08:32 -0000 On Tue, Aug 28, 2012 at 10:58 PM, Luke Howard wrote: > I probably don't understand enough about OAuth, but in my experience with > SASL, whether a given authentication identity can act as a particular > authorisation identity is decided by the application, and typically the > authorisation identities look like local system identifiers (e.g. "u:lukeh") > or DNs (e.g. "dn:cn=Luke Howard,o=PADL"). The authentication mechanism > itself does not do anything beyond securely transport the authorisation > identity, and make it available to the SASL layer/application. > > However I may be conflating implementation experience with a more abstract > perspective. No, that's exactly right. I think William's concern may be that it may not be appropriate to use OAuth-authenticated entities this way since doing so may lose information about about constraints on authorization imposed by OAuth. However, I would say that William should not be so concerned. SASL says nothing about a fine-grained authorization model, and certainly does not preclude such a model. For example, GSS now doe shave a fine-grained authz model ("extended naming"), and a SASL/GS2 bridge implementation could simply expose that interface to applications. Nico -- From nico@cryptonector.com Tue Aug 28 21:10:42 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF4B21F84C2 for ; Tue, 28 Aug 2012 21:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.982 X-Spam-Level: X-Spam-Status: No, score=-2.982 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 k5Heeaq06xfE for ; Tue, 28 Aug 2012 21:10:42 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 422A321F84B5 for ; Tue, 28 Aug 2012 21:10:42 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id D21C121DE58 for ; Tue, 28 Aug 2012 21:10:41 -0700 (PDT) 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; s=cryptonector.com; bh=Y7Fo/7JDuizyP7C6KSck hJpZnFY=; b=gPReRQK7AbkGtmwxtJhzqpvrGOeCJYUYWJ/eR5fbZdgxqpTFfVIp MGVk2lvUTWpTzKINx7x8ll0qN4Qr2fx3EAWcmX4YD4rqp0iNpGVL75tqwydM95mj vUnrNTeK6UiaJt+Jv65I9ROKbmNPnxJ8oKXS/wfkjxYXPk8RjVMjB1I= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id AEF4421DE57 for ; Tue, 28 Aug 2012 21:10:41 -0700 (PDT) Received: by dadf8 with SMTP id f8so94831dad.31 for ; Tue, 28 Aug 2012 21:10:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.194 with SMTP id d2mr608048pax.42.1346213441391; Tue, 28 Aug 2012 21:10:41 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 28 Aug 2012 21:10:41 -0700 (PDT) In-Reply-To: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <078CCB8F-903D-463D-AC2A-ACC48821E9ED@padl.com> Date: Tue, 28 Aug 2012 23:10:41 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:10:42 -0000 On Tue, Aug 28, 2012 at 11:08 PM, Nico Williams wrote: > I think William's concern may be that it may not be appropriate to use > OAuth-authenticated entities this way since doing so may lose > information about about constraints on authorization imposed by OAuth. > > However, I would say that William should not be so concerned. SASL > says nothing about a fine-grained authorization model, and certainly > does not preclude such a model. For example, GSS now doe shave a > fine-grained authz model ("extended naming"), and a SASL/GS2 bridge > implementation could simply expose that interface to applications. To complete the thought: SASL/GS2 should have said (and maybe should be updated to say) that an implementation SHOULD expose all the naming functionality of the GSS-API, including the GSS naming extensions. But I don't think we need to update SASL/GS2 to say that in order to get the OAuth mechanism specified. Nico -- From lukeh@padl.com Tue Aug 28 21:19:07 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7545F11E808A for ; Tue, 28 Aug 2012 21:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599] 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 3Bi2hSKiPx9O for ; Tue, 28 Aug 2012 21:19:07 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id D09D611E8097 for ; Tue, 28 Aug 2012 21:19:06 -0700 (PDT) Received: by us.padl.com with ESMTP id q7T4J0ar012078; Wed, 29 Aug 2012 00:19:03 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: Date: Wed, 29 Aug 2012 14:18:56 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <8407CFBD-E53E-4E9F-B5CF-4481CD8B5F6F@padl.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <078CCB8F-903D-463D-AC2A-ACC48821E9ED@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:19:07 -0000 On 29/08/2012, at 2:10 PM, Nico Williams wrote: > To complete the thought: SASL/GS2 should have said (and maybe should > be updated to say) that an implementation SHOULD expose all the naming > functionality of the GSS-API, including the GSS naming extensions. Getting distracted into implementations-ville, Cyrus SASL supports this = with the SASL_GSS_PEER_NAME property (this returns a gss_name_t object = that you can interrogate with naming extensions). -- Luke= From nico@cryptonector.com Tue Aug 28 21:23:08 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4305E11E80A4 for ; Tue, 28 Aug 2012 21:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ajvac27jrqAX for ; Tue, 28 Aug 2012 21:23:07 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id B875411E8097 for ; Tue, 28 Aug 2012 21:23:07 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 4C559438079 for ; Tue, 28 Aug 2012 21:23:07 -0700 (PDT) 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; s=cryptonector.com; bh=62O7d8ob+DDXK3z6/Qgg b1eKBvY=; b=t0SjMeMHY/lATL4k10ZyltwJ6e1035F9os99Ib6demGG2gt0Mb2T Ka8K9IPnzng4wvlz9cZUPoJ/SOWTFJqALe6bGlmE7R1OzhGGi6KXCLBV2FvGnioo OHnCtIuQXTTO4K/i5mWNYcFubjJV31A+6zOCjhD0chaSk7YnpRABP0w= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 320BC438072 for ; Tue, 28 Aug 2012 21:23:07 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so388047pbb.31 for ; Tue, 28 Aug 2012 21:23:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.73 with SMTP id ra9mr1580275pbc.85.1346214186884; Tue, 28 Aug 2012 21:23:06 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 28 Aug 2012 21:23:06 -0700 (PDT) In-Reply-To: <8407CFBD-E53E-4E9F-B5CF-4481CD8B5F6F@padl.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <078CCB8F-903D-463D-AC2A-ACC48821E9ED@padl.com> <8407CFBD-E53E-4E9F-B5CF-4481CD8B5F6F@padl.com> Date: Tue, 28 Aug 2012 23:23:06 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:23:08 -0000 On Tue, Aug 28, 2012 at 11:18 PM, Luke Howard wrote: > On 29/08/2012, at 2:10 PM, Nico Williams wrote: >> To complete the thought: SASL/GS2 should have said (and maybe should >> be updated to say) that an implementation SHOULD expose all the naming >> functionality of the GSS-API, including the GSS naming extensions. > > Getting distracted into implementations-ville, Cyrus SASL supports this with the SASL_GSS_PEER_NAME property (this returns a gss_name_t object that you can interrogate with naming extensions). Right, and that's perfect. Specification-wise it'd be nice if RFC5801 had said this, but I don't think we need it to *right now*. Nico -- From wmills@yahoo-inc.com Tue Aug 28 21:23:34 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CD411E80D3 for ; Tue, 28 Aug 2012 21:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.572 X-Spam-Level: X-Spam-Status: No, score=-17.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 TnDBrI9b1OLb for ; Tue, 28 Aug 2012 21:23:34 -0700 (PDT) Received: from nm26-vm0.bullet.mail.ac4.yahoo.com (nm26-vm0.bullet.mail.ac4.yahoo.com [98.139.52.242]) by ietfa.amsl.com (Postfix) with SMTP id CAD8C11E8097 for ; Tue, 28 Aug 2012 21:23:33 -0700 (PDT) Received: from [98.139.52.189] by nm26.bullet.mail.ac4.yahoo.com with NNFMP; 29 Aug 2012 04:23:28 -0000 Received: from [98.139.52.140] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 29 Aug 2012 04:23:28 -0000 Received: from [127.0.0.1] by omp1023.mail.ac4.yahoo.com with NNFMP; 29 Aug 2012 04:23:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 726244.66750.bm@omp1023.mail.ac4.yahoo.com Received: (qmail 23259 invoked by uid 60001); 29 Aug 2012 04:23:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346214208; bh=BtM8oSe0wA/ZQh6meGK6trQsBT2OaGW2ALZYJj9jhWs=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=E1AIYz33lhFvbKz1MDV1xZMat4XGqyEykvIietFUqE92T4CzYYGcjRcKbjtp23vAdWeNTQi1nBtYX2C5z0AueDeEnI7WKibXuxX0P/flsaI0j65acwnM/WmE/wCG5EwtDayJTaMxD8Sm9c2MHKUI9PQVODoM0TayGIakaUP4d5Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hYICRSNSjEtYz16Ex3/6Klw+evmD84uL5/Y7vEHrrCHccg4yQZfdeH+Uaw16D5WHwZTl3QJSK+ox+U5m7IIa/5qbx6OYIDNGt5E+0YkWW5sIH2AzR9o9emvSGxa8N1tuHTfWnUtVeQYt0gvvTZLCDtUap8maG6UPSVk1YIKwOz0=; X-YMail-OSG: egUF50EVM1ntwN_EJ1.iW6JU0Bmgbozzs8yfzQZXmEILNfd ._wHajZQLWT2a.P_dAdYSC4t0WuoCrWcxoEbRK1WbE9Qfd1tQrdympuYzNHF sXzqC_7zu78PePInNkxphpdwxfB2UCw7tnlMYRAwcfuw8tdQP2IkqBCmeWKy W0E2tTlf.ltc3JwIpCfx29uPVl2x8tDDjG9mrDIH8OtPCect73rgRE39YgAu Q97j4G1N8n6K_sxdosL0KxHBDmzuV5XuOZJT8e7r7sgVE8hgJfAgDIOF5n79 nz4GpHC_nWs9EfmJcEoI4qVsTbbtt2N9otD7d17QCBBHX1dzDPDMIApLr26_ hF3RrVuNWgBfzV4yEWzKU9ndkhiusnEih6T2hTC.WZXrJOQlogzGTHJ5DYNE 0W7Ff3kIGah0vY5Lxxt_LBa2_UgIB0967fOlLShktXMifJ6uS Received: from [99.31.212.42] by web31813.mail.mud.yahoo.com via HTTP; Tue, 28 Aug 2012 21:23:28 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> Message-ID: <1346214208.78462.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Tue, 28 Aug 2012 21:23:28 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Simon Josefsson In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-1749407437-1346214208=:78462" Cc: "kitten@ietf.org" Subject: [kitten] URis Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:23:35 -0000 --767760015-1749407437-1346214208=:78462 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Because OAuth is about granting access to a resource, and in many cases res= ources are represented as URIs.=A0 The=A0 access dance includes in some par= ts of the flow the URI of the resource for which access is being granted.= =A0 If we really go "there" then we need to be able to grant access to "sen= d mail as user@example.com", and that's completely different from mailto:us= er@example.com.=A0 We'd need to define something like mailfrom:user@example= .com.=A0 This is why I'm punting by mapping everything onto a stub HTTP URI= , because SASL exists in many places for which there is no defined URI.=0A= =0ADoes that explain it?=0A=0A=0A=0A=0A>________________________________=0A= > From: "Cantor, Scott" =0A>To: William Mills ; Simon Josefsson =0A>Cc: "kitten@ietf.org= " =0A>Sent: Tuesday, August 28, 2012 9:00 PM=0A>Subject: = Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>On 8/28/12 1= 1:49 PM, "William Mills" wrote:=0A>=0A>>=0A>>Yes, wh= at you are asking for is something I explicitly avoided and think=0A>>we sh= ould continue to avoid, because for things like OAuth 1.0a you have=0A>>to = define a URI that can be signed which includes the name, and deciding=0A>>t= he correct URI format for an arbitrary=0A>> resource to be authenticate wit= h SASL isn't solved.=0A>=0A>Can you explain why? That sounds like you're ta= lking about the server's=0A>identity, and this is about the client's claime= d identity.=0A>=0A>>I'm avoiding having to try to define a URI for POP, IMA= P, and=0A>>SMTP-send-mail like the plague.=0A>=0A>I don't see why that is n= eeded here. I agree that that's bad. I almost=0A>ended up with that problem= and worked to avoid it.=0A>=0A>-- Scott=0A>=0A>=0A>=0A> --767760015-1749407437-1346214208=:78462 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Because OAuth is about granting access to a resource, and= in many cases resources are represented as URIs.  The  access da= nce includes in some parts of the flow the URI of the resource for which ac= cess is being granted.  If we really go "there" then we need to be abl= e to grant access to "send mail as user@example.com", and that's completely= different from mailto:user@example.com.  We'd need to define somethin= g like mailfrom:user@example.com.  This is why I'm punting by mapping = everything onto a stub HTTP URI, because SASL exists in many places for whi= ch there is no defined URI.

Does that explain it?

From: "Cantor, Scott" <cantor= .2@osu.edu>
To: Wil= liam Mills <wmills@yahoo-inc.com>; Simon Josefsson <simon@josefsso= n.org>
Cc: "kitten@ietf.org"= <kitten@ietf.org>
Sent: Tuesday, August 28, 2012 9:00 PM
Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL = draft -05

On 8/28/12 11:49 PM, "William Mills" <<= a ymailto=3D"mailto:wmills@yahoo-inc.com" href=3D"mailto:wmills@yahoo-inc.c= om">wmills@yahoo-inc.com> wrote:

>
>Yes, what you ar= e asking for is something I explicitly avoided and think
>we should c= ontinue to avoid, because for things like OAuth 1.0a you have
>to def= ine a URI that can be signed which includes the name, and deciding
>t= he correct URI format for an arbitrary
> resource to be authenticate = with SASL isn't solved.

Can you explain why? That sounds like you're= talking about the server's
identity, and this is about the client's claimed identity.

>I'm avoiding having to try to define a URI fo= r POP, IMAP, and
>SMTP-send-mail like the plague.

I don't see = why that is needed here. I agree that that's bad. I almost
ended up with= that problem and worked to avoid it.

-- Scott



--767760015-1749407437-1346214208=:78462-- From cantor.2@osu.edu Tue Aug 28 21:31:38 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CAA11E80BA for ; Tue, 28 Aug 2012 21:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 WoPClZ+7c9m5 for ; Tue, 28 Aug 2012 21:31:37 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7643A21F847D for ; Tue, 28 Aug 2012 21:31:23 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7T4VLiF020843; Wed, 29 Aug 2012 00:31:22 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.02.0309.002; Wed, 29 Aug 2012 00:31:21 -0400 From: "Cantor, Scott" To: William Mills , Simon Josefsson Thread-Topic: URis Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNhXExPPnDfIQILk6pd6AQN0mLIJdwarMA///AJYCAAElnAP//vyIA Date: Wed, 29 Aug 2012 04:31:21 +0000 Message-ID: In-Reply-To: <1346214208.78462.YahooMailNeo@web31813.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.74.80.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <1259405D2BDAC240AAB8997A8933AD23@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] URis Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:31:38 -0000 On 8/29/12 12:23 AM, "William Mills" wrote: >Because OAuth is about granting access to a resource, and in many cases >resources are represented as URIs. The access dance includes in some >parts of the flow the URI of the resource for which access is being >granted. Yes. > If we really go "there" then we > need to be able to grant access to "send mail as user@example.com", and >that's completely different from mailto:user@example.com. I don't think we do. >We'd need to define something like mailfrom:user@example.com. This is >why I'm punting by mapping everything onto a stub HTTP URI, because SASL >exists in many places for which there is no defined URI. >Does that explain it? No. The OAuth layer shouldn't need to know anything about the information we're talking about whatsoever. It's client-asserted information to the server that is then evaluated by the server upon completion of the exchange. In most protocols it's going to be an ordinary, vanilla username. You are making the mistake of trying to tie the asserted identity into the OAuth token exchange so that it's backed by that mechanism, but you don't have to do that. -- Scott From cantor.2@osu.edu Tue Aug 28 21:33:11 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEA421F847F for ; Tue, 28 Aug 2012 21:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 H0Mf1QEuJxuJ for ; Tue, 28 Aug 2012 21:33:10 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD9721F847D for ; Tue, 28 Aug 2012 21:33:10 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7T4X8JY018771; Wed, 29 Aug 2012 00:33:08 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.02.0309.002; Wed, 29 Aug 2012 00:33:08 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNhZn9rryqe/0SvUidbPxlBohQlJdwKgaAgABE0ID//8S1AA== Date: Wed, 29 Aug 2012 04:33:08 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.74.80.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <47386FE06631A340BF29B5A70972C1FF@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:33:11 -0000 On 8/29/12 12:05 AM, "Nico Williams" wrote: > >I think the best thing to do is to say that this is a SASL/GS2 (and >therefore GSS) mechanism and then say *noting* about the SASL >authz-id. Just so it's clear from me, that was all I was expecting. -- Scott From wmills@yahoo-inc.com Tue Aug 28 21:34:57 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B803311E8097 for ; Tue, 28 Aug 2012 21:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.573 X-Spam-Level: X-Spam-Status: No, score=-17.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 9pVm-Fznme3y for ; Tue, 28 Aug 2012 21:34:54 -0700 (PDT) Received: from nm35-vm7.bullet.mail.bf1.yahoo.com (nm35-vm7.bullet.mail.bf1.yahoo.com [72.30.238.79]) by ietfa.amsl.com (Postfix) with SMTP id EF98321F8497 for ; Tue, 28 Aug 2012 21:34:53 -0700 (PDT) Received: from [98.139.212.144] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 29 Aug 2012 04:34:53 -0000 Received: from [98.139.212.226] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 29 Aug 2012 04:34:53 -0000 Received: from [127.0.0.1] by omp1035.mail.bf1.yahoo.com with NNFMP; 29 Aug 2012 04:34:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 30543.11482.bm@omp1035.mail.bf1.yahoo.com Received: (qmail 87840 invoked by uid 60001); 29 Aug 2012 04:34:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346214892; bh=J7/HGeRelin4zw5wT9qxY8F+23HPMHUu8aSDhsYPJN4=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jQtfabTX51cntruHQtv2H73juKpm/G+82uN4PI6IK5/2Qkyk1orWewGDv6KOniGx4pgdccstMJfygo7+irDJyZXkeUuv5BM9Uruv3BAB/Xwlh7Orml6R9VRRho/Kjt39q+Fyf6qhhR15zGgR5v4w/uZukUMv8nykzz9xm+5hCEg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=JbR5d1ZOWlG8zNj3sIgAN/qgmR+LEMwEdKyhLVnvgXuwPLO30HwL0VQ9bs8fCVyR7cRJ/L8Dv5YgB7O8hXQQEVZNg675Tr+5O84c+G7ZzDcXYRs4L0FnbsWw1iGsrOfyxQtniNmr1fjZFiqRqWB1Wnj3fpnBiGhq/yafSr9jk9k=; X-YMail-OSG: B1puZtEVM1nnqmq_.ATJP3H_bxoa5fgvzbwCf2DG2HpWeTp 2Xi3t6yXyYScvabgaNpdg8PS3vF2yitjo6DsCTJk4QzKCH6BCqgqHfkhSbVW 1uwlImw1RSzTuq3FnHbc48H1Vh5SfRaFUw1FwyCWYbu.RFOyjnwXKdnW24I0 8Y4DkvZlL9drb8b9LC7.WCrYQlvSNnqKNewkFwVt5uOuNYZ12f5ielzHvOhx h7lh9.qqYoIqAWFy1mFP9vworCgj7uEpYjivK.HIV_.ztWo32tBKx9C9RR8g nhZ5vQSPgOBXW.CAwZ_d2S2NzfzWwUlBRa3qEqVvoqiesXBB2GU.sd7pBOCO f2PhFH1YXSEjof8e4oJZiIjSgB3w3RNAdlr0lkx9bni.rWZ8jHo5mmfVTCmM NGOEcOTurIjZuxyauA5JJ6Co3Z5gP94aX6YJYqk6IPuw- Received: from [99.31.212.42] by web31804.mail.mud.yahoo.com via HTTP; Tue, 28 Aug 2012 21:34:52 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: Message-ID: <1346214892.84802.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Tue, 28 Aug 2012 21:34:52 -0700 (PDT) From: William Mills To: Nico Williams , "Cantor, Scott" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-1403400999-1346214892=:84802" Cc: "kitten@ietf.org" Subject: [kitten] Identities Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:34:57 -0000 --835683298-1403400999-1346214892=:84802 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Just to be clear it is possible in OAuth to have *both* a client ID which w= ould equate to an authZ ID and a ID in the token which would be an authN ID= .=A0=A0 All this info might be carried in a Bearer token, or explicitly cal= led out in OAuth 1.0a as the oauth_client.=A0 If the client ID represents s= omething=A0 like a desktop client it (i.e. Flickr Uploadr client and mobile= clients now) then that ID isn't probably really useful because it's effect= ively a user agent.=A0 On the other hand it might be the client ID of a 3rd= party in a 3 legged relationship, in which case it really is what we want.= =A0 I was leaving that the to the server to determine.=0A=0A=0A=0A=0A=0A>__= ______________________________=0A> From: Nico Williams =0A>To: "Cantor, Scott" =0A>Cc: "kitten@ietf.org" =0A>Sent: Tuesday, August 28, 2012 9:05 PM=0A>Subject: Re: [= kitten] Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>On Tue, Aug 28, 201= 2 at 10:59 PM, Cantor, Scott wrote:=0A>> On 8/28/12 11:5= 4 PM, "Nico Williams" wrote:=0A>>>=0A>>>OK, let's s= ay that there is a GSS mechanism such that it makes no=0A>>>sense to assert= an authz-id when using it as a SASL/GS2 mechanism.=0A>>=0A>> I don't think= there's any obvious reason for that here.=0A>=0A>I don't see that either.= =A0 Just trying to think this through.=0A>=0A>>>What's the problem?=A0 Well= , we need to say what happens if an authz-id=0A>>>is asserted nonetheless.= =A0 We can say that the server "MUST fail the=0A>>>authentication attempt",= or that it "MUST ignore the authz-id=0A>>>assertion", or perhaps something= else.=0A>>=0A>> As I suspected, and Simon/Luke noted, you can't mandate th= at without=0A>> breaking existing GS2 code.=0A>=0A>Good point.=0A>=0A>I thi= nk the best thing to do is to say that this is a SASL/GS2 (and=0A>therefore= GSS) mechanism and then say *noting* about the SASL=0A>authz-id.=0A>=0A>Ni= co=0A>--=0A>_______________________________________________=0A>Kitten maili= ng list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/listinfo/kitten= =0A>=0A>=0A> --835683298-1403400999-1346214892=:84802 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Just to b= e clear it is possible in OAuth to have *both* a client ID which would equa= te to an authZ ID and a ID in the token which would be an authN ID. &n= bsp; All this info might be carried in a Bearer token, or explicitly called= out in OAuth 1.0a as the oauth_client.  If the client ID represents s= omething  like a desktop client it (i.e. Flickr Uploadr client and mob= ile clients now) then that ID isn't probably really useful because it's eff= ectively a user agent.  On the other hand it might be the client ID of= a 3rd party in a 3 legged relationship, in which case it really is what we= want.  I was leaving that the to the server to determine.


=20
From: Nico Williams <nico@cryptonector.com>
To: "Cantor, Scott" <cantor.2@osu.edu>=
Cc: "kitten@ietf.org"= <kitten@ietf.org>
Sent: Tuesday, August 28, 2012 9:05 PM
Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL dr= aft -05

On Tue, Aug 28, 2012 at 10:59 PM, Cantor, Sc= ott <cantor.2@osu.edu> wrote:
> On 8/28/12 11:54 PM, "Nico Wil= liams" <nico@cryptonector.com> wrote:
>>
>>OK, let's = say that there is a GSS mechanism such that it makes no
>>sense to= assert an authz-id when using it as a SASL/GS2 mechanism.
>
> = I don't think there's any obvious reason for that here.

I don't see = that either.  Just trying to think this through.

>>What's= the problem?  Well, we need to say what happens if an authz-id
>= ;>is asserted nonetheless.  We can say that the server "MUST fail t= he
>>authentication attempt", or that it "MUST ignore the authz-id=
>>assertion", or perhaps something else.
>
> As I sus= pected, and Simon/Luke noted, you can't mandate that without
> breaki= ng existing GS2 code.

Good point.

I think the best thing to d= o is to say that this is a SASL/GS2 (and
therefore GSS) mechanism and then say *noting* about the SASL
authz-id.

Nico
--
_______= ________________________________________
Kitten mailing list
Kitten@ietf.o= rg
https://www.ietf.org/mailman/listinfo/kitten


--835683298-1403400999-1346214892=:84802-- From nico@cryptonector.com Tue Aug 28 21:36:02 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7BB11E8097 for ; Tue, 28 Aug 2012 21:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.966 X-Spam-Level: X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=-0.989, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 1Sh5yJjCbPC6 for ; Tue, 28 Aug 2012 21:36:01 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD6F21F8497 for ; Tue, 28 Aug 2012 21:36:01 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 05FBC59405E for ; Tue, 28 Aug 2012 21:36:01 -0700 (PDT) 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; s=cryptonector.com; bh=VoF9R0I61YPEkrU/ThO1 Q78JfaM=; b=NIMamQiP1hocImnbPGQbsy+0d6qdF/CAVXakfEkcuXfBSlkNVzgl sprTe+bOkkSVY6Gv9D+UI+/Q9ycx9q3meXK5rLt/0CNeK36lQO5qw6WdcAEynN7l pd68ryLaQf1OMeM6fckaZC8iM89SPuCJ/DKIwQdHvcy6x0gUPo18aMg= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id E9B9F594059 for ; Tue, 28 Aug 2012 21:36:00 -0700 (PDT) Received: by dadf8 with SMTP id f8so106897dad.31 for ; Tue, 28 Aug 2012 21:36:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.220.104 with SMTP id pv8mr1573721pbc.119.1346214960626; Tue, 28 Aug 2012 21:36:00 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 28 Aug 2012 21:36:00 -0700 (PDT) In-Reply-To: <1346214208.78462.YahooMailNeo@web31813.mail.mud.yahoo.com> References: <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346214208.78462.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Tue, 28 Aug 2012 23:36:00 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: Simon Josefsson , "kitten@ietf.org" Subject: Re: [kitten] URis Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:36:02 -0000 On Tue, Aug 28, 2012 at 11:23 PM, William Mills wrote: > Because OAuth is about granting access to a resource, and in many cases > resources are represented as URIs. The access dance includes in some parts > of the flow the URI of the resource for which access is being granted. If > we really go "there" then we need to be able to grant access to "send mail > as user@example.com", and that's completely different from > mailto:user@example.com. We'd need to define something like > mailfrom:user@example.com. This is why I'm punting by mapping everything > onto a stub HTTP URI, because SASL exists in many places for which there is > no defined URI. > > Does that explain it? Yes. I surmised that was your concern. What we want is for the authentication ID that is yielded on the server side to be in the form of a GSS NAME object that the application can use to inquire about the granted access. Also, the display/exported name forms of an OAuth authentication ID can actually be such that they encode the authorizations granted. But here's the key: you need not say anything at all about the SASL authz-id. It's irrelevant. If a client asserts one then the *application* gets to decide whether and how to use it in relation to the OAuth authentication ID. Given a complex/composite OAuth authentication ID I don't think you'll have to worry about the authz-ID at all. So... just say nothing about authz-ids! But, you will want to specify at least what the authentication ID display form is, and preferably a canonicalization of it. Here are some possible authen IDs that I'm imagining: - : [, ...] - joe@foo.example: send-email-as:jane@bar.example - anonymous: send-e-mail-as:joe@foo.example, send-email-as:jane@bar.example Canonicalization might require lower-casing case-insensitive components of IDs and authorizations. Or you might not specify a canonicalization, just that the forms granted by the grantor are by definition canonical (this is much easier!). Nico -- From cantor.2@osu.edu Tue Aug 28 21:39:26 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED7711E8097 for ; Tue, 28 Aug 2012 21:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 F5Dl3WekfkyQ for ; Tue, 28 Aug 2012 21:39:25 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9E221F84E1 for ; Tue, 28 Aug 2012 21:39:25 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7T4dKAg023926; Wed, 29 Aug 2012 00:39:24 -0400 Received: from CIO-TNC-HT07.osuad.osu.edu (2002:a46b:51ae::a46b:51ae) by CIO-KRC-HT01.osuad.osu.edu (2002:a46b:5125::a46b:5125) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 29 Aug 2012 00:39:10 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.02.0309.002; Wed, 29 Aug 2012 00:39:10 -0400 From: "Cantor, Scott" To: "Cantor, Scott" , William Mills , Simon Josefsson Thread-Topic: [kitten] URis Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNhaA6BSVntVpg+0K9X3nX3A6Ljg== Date: Wed, 29 Aug 2012 04:39:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.74.80.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <8512C8411049204895D6029262CCD8EB@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] URis Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:39:26 -0000 On 8/29/12 12:31 AM, "Cantor, Scott" wrote: > >The OAuth layer shouldn't need to know anything about the information >we're talking about whatsoever. It's client-asserted information to the >server that is then evaluated by the server upon completion of the >exchange. In most protocols it's going to be an ordinary, vanilla >username. > >You are making the mistake of trying to tie the asserted identity into the >OAuth token exchange so that it's backed by that mechanism, but you don't >have to do that. Actually, I'll caveat that. If the implementations of these SASL clients is such that the client asserted identity is fed into the mechanism and expected to be carried through as the client identity in the underlying mechanism, then I would see the problem. Since that's a fatal problem in most mechanisms, I think it would have to get fixed anyway, and it can't be fixed by trying to legislate away the fact that the client's view of its name and the mechanism's view just aren't necessarily the same. -- Scott From nico@cryptonector.com Tue Aug 28 21:50:05 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0812521F84C2 for ; Tue, 28 Aug 2012 21:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 OEslrBm28IJP for ; Tue, 28 Aug 2012 21:50:04 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0989C21F844F for ; Tue, 28 Aug 2012 21:50:03 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 94B8F3B8062 for ; Tue, 28 Aug 2012 21:50:03 -0700 (PDT) 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; s=cryptonector.com; bh=vD4S13Giwe5PrKklvhAl WAHUfGk=; b=Tamt3fahrhLDhaYACeEL6B4P6DFPqrwaSZfDS3SrwxiiZ7vDRDBq rxUwGk42nJavOFEdNqX5vkX89flNznWMpIxAKr2yOt93u41mhULzltweiIR3pwRr y9KfAjV0Q8y0NYTSGgCgew1XQA1vI8RI/eAq8uPIzoBws0XdqpBV23o= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 83E363B805B for ; Tue, 28 Aug 2012 21:50:03 -0700 (PDT) Received: by dadf8 with SMTP id f8so113455dad.31 for ; Tue, 28 Aug 2012 21:50:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.77.7 with SMTP id o7mr813844paw.37.1346215803133; Tue, 28 Aug 2012 21:50:03 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 28 Aug 2012 21:50:02 -0700 (PDT) In-Reply-To: <1346214892.84802.YahooMailNeo@web31804.mail.mud.yahoo.com> References: <1346214892.84802.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Tue, 28 Aug 2012 23:50:02 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Identities Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:50:05 -0000 On Tue, Aug 28, 2012 at 11:34 PM, William Mills wrote: > Just to be clear it is possible in OAuth to have *both* a client ID which > would equate to an authZ ID and a ID in the token which would be an authN > ID. All this info might be carried in a Bearer token, or explicitly called > out in OAuth 1.0a as the oauth_client. If the client ID represents > something like a desktop client it (i.e. Flickr Uploadr client and mobile > clients now) then that ID isn't probably really useful because it's > effectively a user agent. On the other hand it might be the client ID of a > 3rd party in a 3 legged relationship, in which case it really is what we > want. I was leaving that the to the server to determine. If OAuth itself can carry an authz-id and its semantics are not *exactly* the same as the semantics of SASL authz-id, then it's best to not try to conflate the two. I'm assuming that the semantics of the two are in fact different. The gs2-header should carry the SASL authz-id and nothing more, and you should say nothing about this. What I do think needs to be covered is the display/exported name forms of OAuth clients. Because we don't want to lose fine-grained authz data, and because fine-grained authz data is OAuth's raison d'etre, you should specify a name form that preserves (encodes) all that authz data. If OAuth has an internal authz-id concept then this is where that authz-id would show up. When I say "display/exported name form" I'm really referring to GSS-API concepts. In GSS we have names represented as opaque objects -- NAME in the abstract API, gss_name_t in the C bindings -- and these names can be queried. For example, you would apply GSS_Display_name() to a NAME to find its display form, and you'd apply GSS_Export_name() to obtain its "exported name token" (an octet string) form. You'd call GSS_Import_name() with either a string and a name-type to get a NAME, or with an exported name token and a special name-type (GSS_C_NT_EXPORTED_NAME). SASL/GS2 says very little about this... Now, normally a GSS mechanism would authenticate users and services to each other, and if there is additional fine-grained authorization data delivered by the mechanism, then that is to be accessed via GSS_Get_name_attribute() and friends. In this case I think you could argue that because OAuth's entire purpose is to deliver fine-grained authz data the display and exported name forms of OAuth names must encode that data. See my other reply showing some sample OAuth names. Nico PS: The query/display/exported name forms of a GSS mechanism are one of the key things to document when specifying a GSS mechanism. Since OAuth would be a GSS mechanism, this is something that must be covered. From lear@cisco.com Tue Aug 28 22:43:24 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B3E11E80AD for ; Tue, 28 Aug 2012 22:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.528 X-Spam-Level: X-Spam-Status: No, score=-110.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 tJPz25WsfzFB for ; Tue, 28 Aug 2012 22:43:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7F011E809C for ; Tue, 28 Aug 2012 22:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=2958; q=dns/txt; s=iport; t=1346219003; x=1347428603; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=qKV/JqrD8vmVi2minxSmpFWqXcd0UJw+1q/gZTkVgEs=; b=A6wmQobGH3z9H5xl3iSY1sCu+EWR0wLhvVMH/Mnz+J6fvn9DOwCWV+Xh p7ZbwX/Vn5zyHg8Yesrh5teeCtYj09m67GbmNccTrw7iso5ny3/8wXP7o mJK0oEK+Wtv2hu5FzusGjMAtMc/tw/LnR87Zsk+oJkr5sht6qpV5MWxFp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAF2rPVCQ/khL/2dsb2JhbABFgkqDObR7gQeCIAEBAQQSARBVARALBAoKCRYIAwICCQMCAQIBNBEGDQEFAgEBHoVvgXybc40YkzeLIoUtgRIDlVaOLoFngmWBXw X-IronPort-AV: E=Sophos;i="4.80,332,1344211200"; d="scan'208,217";a="143034955" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 29 Aug 2012 05:43:21 +0000 Received: from ams3-vpn-dhcp5580.cisco.com (ams3-vpn-dhcp5580.cisco.com [10.61.85.203]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7T5hKhF027343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 05:43:21 GMT Message-ID: <503DABF8.6000807@cisco.com> Date: Wed, 29 Aug 2012 07:43:20 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: William Mills References: <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346214208.78462.YahooMailNeo@web31813.mail.mud.yahoo.com> In-Reply-To: <1346214208.78462.YahooMailNeo@web31813.mail.mud.yahoo.com> X-Enigmail-Version: 1.4.4 Content-Type: multipart/alternative; boundary="------------030604000408050704090908" Cc: Simon Josefsson , "kitten@ietf.org" Subject: Re: [kitten] URis Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 05:43:24 -0000 This is a multi-part message in MIME format. --------------030604000408050704090908 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sorry for stepping into this late, but just a question: On 8/29/12 6:23 AM, William Mills wrote: > Because OAuth is about granting access to a resource, and in many > cases resources are represented as URIs. The access dance includes > in some parts of the flow the URI of the resource for which access is > being granted. If we really go "there" then we need to be able to > grant access to "send mail as user@example.com", and that's completely > different from mailto:user@example.com. We'd need to define something > like mailfrom:user@example.com. We don't use a different syntax in SMTP between MAIL FROM: and RCPT TO: (with the exception of <>). Why would this be necessary here? Eliot --------------030604000408050704090908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Sorry for stepping into this late, but just a question:

On 8/29/12 6:23 AM, William Mills wrote:
Because OAuth is about granting access to a resource, and in many cases resources are represented as URIs.  The  access dance includes in some parts of the flow the URI of the resource for which access is being granted.  If we really go "there" then we need to be able to grant access to "send mail as user@example.com", and that's completely different from mailto:user@example.com.  We'd need to define something like mailfrom:user@example.com.

We don't use a different syntax in SMTP between MAIL FROM: and RCPT TO: (with the exception of <>).  Why would this be necessary here?

Eliot

--------------030604000408050704090908-- From wmills@yahoo-inc.com Tue Aug 28 22:45:36 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7E411E80BA for ; Tue, 28 Aug 2012 22:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.556 X-Spam-Level: X-Spam-Status: No, score=-17.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 zfDqV--hHlXp for ; Tue, 28 Aug 2012 22:45:35 -0700 (PDT) Received: from nm31-vm5.bullet.mail.ne1.yahoo.com (nm31-vm5.bullet.mail.ne1.yahoo.com [98.138.229.45]) by ietfa.amsl.com (Postfix) with SMTP id 2C40211E809C for ; Tue, 28 Aug 2012 22:45:35 -0700 (PDT) Received: from [98.138.90.54] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 29 Aug 2012 05:45:29 -0000 Received: from [98.138.89.251] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 29 Aug 2012 05:45:29 -0000 Received: from [127.0.0.1] by omp1043.mail.ne1.yahoo.com with NNFMP; 29 Aug 2012 05:45:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 520243.16409.bm@omp1043.mail.ne1.yahoo.com Received: (qmail 2129 invoked by uid 60001); 29 Aug 2012 05:45:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346219129; bh=eCXn9U0Rwo75LGEoV03TCn0VJKCLREAA3vkAQcAXIIY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bUD30MSN6BK0pTDWta1pduvgZQWaRTvKoaMdiiNsWQUcklty3ETLLBnLZFiHzYiaB7EVGDWbgPQtFmZeQdsReu7U+gOvh9xLbAaUqH0VWeOhDadwTa1mja/SJMV9oxEGQvwMUs+h/v5q9dDyEEvMie3U3CvbEy6SQYcpy/vfUtg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=W7eTfG9uGotGONm7Bcl8/5ip+wWgbJpzIUxHoN0xfa6ow9cjlpB5hX+Mgx0dK5U8htdxygrUkTtk3HI0AIayCbdO3m/mMojqVv+zFYCh9vnKUKMLC2hcYnSNanAdkRMw50UynoTEznio/sm/BPQiPGxkIyY/RvEBEy1+OoSIP6Q=; X-YMail-OSG: OSU_vSYVM1mIG7zjyA_zspIKZTolCP.idVagOwK2RtjuumR xY1SkjGFuhqKDTWGSjJKUTtBBG7HMDrdLzPhzdKKOHziobv21.eJ2vW7O2d2 FiumrHRfj8ydsCMBqdUv5p7VEokm9UFTfhGflXT0GWwtayeHVjbtadod_Dkj WWX1w1Ujr8JGuWgDlrescxnXHafIZsG2zF.SDaIDuT08dNtvSUoot3LnzA7c 9BkdvAa6bP7npRbQbB8nrWsUiMxE4SV2u_fvfJgIDqKcTRhN3830ERW6tPTQ mkbvWza69.W_W1ds57_6pX.XqYuiflfD9sxJarqSfRNFnzS078bOvB.yZTa7 LrKhG1.AdmnZzBTDB5GiqZcw9o5Z_qQXXNSZyhnSk6T4fZbiQeXo6A7.hbfZ rrn7EHLNavTjOdDRL8lszntDCfCCiOo3J.HdWQrS6wpYBBtWdJ8KMtUWsBzC 2Af6Y052cma8- Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Tue, 28 Aug 2012 22:45:29 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346214208.78462.YahooMailNeo@web31813.mail.mud.yahoo.com> Message-ID: <1346219129.88724.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Tue, 28 Aug 2012 22:45:29 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , "kitten@ietf.org" Subject: Re: [kitten] URis Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 05:45:36 -0000 =0A=0A=0A=0AOK!=A0 Now I'm getting it I think, having read this and your ot= her (longer) message.=A0 I think that accepting the form provided by the gr= antor is right, although the server itself might have a display name that i= t knows independent of what's carried in the token.=0A=0ASo then, here's la= nguage I think does what you are saying:=0A=0A=0A...=0A=A0=A0=A0 user (REQU= IRED):=0A=A0=A0=A0=A0=A0=A0=A0 The authentication ID. The server MAY use th= is as a routing or database lookup hint. The user name MUST agree with the = identity asserted by the OAuth credential.=0A=0A...=0A=0A3.2.1.=A0Mapping t= o SASL Identities=0A=0ASome OAuth mechanisms can provide both an authorizat= ion identity and an authentication identity. An example of this is OAuth 1.= 0a=A0[RFC5849]=A0where the consumer key (oauth_consumer_key) identifies the= entity using the token which equates to the SASL authentication identity, = and is authenticated using the shared secret. The server MAY use a consumer= key, a value derived from it, or other comparable identity in the OAuth au= thorization scheme to allow SASL an authentication identity different from = the authorization identity to be set.=0A=0A=0A3.2.2.=A0Canonicalization=0A= =0AThe identity asserted by the OAuth authorization server is canonical for= display. The server MAY provide a different canonical form based on local = data.=0A=0A=0A=0A=0A=0A=0A=0A>________________________________=0A> From: Ni= co Williams =0A>To: William Mills =0A>Cc: "Cantor, Scott" ; Simon Josefsson ; "kitten@ietf.org" =0A>Sent: Tuesday, August = 28, 2012 9:36 PM=0A>Subject: Re: [kitten] URis Re: Comma vs. %x01 Re: OAuth= SASL draft -05=0A> =0A>On Tue, Aug 28, 2012 at 11:23 PM, William Mills wrote:=0A>> Because OAuth is about granting access to a= resource, and in many cases=0A>> resources are represented as URIs.=A0 The= =A0 access dance includes in some parts=0A>> of the flow the URI of the res= ource for which access is being granted.=A0 If=0A>> we really go "there" th= en we need to be able to grant access to "send mail=0A>> as user@example.co= m", and that's completely different from=0A>> mailto:user@example.com.=A0 W= e'd need to define something like=0A>> mailfrom:user@example.com.=A0 This i= s why I'm punting by mapping everything=0A>> onto a stub HTTP URI, because = SASL exists in many places for which there is=0A>> no defined URI.=0A>>=0A>= > Does that explain it?=0A>=0A>Yes.=A0 I surmised that was your concern.=A0= What we want is for the=0A>authentication ID that is yielded on the server= side to be in the form=0A>of a GSS NAME object that the application can us= e to inquire about the=0A>granted access.=A0 Also, the display/exported nam= e forms of an OAuth=0A>authentication ID can actually be such that they enc= ode the=0A>authorizations granted.=0A>=0A>But here's the key: you need not = say anything at all about the SASL=0A>authz-id.=A0 It's irrelevant.=A0 If a= client asserts one then the=0A>*application* gets to decide whether and ho= w to use it in relation to=0A>the OAuth authentication ID.=A0 Given a compl= ex/composite OAuth=0A>authentication ID I don't think you'll have to worry = about the=0A>authz-ID at all.=0A>=0A>So... just say nothing about authz-ids= !=0A>=0A>But, you will want to specify at least what the authentication ID= =0A>display form is, and preferably a canonicalization of it.=A0 Here are= =0A>some possible authen IDs that I'm imagining:=0A>=0A>- : [, ...]=0A>=A0 =A0 - joe@foo.example: send-email-as:jane@bar.exa= mple=0A>=A0 =A0 - anonymous: send-e-mail-as:joe@foo.example, send-email-as:= jane@bar.example=0A>=0A>Canonicalization might require lower-casing case-in= sensitive=0A>components of IDs and authorizations.=A0 Or you might not spec= ify a=0A>canonicalization, just that the forms granted by the grantor are b= y=0A>definition canonical (this is much easier!).=0A>=0A>Nico=0A>--=0A>=0A>= =0A> From alexey.melnikov@isode.com Wed Aug 29 00:46:28 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D8F21F8535 for ; Wed, 29 Aug 2012 00:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.215 X-Spam-Level: X-Spam-Status: No, score=-101.215 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 hQTdr05nxrDt for ; Wed, 29 Aug 2012 00:46:28 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id E28D721F853A for ; Wed, 29 Aug 2012 00:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1346226385; d=isode.com; s=selector; i=@isode.com; bh=bSZmNvZjmc2sb6KOw3+13NHnmIZdUuxlRsvV9OTzZNM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=JbhqG3l497Ug1wVFRZP6EcJzmv6+1+OtgNfr/PsIYXQ1vvgJB/tU9fO87B79nywiYT8Azr BlA+SmK5w9ClzlBgffKGoXjfwUS/OFoUZVCtuZNKWx/KpS+Mz5a4AxIGM/SQKzk7L8A7ce 7IxMHgAs8/Z5rw7g6BBJt+4BC3IVf+0=; Received: from [188.29.12.202] (188.29.12.202.threembb.co.uk [188.29.12.202]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 29 Aug 2012 08:46:24 +0100 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> In-Reply-To: Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Wed, 29 Aug 2012 08:47:17 +0100 To: Nico Williams , William Mills MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 07:46:28 -0000 On 29 Aug 2012, at 04:54, Nico Williams wrote: > On Tue, Aug 28, 2012 at 10:49 PM, William Mills wro= te: >> Yes, what you are asking for is something I explicitly avoided and think w= e >> should continue to avoid, because for things like OAuth 1.0a you have to >> define a URI that can be signed which includes the name, and deciding the= >> correct URI format for an arbitrary resource to be authenticate with SASL= >> isn't solved. >>=20 >> It also would require is to be able to present those URIs to an OAuth >> authorization endpoint to be explicitly approved. >>=20 >> I'm avoiding having to try to define a URI for POP, IMAP, and SMTP-send-m= ail >> like the plague. >=20 > OK, let's say that there is a GSS mechanism such that it makes no > sense to assert an authz-id when using it as a SASL/GS2 mechanism. > What's the problem? Well, we need to say what happens if an authz-id > is asserted nonetheless. We can say that the server "MUST fail the > authentication attempt", or that it "MUST ignore the authz-id > assertion", or perhaps something else. I am very confused: the format of authorization identities is controlled by p= rotocols using SASL and not by mechanisms. It MUST NOT be specified in a SAS= L mechanism. So what kind of URI are we talking about??? >=20 > Nico > -- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From wmills@yahoo-inc.com Wed Aug 29 08:10:14 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B29221F86B6 for ; Wed, 29 Aug 2012 08:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.556 X-Spam-Level: X-Spam-Status: No, score=-17.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 7B3ClYTs0wCY for ; Wed, 29 Aug 2012 08:10:12 -0700 (PDT) Received: from nm40-vm7.bullet.mail.bf1.yahoo.com (nm40-vm7.bullet.mail.bf1.yahoo.com [72.30.239.215]) by ietfa.amsl.com (Postfix) with SMTP id 8687F21F86B5 for ; Wed, 29 Aug 2012 08:10:11 -0700 (PDT) Received: from [98.139.212.146] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 29 Aug 2012 15:10:10 -0000 Received: from [98.139.212.251] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 29 Aug 2012 15:10:10 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 29 Aug 2012 15:10:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 189359.71880.bm@omp1060.mail.bf1.yahoo.com Received: (qmail 39784 invoked by uid 60001); 29 Aug 2012 15:10:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346253009; bh=QQ7CeVeCjItOJnkzXpD1IUupfqa4JNSNe0zuKaVgg+8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AKZ4cJCXnI0rLgcNZdyt3zdM7UdpczvXTk0df8NWsxy8D1YAPgW9WQFQT3v8q7+aJeO3tz0DJPMHHtAIhCjc9cxF1vR74AqAd1NL4Y2wMlOionEsB+kk+2L7e5IR5363Xvm9Jux3sg/59GkFtZIExzPvTmB3cYC5AAYBixEBb5M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VdxnAb1vJ1Vx+CiXhew/tKvAZEt9RujItT1FTkv6eGghlD5lrnwsVeOd13n03LEqgVIRlmgp5jsSkz295gGq6FQ27zJGF27a6Mcqj0ilJDthc+JW50MA6eO3hVgfZLuPAffdXORJ/hSWqc+vCqPUDvDNB3q+FdP80MGu6cAS9ok=; X-YMail-OSG: 3sHi570VM1mlC7MYLQtX9Nc7VsxtbA5IYUWFCqKdSqt6YoL g7gYW6nI4kKWx0kQfRP4lUA_fAml8gmTr7uTVKdI56FaM.y8HwgRHd0yxdgG 8cmNzP24aIs3C8Ckps86Fx9bNYHGu3ZcGjkvMI5UN.6E0IsOMgVlNtLG7xnx AAA1.w0xJ0TqKsXL0uPpQOlfiDxIYWuE1jCgFjwXVMrLPTWPBudtM1bJ7FpB r8YxQ4ul32sJmUHlpAE953AtLn8BEXVE4eeeWn1GLO3jFXTRAe0aMsc1r72d 4U534NAqHfs5hcr2vG0sJ_2eNYD94i0W2Le9ld7O6x_hLloWUGIAbHIia4DL F_iW0OfiKZruVcBVAOmz3sgr5GlNdGv21AYjvN7ZYyAfi3KzMaqHcLQtNaxZ 4X0BmE2rcw.gfcl34LxYEzTuHuYtbxNebnYQR0LiCfhtIak09c3_IvtUvCO3 pjn5t8GWWvl70 Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Wed, 29 Aug 2012 08:10:09 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346214208.78462.YahooMailNeo@web31813.mail.mud.yahoo.com> <503DABF8.6000807@cisco.com> Message-ID: <1346253009.34921.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Wed, 29 Aug 2012 08:10:09 -0700 (PDT) From: William Mills To: Eliot Lear In-Reply-To: <503DABF8.6000807@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-251581413-1346253009=:34921" Cc: Simon Josefsson , "kitten@ietf.org" Subject: Re: [kitten] URis Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 15:10:14 -0000 ---1055047407-251581413-1346253009=:34921 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable While they may be the same SMTP servers for sending outbound mail from auth= enticated users on a domain are typically different than the mail exchanger= s used for sending mail to that domain.=A0 The mailto: scheme could perhaps= be overloaded for this purpose, but in this use case what we need is somet= hing that identifies for a user how they can send mail in an authenticated = fashion and not how to send something to the user.=0A=0A-bill=0A=0A=0A=0A= =0A=0A>________________________________=0A> From: Eliot Lear =0A>To: William Mills =0A>Cc: "Cantor, Scott" ; Simon Josefsson ; "kitten@ietf.org" =0A>Sent: Tuesday, August 28, 2012 10:43 PM=0A>Subject: Re:= [kitten] URis Re: Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>=0A>S= orry for stepping into this late, but just a question:=0A>=0A>=0A>On 8/29/1= 2 6:23 AM, William Mills wrote:=0A>=0A>Because OAuth is about granting acce= ss to a resource, and in many cases resources are represented as URIs.=A0 T= he=A0 access dance includes in some parts of the flow the URI of the resour= ce for which access is being granted.=A0 If we really go "there" then we ne= ed to be able to grant access to "send mail as user@example.com", and that'= s completely different from mailto:user@example.com.=A0 We'd need to define= something like mailfrom:user@example.com.=0A>>=0A>We don't use a different= syntax in SMTP between MAIL FROM: and RCPT=0A TO: (with the exception o= f <>).=A0 Why would this be necessary=0A here?=0A>=0A>Eliot=0A>=0A>=0A>= =0A> ---1055047407-251581413-1346253009=:34921 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
While the= y may be the same SMTP servers for sending outbound mail from authenticated= users on a domain are typically different than the mail exchangers used fo= r sending mail to that domain.  The mailto: scheme could perhaps be ov= erloaded for this purpose, but in this use case what we need is something t= hat identifies for a user how they can send mail in an authenticated fashio= n and not how to send something to the user.

-bill

From: Eliot L= ear <lear@cisco.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: "Cantor, Scott" <cantor.2@osu.edu>;= Simon Josefsson <simon@josefsson.org>; "kitten@ietf.org" <kitten@= ietf.org>
Sent: Tu= esday, August 28, 2012 10:43 PM
S= ubject: Re: [kitten] URis Re: Comma vs. %x01 Re: OAuth SASL d= raft -05

=0A =0A =0A = =0A
=0A Sorry for stepping into this late, but just a question:=0A
=0A
On 8/29/12 6= :23 AM, William Mills=0A wrote:
=0A
=0A
=0A =0A
=0A
Because=0A OAuth is abou= t granting access to a resource, and in many=0A cases resources = are represented as URIs.  The  access dance=0A include= s in some parts of the flow the URI of the resource=0A for which= access is being granted.  If we really go "there"=0A then = we need to be able to grant access to "send mail as=0A user= @example.com", and that's completely different from=0A mai= lto:user@example.com.  We'd need to define something like=0A = mailfrom:user@example.com.
=0A =
=0A
=0A
=0A
=0A We don't= use a different syntax in SMTP between MAIL FROM: and RCPT=0A TO: (with= the exception of <>).  Why would this be necessary=0A here?<= br>=0A
=0A Eliot
=0A
=0A
=0A=0A


---1055047407-251581413-1346253009=:34921-- From wmills@yahoo-inc.com Wed Aug 29 08:12:11 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC9B21F86D9 for ; Wed, 29 Aug 2012 08:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.557 X-Spam-Level: X-Spam-Status: No, score=-17.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 w1lHuVhq3BDp for ; Wed, 29 Aug 2012 08:12:10 -0700 (PDT) Received: from nm20.bullet.mail.sp2.yahoo.com (nm20.bullet.mail.sp2.yahoo.com [98.139.91.90]) by ietfa.amsl.com (Postfix) with SMTP id 647D521F86D8 for ; Wed, 29 Aug 2012 08:12:10 -0700 (PDT) Received: from [98.139.91.68] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 29 Aug 2012 15:12:04 -0000 Received: from [98.139.91.24] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 29 Aug 2012 15:12:04 -0000 Received: from [127.0.0.1] by omp1024.mail.sp2.yahoo.com with NNFMP; 29 Aug 2012 15:12:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 244687.73460.bm@omp1024.mail.sp2.yahoo.com Received: (qmail 78389 invoked by uid 60001); 29 Aug 2012 15:12:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346253123; bh=M6osoVFD7LpbfaVieFs6pE/WOWv4/IrmNEYdNO3DxqM=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Q6uy4oeo6RBBbM5QjaZwiOhcnNuBp7yFBicOL3HaEGIwTP3nbyTA4gV06O7E5A8xwtDZ3Q3CeOCy9rObdOqTuyuOtOlSPmivOApaqX7t8fRL2THjt5PkNz3L2UZYx+5xefsJ4guhkBFQc2WP1pOJ4JtNYc0NuBjttQ1MPs5fupY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BonN5s1IlLKPtKRgnk3Cl09SAJJ4L3ZtVTrMhJWKWzkNUeO+gS+6bWAvQBJvYmWm57bE9RRUhSp04ea2/1qRy22PgrfNojdHJ84IIpkJXc0LRU7SwiIvf49SXLsFs4WaslyBAERZfie+e27fOJS0AVuz+BHMVneEqMSb7+dqSj8=; X-YMail-OSG: DmwbYSAVM1lB4r1o79vgQMsGZbHSp1gVR84PLPseaRR9WhF M_lcVVXhDCxo1mbNx.vndETPMDpIwXV4kyRLArYSjx.2eQrKCUC8r_dKQyIu WW2xX.AQPQDyECejTPAezXXRVAMrIP20CIt9ZXLJ7xhDNkl6HNI7xJ7S27UE IWJyUb0NVVcsQp6msqZIKsn8D9227QoLtwsQC_sWneUOrhJZ.B7H.AOoRaDY pdAd3X1GpB4s0.GhHo6Hi5guzcpANlL6ZN8szSrFRTZxghYBXOMM6.Qa7NH_ Wz_V1V0.RlJeZFzMr8y62_rQMAHBtC8Ns8Fliqe2xygnUjsbGBt5TVUuRKe0 tl3J0JmV.wajVD86X8d.FX7S.Criqo6GCEfLDcP95sxi7u6Iphysa4L6Zq02 yDK1wMjvOOBO94tfEU.gbxWtMpI2rxTEiD5tDT7ziLgWCf3OF63h4suAkRmM Q8HSRcg-- Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Wed, 29 Aug 2012 08:12:03 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> Message-ID: <1346253123.67083.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Wed, 29 Aug 2012 08:12:03 -0700 (PDT) From: William Mills To: Alexey Melnikov , Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1935884094-1291050723-1346253123=:67083" Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 15:12:11 -0000 --1935884094-1291050723-1346253123=:67083 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yes, an OAuth SASL mechanism has to be able to take a credential and map it= to an identity that works in the specific protocol.=0A=0A=0A=0A=0A=0A>____= ____________________________=0A> From: Alexey Melnikov =0A>To: Nico Williams ; William Mills =0A>Cc: "kitten@ietf.org" =0A>Sent: Wedne= sday, August 29, 2012 12:47 AM=0A>Subject: Re: [kitten] Comma vs. %x01 Re: = OAuth SASL draft -05=0A> =0A>On 29 Aug 2012, at 04:54, Nico Williams wrote:=0A>=0A>> On Tue, Aug 28, 2012 at 10:49 PM, William= Mills wrote:=0A>>> Yes, what you are asking for is = something I explicitly avoided and think we=0A>>> should continue to avoid,= because for things like OAuth 1.0a you have to=0A>>> define a URI that can= be signed which includes the name, and deciding the=0A>>> correct URI form= at for an arbitrary resource to be authenticate with SASL=0A>>> isn't solve= d.=0A>>> =0A>>> It also would require is to be able to present those URIs t= o an OAuth=0A>>> authorization endpoint to be explicitly approved.=0A>>> = =0A>>> I'm avoiding having to try to define a URI for POP, IMAP, and SMTP-s= end-mail=0A>>> like the plague.=0A>> =0A>> OK, let's say that there is a GS= S mechanism such that it makes no=0A>> sense to assert an authz-id when usi= ng it as a SASL/GS2 mechanism.=0A>> What's the problem?=A0 Well, we need to= say what happens if an authz-id=0A>> is asserted nonetheless.=A0 We can sa= y that the server "MUST fail the=0A>> authentication attempt", or that it "= MUST ignore the authz-id=0A>> assertion", or perhaps something else.=0A>=0A= >I am very confused: the format of authorization identities is controlled b= y protocols using SASL and not by mechanisms. It MUST NOT be specified in a= SASL mechanism.=0A>=0A>So what kind of URI are we talking about???=0A>> = =0A>> Nico=0A>> --=0A>> _______________________________________________=0A>= > Kitten mailing list=0A>> Kitten@ietf.org=0A>> https://www.ietf.org/mailma= n/listinfo/kitten=0A>=0A>=0A> --1935884094-1291050723-1346253123=:67083 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, an O= Auth SASL mechanism has to be able to take a credential and map it to an id= entity that works in the specific protocol.

=

From: Alexey Melni= kov <alexey.melnikov@isode.com>
To: Nico Williams <nico@cryptonector.com>; William Mi= lls <wmills@yahoo-inc.com>
= Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Wednesday, August 29, 2012 12:47 AM
Subject: Re: [kitten] Comma vs. %= x01 Re: OAuth SASL draft -05

On 29 Aug 2012, at 04:5= 4, Nico Williams <nico@cryptonector.com> wrote:

>= ; On Tue, Aug 28, 2012 at 10:49 PM, William Mills <wmills@yahoo-inc= .com> wrote:
>> Yes, what you are asking for is something I= explicitly avoided and think we
>> should continue to avoid, beca= use for things like OAuth 1.0a you have to
>> define a URI that ca= n be signed which includes the name, and deciding the
>> correct U= RI format for an arbitrary resource to be authenticate with SASL
>>= ; isn't solved.
>>
>> It also would require is to be able= to present those URIs to an OAuth
>> authorization endpoint to be= explicitly approved.
>>
>> I'm avoiding having to try t= o define a URI for POP, IMAP, and SMTP-send-mail
>> like the plagu= e.
>
> OK, let's say that there is a GSS mechanism such that i= t makes no
> sense to assert an authz-id when using it as a SASL/GS2 = mechanism.
> What's the problem?  Well, we need to say what happ= ens if an authz-id
> is asserted nonetheless.  We can say that t= he server "MUST fail the
> authentication attempt", or that it "MUST = ignore the authz-id
> assertion", or perhaps something else.

I= am very confused: the format of authorization identities is controlled by = protocols using SASL and not by mechanisms. It MUST NOT be specified in a S= ASL mechanism.

So what kind of URI are we talking about???
>
> Nico
> --
> ________________________= _______________________
> Kitten mailing list
> Kitten@ietf.org<= br>> https://www.ietf.org/mailman/listinfo/kitten


=
--1935884094-1291050723-1346253123=:67083-- From lukeh@padl.com Wed Aug 29 17:23:03 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7770D11E80F6 for ; Wed, 29 Aug 2012 17:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] 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 zKmDjCfmObF6 for ; Wed, 29 Aug 2012 17:23:03 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id D1E3111E80F5 for ; Wed, 29 Aug 2012 17:23:02 -0700 (PDT) Received: by us.padl.com with ESMTP id q7U0Mse0029862; Wed, 29 Aug 2012 20:22:58 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: Date: Thu, 30 Aug 2012 10:22:52 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.6 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 00:23:03 -0000 On 29/08/2012, at 5:47 PM, Alexey Melnikov = wrote: > I am very confused: the format of authorization identities is = controlled by protocols using SASL and not by mechanisms. It MUST NOT be = specified in a SASL mechanism. My understanding is that we are conflating SASL and OAuth authorisation = identities. SASL authorisation identities should be carried per the GS2 = specification and are for the SASL implementation or application to = handle, not the mechanism. OAuth authorisation semantics might be = exposed via GSS naming extensions. -- Luke= From wwwrun@rfc-editor.org Wed Aug 29 17:53:12 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3FD21F8498; Wed, 29 Aug 2012 17:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.995 X-Spam-Level: X-Spam-Status: No, score=-101.995 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 3cCVh58yV-68; Wed, 29 Aug 2012 17:53:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0238821F8495; Wed, 29 Aug 2012 17:53:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5F8BCB1E002; Wed, 29 Aug 2012 17:50:51 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120830005051.5F8BCB1E002@rfc-editor.org> Date: Wed, 29 Aug 2012 17:50:51 -0700 (PDT) Cc: kitten@ietf.org, rfc-editor@rfc-editor.org Subject: [kitten] RFC 6680 on Generic Security Service Application Programming Interface (GSS-API) Naming Extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 00:53:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6680 Title: Generic Security Service Application Programming Interface (GSS-API) Naming Extensions Author: N. Williams, L. Johansson, S. Hartman, S. Josefsson Status: Standards Track Stream: IETF Date: August 2012 Mailbox: nico@cryptonector.com, leifj@sunet.se, hartmans-ietf@mit.edu, simon@josefsson.org Pages: 18 Characters: 37063 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-kitten-gssapi-naming-exts-15.txt URL: http://www.rfc-editor.org/rfc/rfc6680.txt The Generic Security Service Application Programming Interface (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. This document is a product of the Common Authentication Technology Next Generation Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wmills@yahoo-inc.com Wed Aug 29 22:35:43 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C320A21F858F for ; Wed, 29 Aug 2012 22:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.574 X-Spam-Level: X-Spam-Status: No, score=-17.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 4HNnMBi9i1HR for ; Wed, 29 Aug 2012 22:35:43 -0700 (PDT) Received: from nm39-vm7.bullet.mail.bf1.yahoo.com (nm39-vm7.bullet.mail.bf1.yahoo.com [72.30.239.151]) by ietfa.amsl.com (Postfix) with SMTP id C15DE21F8587 for ; Wed, 29 Aug 2012 22:35:42 -0700 (PDT) Received: from [98.139.212.147] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 30 Aug 2012 05:35:41 -0000 Received: from [98.139.212.200] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 30 Aug 2012 05:35:41 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 30 Aug 2012 05:35:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 497626.79832.bm@omp1009.mail.bf1.yahoo.com Received: (qmail 16080 invoked by uid 60001); 30 Aug 2012 05:35:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346304940; bh=8LbxM6tXA6n8kPiv9tFQG0/E0qjh2y+j+u5L8syDjt0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mwjNeptt0Clk2v5GactuiET6GMHWX25gdkh3rXO8CG9jEXHjXfxuSH4xELZnkxaDgU9t5WlY/DbjgDfi+jOqWojg//qO64JOq1emuLghBt/cufI2TfwTmASLi7a/Jz9/AuPeaXmIxakrmJAY2BX1c0IavUuc0/w9Dh9g/K0CpZw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MttePKSTLKft1H1GKwNKQVuRlqcoXKP+rRhYJ7RPUjEOP/9TSPg8oDQhnkFOcI9TJodMD0f0HEhLzg3gtLVOYgmCNZhpyTBIUUlChyrbDk6ZOKIAB+KA7FG1NGKwhVQxJ7XQLgUG5D0+v97ujzE2TFf6MgcD4GOExWgCGsVusIs=; X-YMail-OSG: _yjg7kkVM1nKywqzGvIoaJojwYPWZxzL5xiRG3JD8mKB96A AAE8TBqL9imYBrganDohheR25rQRnzfQvR9oCfG0G_4WnkNWylzQU5z7w_Tb gq7CVZ4pQO6BZXe6dGg0jDnAcTsNhXUZjzB15lMQFFoK6EmRe9jQ1tud9Ouf F1OgP5Wil5eeKiJKLl6jYZ.Ul45Q61gjbInzzYA972RUvjFZoax_fxzv1VTr b8qO2Q6uHtzp0yNEOBJj2RzW8LuydMXzP.UrrhuWZjvI9Hf68RvWrEfC_2pY pKz6eNGfiZSCwNAAMOg.Jf2.8tVEk.iE9y2suI8x3gpVqctBcD1nhPWqaZsh BVLWTVL9Hu_HGvkNKu11v2FflV4UXK1P_rk389in1L0Dw7OluRnpUzsW4RrB Pnmrzjn.YmZXMgmQiXvgR4e1hzlOXrO.A8m5hPh6txiI7 Received: from [99.31.212.42] by web31809.mail.mud.yahoo.com via HTTP; Wed, 29 Aug 2012 22:35:40 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> Message-ID: <1346304940.59715.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Wed, 29 Aug 2012 22:35:40 -0700 (PDT) From: William Mills To: Luke Howard , Alexey Melnikov In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-1584965121-1346304940=:59715" Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 05:35:43 -0000 ---1395015409-1584965121-1346304940=:59715 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable How is the mechanism different form the application in this case?=A0 I real= ly don't get why there is a problem here, in fact this wasn't a problem unt= il the gs2-header actually got added.=A0 =0A=0AWhy can't the mechanism itse= lf be asserting the identity?=0A=0A=0A=0A=0A=0A>___________________________= _____=0A> From: Luke Howard =0A>To: Alexey Melnikov =0A>Cc: Nico Williams ; William= Mills ; "kitten@ietf.org" =0A>Sent= : Wednesday, August 29, 2012 5:22 PM=0A>Subject: Re: [kitten] Comma vs. %x0= 1 Re: OAuth SASL draft -05=0A> =0A>=0A>On 29/08/2012, at 5:47 PM, Alexey Me= lnikov wrote:=0A>=0A>> I am very confused: the = format of authorization identities is controlled by protocols using SASL an= d not by mechanisms. It MUST NOT be specified in a SASL mechanism.=0A>=0A>M= y understanding is that we are conflating SASL and OAuth authorisation iden= tities. SASL authorisation identities should be carried per the GS2 specifi= cation and are for the SASL implementation or application to handle, not th= e mechanism. OAuth authorisation semantics might be exposed via GSS naming = extensions.=0A>=0A>-- Luke=0A>=0A> ---1395015409-1584965121-1346304940=:59715 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
How is th= e mechanism different form the application in this case?  I really don= 't get why there is a problem here, in fact this wasn't a problem until the= gs2-header actually got added. 

Why can't the mechanism itsel= f be asserting the identity?


<= div dir=3D"ltr">
From: Luke Howard <lukeh@padl.co= m>
To: Alexey Melni= kov <alexey.melnikov@isode.com>
Sent: Wednesday, August= 29, 2012 5:22 PM
Subject:= Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05

On 29/08/2012, at 5:47 PM, Alexey Melnikov <ale= xey.melnikov@isode.com> wrote:

> I am very confused: the f= ormat of authorization identities is controlled by protocols using SASL and= not by mechanisms. It MUST NOT be specified in a SASL mechanism.

My= understanding is that we are conflating SASL and OAuth authorisation ident= ities. SASL authorisation identities should be carried per the GS2 specification and are for the SASL implementation or application to handle= , not the mechanism. OAuth authorisation semantics might be exposed via GSS= naming extensions.

-- Luke

---1395015409-1584965121-1346304940=:59715-- From simon@josefsson.org Thu Aug 30 01:06:35 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC01521F86D8 for ; Thu, 30 Aug 2012 01:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.854 X-Spam-Level: X-Spam-Status: No, score=-99.854 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 H6UT9yq68ojf for ; Thu, 30 Aug 2012 01:06:35 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id B4E1E21F84A7 for ; Thu, 30 Aug 2012 01:06:33 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7U86Gtv011244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Aug 2012 10:06:23 +0200 From: Simon Josefsson To: William Mills References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120830:alexey.melnikov@isode.com::CWU5+tmC5u5ifHIB:0sdL X-Hashcash: 1:22:120830:kitten@ietf.org::LWLwjQd9ErOU9A+F:8T16 X-Hashcash: 1:22:120830:lukeh@padl.com::YA+IfevccBu/1GHy:5UEg X-Hashcash: 1:22:120830:wmills@yahoo-inc.com::kc/rJUW+FFSsb6XY:FFAP Date: Thu, 30 Aug 2012 10:06:15 +0200 In-Reply-To: <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> (William Mills's message of "Wed, 29 Aug 2012 22:35:40 -0700 (PDT)") Message-ID: <87fw742494.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 08:06:36 -0000 William Mills writes: > How is the mechanism different form the application in this case?  I > really don't get why there is a problem here, in fact this wasn't a > problem until the gs2-header actually got added.  Before the gs2-header was added, the mechanism did not support transferring an authzid which would be a serious problem. Adding the gs2-header solves both the GS2 compatibility issue, and enables transport of the authzid. > Why can't the mechanism itself be asserting the identity? The authzid is asserted by the SMTP/IMAP/etc client. I agree with Luke that we shouldn't conflate SASL and OAuth authorization identities. SASL mechanisms should transfer a SASL authzid and that's it. The SASL authzid should not be involved in anything the mechanism does. /Simon > > > > >>________________________________ >> From: Luke Howard >>To: Alexey Melnikov >>Cc: Nico Williams ; William Mills >> ; "kitten@ietf.org" >>Sent: Wednesday, August 29, 2012 5:22 PM >>Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 >> >> >>On 29/08/2012, at 5:47 PM, Alexey Melnikov wrote: >> >>> I am very confused: the format of authorization identities is >>> controlled by protocols using SASL and not by mechanisms. It MUST >>> NOT be specified in a SASL mechanism. >> >>My understanding is that we are conflating SASL and OAuth >> authorisation identities. SASL authorisation identities should be >> carried per the GS2 specification and are for the SASL >> implementation or application to handle, not the mechanism. OAuth >> authorisation semantics might be exposed via GSS naming extensions. >> >>-- Luke >> >> > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From wmills@yahoo-inc.com Thu Aug 30 08:06:33 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D825321F8622 for ; Thu, 30 Aug 2012 08:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.555 X-Spam-Level: X-Spam-Status: No, score=-17.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 fHzROveAeOo1 for ; Thu, 30 Aug 2012 08:06:32 -0700 (PDT) Received: from nm14-vm0.bullet.mail.ac4.yahoo.com (nm14-vm0.bullet.mail.ac4.yahoo.com [98.139.52.234]) by ietfa.amsl.com (Postfix) with SMTP id D1FDB21F8611 for ; Thu, 30 Aug 2012 08:06:31 -0700 (PDT) Received: from [98.139.52.192] by nm14.bullet.mail.ac4.yahoo.com with NNFMP; 30 Aug 2012 15:06:24 -0000 Received: from [98.139.52.149] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 30 Aug 2012 15:06:24 -0000 Received: from [127.0.0.1] by omp1032.mail.ac4.yahoo.com with NNFMP; 30 Aug 2012 15:06:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 620216.74766.bm@omp1032.mail.ac4.yahoo.com Received: (qmail 85858 invoked by uid 60001); 30 Aug 2012 15:06:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346339183; bh=+/gqvFXN/h1dxbw9MJiVZ9p+JHNcuQxdiJ8o5/Jg6OA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cBqi3KLcb+DDBGcVk05wVJD6ZHd0gDJoJvHIrn9+fK40XlYBO8S2F2ZXrgxaD8bwzEvVlkq9R5bfHIFHs7jZ33L6JxOKTmakBHWEEC5prEAyeq7ftBy7jaNE7sst3YdjB1Yj8MdMiIIWducF5Oq1d2Lv25iXEXfch+UdYfSa3Kg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rBxBUQhIK4jnZJQKQ7jgICeHkCzslvELeOW6mNygP0mn6t2+sC7EAfG8SWopvYdQZ1ovl9RH2QZQvRrkVtVy6EOE8gvZsEUpRfvoNU1B6QV8mYrRjT/BWR+crSCJ3VFrepw8fTVOIuAuoxXIiToxaywWFGJ2cqCvVucNsRJX9ng=; X-YMail-OSG: 967bPtYVM1lj46nNe5B9w1V7dQnu5R_G20bdr5s.eoFkd_F FlbaVBSGKz08OpLRH08O93b8IwwF4BDiG1n8chS5MWDauhfgLNT602_ExuL3 vktpfnb02EGvs9gDL1MV0fcWtI7LXMQtoexrQcjgJRoSMrl1upHoPl6_MqhQ Iwy4Jci0KN6u3iWerF98OyiJmgrO5ViPRdUZMeU76KgeuP47NAQdsJab_XSy Ffsb3mM5DWLZlIaWFs3KQoU7bl7Zi33DJp3DkeaUqszEmaHqGudBOzr1CDVH hiOB9eKqqPCB92BOmERdd3jNVleJUCTB2UBL.0nFQ8rQWOpyAN5GgcAt1D4R AjNYcT8GyB6NVYfWzN0d6iPyiuh72jxU9S.4BwhD1vNOIhCpmglYrNqOkaIZ YrUHCoLinsCbizKuD6q18pvVs3rhN7kZJij4V_my58tKJY5Qw7ayFElXBiyj 6Qq5YaQ0- Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Thu, 30 Aug 2012 08:06:23 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> Message-ID: <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 08:06:23 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87fw742494.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-563560891-1346339183=:7746" Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 15:06:34 -0000 ---1055047407-563560891-1346339183=:7746 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Authz id has always been supported in this draft.=0A=0AGiven the way it's c= urrently written is there a problem?=0A=0A=0A=0A=0A=0A>____________________= ____________=0A> From: Simon Josefsson =0A>To: William= Mills =0A>Cc: Luke Howard ; Alexey = Melnikov ; "kitten@ietf.org" = =0A>Sent: Thursday, August 30, 2012 1:06 AM=0A>Subject: Re: Comma vs. %x01 = Re: OAuth SASL draft -05=0A> =0A>William Mills write= s:=0A>=0A>> How is the mechanism different form the application in this cas= e?=A0 I=0A>> really don't get why there is a problem here, in fact this was= n't a=0A>> problem until the gs2-header actually got added.=A0=0A>=0A>Befor= e the gs2-header was added, the mechanism did not support=0A>transferring a= n authzid which would be a serious problem.=A0 Adding the=0A>gs2-header sol= ves both the GS2 compatibility issue, and enables=0A>transport of the authz= id.=0A>=0A>> Why can't the mechanism itself be asserting the identity?=0A>= =0A>The authzid is asserted by the SMTP/IMAP/etc client.=A0 I agree with Lu= ke=0A>that we shouldn't conflate SASL and OAuth authorization identities.= =0A>SASL mechanisms should transfer a SASL authzid and that's it.=A0 The SA= SL=0A>authzid should not be involved in anything the mechanism does.=0A>=0A= >/Simon=0A>=0A>>=0A>>=0A>>=0A>>=0A>>>________________________________=0A>>>= From: Luke Howard =0A>>>To: Alexey Melnikov =0A>>>Cc: Nico Williams ; William Mill= s=0A>>> ; "kitten@ietf.org" =0A>>>Se= nt: Wednesday, August 29, 2012 5:22 PM=0A>>>Subject: Re: [kitten] Comma vs.= %x01 Re: OAuth SASL draft -05=0A>>> =0A>>>=0A>>>On 29/08/2012, at 5:47 PM,= Alexey Melnikov wrote:=0A>>>=0A>>>> I am very = confused: the format of authorization identities is=0A>>>> controlled by pr= otocols using SASL and not by mechanisms. It MUST=0A>>>> NOT be specified i= n a SASL mechanism.=0A>>>=0A>>>My understanding is that we are conflating S= ASL and OAuth=0A>>> authorisation identities. SASL authorisation identities= should be=0A>>> carried per the GS2 specification and are for the SASL=0A>= >> implementation or application to handle, not the mechanism. OAuth=0A>>> = authorisation semantics might be exposed via GSS naming extensions.=0A>>>= =0A>>>-- Luke=0A>>>=0A>>>=0A>> ____________________________________________= ___=0A>> Kitten mailing list=0A>> Kitten@ietf.org=0A>> https://www.ietf.org= /mailman/listinfo/kitten=0A>=0A>=0A> ---1055047407-563560891-1346339183=:7746 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Authz id = has always been supported in this draft.

Given the way it's currentl= y written is there a problem?


From: Simon Josefsson <simon@= josefsson.org>
To: = William Mills <wmills@yahoo-inc.com>
Cc: Luke Howard <lukeh@padl.com>; Alexey Melniko= v <alexey.melnikov@isode.com>; "kitten@ietf.org" <kitten@ietf.org&g= t;
Sent: Thursday, Au= gust 30, 2012 1:06 AM
Subject: Re: Comma vs. %x01 Re: OAuth SASL draft -05
William Mills <wmills@yahoo-inc.com> writes:

> Ho= w is the mechanism different form the application in this case?  I
= > really don't get why there is a problem here, in fact this wasn't a> problem until the gs2-header actually got added. 

Before = the gs2-header was added, the mechanism did not support
transferring an = authzid which would be a serious problem.  Adding the
gs2-header so= lves both the GS2 compatibility issue, and enables
transport of the auth= zid.

> Why can't the mechanism itself be asserting the identity?

The authzid is asserted by the SMTP/IMAP/etc client. = ; I agree with Luke
that we shouldn't conflate SASL and OAuth authorizat= ion identities.
SASL mechanisms should transfer a SASL authzid and that'= s it.  The SASL
authzid should not be involved in anything the mech= anism does.

/Simon

>
>
>
>
>>__= ______________________________
>> From: Luke Howard <lukeh@padl.com>
>>To: Alexey Melnikov <alexey.melnikov@iso= de.com>
>>Cc: Nico Williams <nico@cryptonector.c= om>; William Mills
>> <wmills@yahoo-inc.com>= ; "kitten@= ietf.org" <kitten@ietf.org>
>>Sent: Wednesday, August 29,= 2012 5:22 PM
>>Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SAS= L draft -05
>>
>>
>>On 29/08/2012, at 5:47 PM, = Alexey Melnikov <alexey.melnikov@isode.com> wrote:=
>>
>>> I am very confused: the format of authorizatio= n identities is
>>> controlled by protocols using SASL and not = by mechanisms. It MUST
>>> NOT be specified in a SASL mechanism= .
>>
>>My understanding is that we are conflating SASL an= d OAuth
>> authorisation identities. SASL authorisation identities= should be
>> carried per the GS2 specification and are for the SASL
>> implementation or application to handle, not the mechanis= m. OAuth
>> authorisation semantics might be exposed via GSS namin= g extensions.
>>
>>-- Luke
>>
>>
>= ; _______________________________________________
> Kitten mailing li= st
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kit= ten


---1055047407-563560891-1346339183=:7746-- From nico@cryptonector.com Thu Aug 30 08:07:33 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43F221F8619 for ; Thu, 30 Aug 2012 08:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-1.272, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6] 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 Iu0KZwYgHx8e for ; Thu, 30 Aug 2012 08:07:33 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5271521F8617 for ; Thu, 30 Aug 2012 08:07:33 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id D795E35005B for ; Thu, 30 Aug 2012 08:07:32 -0700 (PDT) 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; s=cryptonector.com; bh=Mdknhwgagp/8m7Ga6oim q3kVUTg=; b=NoJGpCRKvGJVhcg5KTxTS3eEvjeL4Z/N0ZY4uyIBnB1Afs3x82gj QGcogA9ejddbexWZN8swCxBiOzYytzVUDEZiK0fWKMmSjtYFODjxGI3sYD7h3eCH 8crB0vxgALGNzlDTz+V+PgLJM/Hq2M02WyU+4Aqha3FA5KXP6Ddv95c= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id BCBEA350058 for ; Thu, 30 Aug 2012 08:07:32 -0700 (PDT) Received: by dadf8 with SMTP id f8so1225589dad.31 for ; Thu, 30 Aug 2012 08:07:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.34 with SMTP id ib2mr11878477pbc.164.1346339252326; Thu, 30 Aug 2012 08:07:32 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 30 Aug 2012 08:07:31 -0700 (PDT) In-Reply-To: <1346304940.59715.YahooMailNeo@web31809.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 10:07:31 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 15:07:33 -0000 On Thu, Aug 30, 2012 at 12:35 AM, William Mills wrote: > How is the mechanism different form the application in this case? I really I dont'get this question :) The mechanism and the application are entirely different :) > don't get why there is a problem here, in fact this wasn't a problem until > the gs2-header actually got added. > > Why can't the mechanism itself be asserting the identity? Only the client application asserts an authz-id. The mechanism is only required to transport it. The mechanism transports the authz-id, via the gs2-header. Why via the gs2-header? Because GSS mechanisms *do not* have an authz-id concept, so the authz-id has to be carried outside the _GSS_ mechanism but _inside_ the SASL mechanism. The whole point of the gs2-header is to make it possible to use GSS mechanisms as SASL mechanisms. So a GSS mechanism used with the gs2-header (and a SASL mech name) *is* a SASL mechanism. Nico -- From nico@cryptonector.com Thu Aug 30 08:15:59 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D865E21F8510 for ; Thu, 30 Aug 2012 08:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 l07YH2YJvJEW for ; Thu, 30 Aug 2012 08:15:59 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 37A6D21F850C for ; Thu, 30 Aug 2012 08:15:59 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id E563459405E for ; Thu, 30 Aug 2012 08:15:58 -0700 (PDT) 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; s=cryptonector.com; bh=1NK9KbkybKW3W3YcBEl4 qLDFCaI=; b=RycTqOseg9uWPAWiXzq6xbYkq6cBgr36FoDbV0TKiiamapRQElwi kJJXn8Td8xsPUaN/IHeV8y6utIq66D9uvIX5E7iAg8g+dPHq2o5IVeJvWzmsaZFq kbzXPxrFzYA9WRn6B9Ml+GX/PXTVRzttSP/NpGvcVwAuyAsa4MRenDA= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id CBBBB59401C for ; Thu, 30 Aug 2012 08:15:58 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3196324pbb.31 for ; Thu, 30 Aug 2012 08:15:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.75.97 with SMTP id b1mr10423925paw.15.1346339758328; Thu, 30 Aug 2012 08:15:58 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 30 Aug 2012 08:15:58 -0700 (PDT) In-Reply-To: <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 10:15:58 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 15:16:00 -0000 On Thu, Aug 30, 2012 at 10:06 AM, William Mills wrote: > Authz id has always been supported in this draft. > > Given the way it's currently written is there a problem? I think we're talking about the text of section 3.2.1, and the 'user' key/value described in section 3.1. Section 3.2.1 describes an authorization ID that has very different semantics from the SASL authz-id, or at least that is so *to my reading*. If my reading is wrong and the authz-id described in 3.2.1 has SASL-compatible semantics then what you should do is simply remove the 'user' key in section 3.1. Else if my reading is correct then you need to distinguish the OAuth authz-id from the SASL authz-id. Nico -- From wmills@yahoo-inc.com Thu Aug 30 08:27:05 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC31121F8534 for ; Thu, 30 Aug 2012 08:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.556 X-Spam-Level: X-Spam-Status: No, score=-17.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 bLUcNb8Uwyxe for ; Thu, 30 Aug 2012 08:27:04 -0700 (PDT) Received: from nm37-vm1.bullet.mail.ne1.yahoo.com (nm37-vm1.bullet.mail.ne1.yahoo.com [98.138.229.129]) by ietfa.amsl.com (Postfix) with SMTP id DA14721F84B6 for ; Thu, 30 Aug 2012 08:27:03 -0700 (PDT) Received: from [98.138.90.49] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 15:27:00 -0000 Received: from [98.138.89.250] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 15:27:00 -0000 Received: from [127.0.0.1] by omp1042.mail.ne1.yahoo.com with NNFMP; 30 Aug 2012 15:27:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 656997.78228.bm@omp1042.mail.ne1.yahoo.com Received: (qmail 86502 invoked by uid 60001); 30 Aug 2012 15:27:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346340420; bh=60NhFsh08LEhml9uZvTiAvoFazDvfVg9g2tWIdt5fKg=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=q1d4y/gpZQ3tI+n8+zHhQ/BpPwwhqPRwVLf8vXCcThL+wDYIEDjvz8FqKQKZllV9JUpW8TzZiIq0swsD9edJfQ+dPFMZwxofAnIY3XUszjmENLCHP/sXzSRf8Q8kIATZGz0BQky/ttuB6scL5s5ohTP0Vk2AujEXEydXu4rbHlA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Bpx+YhB15Vy7Fki7UKNgyurBUd/PGENkeQJ4Wmob9loqx8zAXQiYZAZlt/GagtpnCUbthq8ILOz4pjZfRlAZUPXBYVOCO4FvSPOZubnbu5DgtrFtIU2rIRrm436J2bLvZk0f6A+3/LK+MF0xBijf06tDlAMrAGr5Qfm3+LA1fCo=; X-YMail-OSG: e.YqvaEVM1kd1LQiv6Eo2GeXdedshp5oNXosWWlXSvK2ULd PSpB4KgBvn6SklBBtljtwf6UbTRQU3cNq..PIGtv4iAadz5Z2wSopKgofScO TvhvxvuZ_s3oIurKKFWfC01K06.Xy69Nj_.A0ivQVoPq71jKSNTfJY8WS4rw H_IiI67RGocMDpgSGqPFLd5uvb2yGzJqh8upPK8WR8AkzJIAf.YYfyNj70dB P54ZLTE7J63L1mQAjofSwpDbFqOJnqhamB_mj0mM6rr7PSfd5T7OEN4ZMW35 GkQZ6zxvSdmNsQz7s207HrR98Ra0_zkbJ_3OmvhbNpcn1ALo6SN4K9ING8Xj 39CPHbjBbDCXrQ9YqNyqdQLe6NvjMrdgIzbPS1YJqeBnhl6ADMTK9xthgOof w9yJxAS_wUcTXTOEYy8UnYPyOEPelwHhITSP4s7RiDQpuT9hq8ByvKvqpWU1 qTtuRPNM- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Thu, 30 Aug 2012 08:27:00 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 08:27:00 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-2147128420-1346340420=:52884" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 15:27:06 -0000 ---1238014912-2147128420-1346340420=:52884 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable User is needed in the purely SASL part of this so if the gs2 header isn't a= vailable then it has to be carried somewhere.=A0 I can require that they be= identical if that will help.=0A=0A=0A=0A=0A=0A>___________________________= _____=0A> From: Nico Williams =0A>To: William Mills = =0A>Cc: Simon Josefsson ; "kitt= en@ietf.org" =0A>Sent: Thursday, August 30, 2012 8:15 AM= =0A>Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>O= n Thu, Aug 30, 2012 at 10:06 AM, William Mills wrote= :=0A>> Authz id has always been supported in this draft.=0A>>=0A>> Given th= e way it's currently written is there a problem?=0A>=0A>I think we're talki= ng about the text of section 3.2.1, and the 'user'=0A>key/value described i= n section 3.1.=0A>=0A>Section 3.2.1 describes an authorization ID that has = very different=0A>semantics from the SASL authz-id, or at least that is so = *to my=0A>reading*.=A0 If my reading is wrong and the authz-id described in= 3.2.1=0A>has SASL-compatible semantics then what you should do is simply r= emove=0A>the 'user' key in section 3.1.=A0 Else if my reading is correct th= en you=0A>need to distinguish the OAuth authz-id from the SASL authz-id.=0A= >=0A>Nico=0A>--=0A>=0A>=0A> ---1238014912-2147128420-1346340420=:52884 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
User is n= eeded in the purely SASL part of this so if the gs2 header isn't available = then it has to be carried somewhere.  I can require that they be ident= ical if that will help.


From: Nico Williams <nico@cryptonecto= r.com>
To: William = Mills <wmills@yahoo-inc.com>
Cc: Simon Josefsson <simon@josefsson.org>; "kitten= @ietf.org" <kitten@ietf.org>
Sent: Thursday, August 30, 2012 8:15 AM
Subject: Re: [kitten] Comma vs. %x01 Re: OA= uth SASL draft -05

On Thu, Aug 30, 2012 at 10:06 AM,= William Mills <wmills@yahoo-inc.com> wrote:
> Authz i= d has always been supported in this draft.
>
> Given the way it= 's currently written is there a problem?

I think we're talking about= the text of section 3.2.1, and the 'user'
key/value described in sectio= n 3.1.

Section 3.2.1 describes an authorization ID that has very dif= ferent
semantics from the SASL authz-id, or at least that is so *to myreading*.  If my reading is wrong and the authz-id described in 3.2.1
has SASL-compatible semantics then what you should do is simply r= emove
the 'user' key in section 3.1.  Else if my reading is correct= then you
need to distinguish the OAuth authz-id from the SASL authz-id.=

Nico
--


---1238014912-2147128420-1346340420=:52884-- From nico@cryptonector.com Thu Aug 30 09:09:30 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8117B21F859E for ; Thu, 30 Aug 2012 09:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=-0.954, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 GScLrHSyHP3n for ; Thu, 30 Aug 2012 09:09:29 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id D3FD021F8594 for ; Thu, 30 Aug 2012 09:09:29 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 80C2C1E07C for ; Thu, 30 Aug 2012 09:09:29 -0700 (PDT) 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; s=cryptonector.com; bh=tmrtgszGg85q3CvIfelv m9IEqCA=; b=UlsQUQIq2eD5vGEa6pDiezVdzKz9m+Sfv5NmwZycNNbU4KBvRjh1 6vPwkiL1kj2enyVxC1zdOhFyAusVvZZQYKL1GQoGLKREkzu1CwHy4lnWVVOjLfg6 QFfn+CmvlTbCEHlDrsatClZWY+HpmEUfclMW4NrcJElWIGUfD08eAeY= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 64F991E05C for ; Thu, 30 Aug 2012 09:09:29 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3273590pbb.31 for ; Thu, 30 Aug 2012 09:09:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.34 with SMTP id ib2mr12106251pbc.164.1346342968868; Thu, 30 Aug 2012 09:09:28 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 30 Aug 2012 09:09:28 -0700 (PDT) In-Reply-To: <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 11:09:28 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 16:09:30 -0000 On Thu, Aug 30, 2012 at 10:27 AM, William Mills wrote: > User is needed in the purely SASL part of this so if the gs2 header isn't > available then it has to be carried somewhere. I can require that they be > identical if that will help. But... the whole point is that in a SASL context the gs2-header is always present so why would the gs2-header not be available? It wouldn't be available only in a pure GSS, non-SASL context -- a context in which we don't need an authz-id anyways. My advice: remove the 'user' key. From wmills@yahoo-inc.com Thu Aug 30 09:13:38 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1B121F8554 for ; Thu, 30 Aug 2012 09:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.556 X-Spam-Level: X-Spam-Status: No, score=-17.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 cx-eyhfjEz7J for ; Thu, 30 Aug 2012 09:13:37 -0700 (PDT) Received: from nm37-vm3.bullet.mail.bf1.yahoo.com (nm37-vm3.bullet.mail.bf1.yahoo.com [72.30.238.203]) by ietfa.amsl.com (Postfix) with SMTP id 52A9B21F8551 for ; Thu, 30 Aug 2012 09:13:37 -0700 (PDT) Received: from [98.139.212.145] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 30 Aug 2012 16:13:36 -0000 Received: from [98.139.212.245] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 30 Aug 2012 16:13:36 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 30 Aug 2012 16:13:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 444206.87086.bm@omp1054.mail.bf1.yahoo.com Received: (qmail 11583 invoked by uid 60001); 30 Aug 2012 16:13:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346343215; bh=yPkJVgUGXW07JbvNR9XxSkGahRSAhknQJ5VIcVGoO0k=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=igbGFI1XEIYQDe8DNijHz0arUabj27Tbj7EvNF2oExahmd4btjX6Bw2EAmrKF5gDYVcbYIjtWV9r34EK76ivUgPPwemIX3TWhF/uf8A0JMt28Z0BkUCDpAZvqPBZtv1yrTBgSmOq9COgkGvgMaN4NFfiObfobsbQl4janYD/J64= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=W/L/s+9hkm/tFRJpW7INNfpyLvppCh5HG2POJDV86IhKHaOE5vizhFROv8/iWiNdxO3HcDOWHnLMietVqXs1PDlxVYqSTLhfdfcPBfhKE5BCZc66BKuW6XzAsm1sT5B2dT1AvT5ZgdvsQD5vRJtBLoDTgp109CAgcWiY04ncoy0=; X-YMail-OSG: a5b6.3gVM1lVG1hvn7eytG1tuttsegh6nFbgudjbogIHAlE vSofTs8Jvp_GmFgN1APqLcQXvLpdNeeF64srsVbXgfUW.eT4B5No4a2HrCsx aV8q08v9eOrQbauCVJGlU.pcy3qcvJdbgciYsNKQ32V..JugZnkT9EG73Qww wW3A71XmyjE8Sd9uqme8eAMoEc.K5glXp0Cz05.orURavdmkzMIg.XT4YHvp zvBlTqfV1gcI4v.Mns7Jl3gB8WKNzUGR7XjBsnaEH07vegjWO0abLFwQ1l.t h7QCshMLRMVbm_87NtYqfY8gyEIn2MTQzhUdyqE4PyATTw0r7YZA1yq3XcJX DBmGPeMr1IGYiTpIXcIO5gOnKgAbrKoyjl0OQ6D5rH.jGNllAqfRlhrnUAdk TWGpO7VXiOuOaiEXNI1L.1MfnJyHfW.56yCo4sZ0vt04NVK4uOPgyT8YpEsR Yu264yg-- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Thu, 30 Aug 2012 09:13:35 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> Message-ID: <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 09:13:35 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-728878592-1346343215=:93231" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 16:13:38 -0000 --1458549034-728878592-1346343215=:93231 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable One purpose of the user key is as a routing hint.=A0 Are you sayng that wou= ld never be needed in a GS2 environment?=0A=0A=0A=0A=0A=0A>________________= ________________=0A> From: Nico Williams =0A>To: Wil= liam Mills =0A>Cc: Simon Josefsson ; "kitten@ietf.org" =0A>Sent: Thursday, August 30, 20= 12 9:09 AM=0A>Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05= =0A> =0A>On Thu, Aug 30, 2012 at 10:27 AM, William Mills wrote:=0A>> User is needed in the purely SASL part of this so if the g= s2 header isn't=0A>> available then it has to be carried somewhere.=A0 I ca= n require that they be=0A>> identical if that will help.=0A>=0A>But...=A0 t= he whole point is that in a SASL context the gs2-header is=0A>always presen= t so why would the gs2-header not be available?=A0 It=0A>wouldn't be avail= able only in a pure GSS, non-SASL context -- a=0A>context in which we don't= need an authz-id anyways.=0A>=0A>My advice: remove the 'user' key.=0A>=0A>= =0A> --1458549034-728878592-1346343215=:93231 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
One purpo= se of the user key is as a routing hint.  Are you sayng that would nev= er be needed in a GS2 environment?


=
From: Nico Williams <nico@= cryptonector.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: Simon Josefsson <simon@josefsson.org>; "k= itten@ietf.org" <kitten@ietf.org>
Sent: Thursday, August 30, 2012 9:09 AM
Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL d= raft -05

On Thu, Aug 30, 2012 at 10:27 AM, William M= ills <wmills@yahoo-inc.com> wrote:
> User is needed in= the purely SASL part of this so if the gs2 header isn't
> available = then it has to be carried somewhere.  I can require that they be
&g= t; identical if that will help.

But...  the whole point is that= in a SASL context the gs2-header is
always present so why would the gs2= -header not be available?  It
wouldn't be available only in a pure= GSS, non-SASL context -- a
context in which we don't need an authz-id a= nyways.

My advice: remove the 'user' key.


--1458549034-728878592-1346343215=:93231-- From nico@cryptonector.com Thu Aug 30 09:20:36 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3326521F85A4 for ; Thu, 30 Aug 2012 09:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.923 X-Spam-Level: X-Spam-Status: No, score=-2.923 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Y6WG4gZPgsMQ for ; Thu, 30 Aug 2012 09:20:35 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 664EB21F8527 for ; Thu, 30 Aug 2012 09:20:35 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id C52FF94065 for ; Thu, 30 Aug 2012 09:20:34 -0700 (PDT) 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; s=cryptonector.com; bh=rM5JLRr4SXY8F3HJl1Ty H2po4Rc=; b=J7ucqPggPAXAYqDerpw5aLPlpAXC0I50+AG9PaWw8fdm2QSeADAr zY/91/E0jhhS1cK1R1NQgc1fxENUUPTdt6vi1ZB0ptoa1dohCqTJtSP4bQpX5Mgd JjewRD2FouAHGJGOcyMA+wA/7h4xtry+C/JHgtDBUUGYUw5Jex//dTw= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id AA83D9405E for ; Thu, 30 Aug 2012 09:20:34 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3288191pbb.31 for ; Thu, 30 Aug 2012 09:20:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.34 with SMTP id ib2mr12142516pbc.164.1346343634365; Thu, 30 Aug 2012 09:20:34 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 30 Aug 2012 09:20:34 -0700 (PDT) In-Reply-To: <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 11:20:34 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 16:20:36 -0000 On Thu, Aug 30, 2012 at 11:13 AM, William Mills wrote: > One purpose of the user key is as a routing hint. Are you sayng that would > never be needed in a GS2 environment? From nico@cryptonector.com Thu Aug 30 09:26:05 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9095A21F85B4 for ; Thu, 30 Aug 2012 09:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=-0.939, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 EFvrJDzFTRc0 for ; Thu, 30 Aug 2012 09:26:05 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id E952921F8587 for ; Thu, 30 Aug 2012 09:26:04 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id EA1C6286059 for ; Thu, 30 Aug 2012 09:26:03 -0700 (PDT) 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; s=cryptonector.com; bh=mvmbiBi0OhmAtprCO4WH ZwEnsp0=; b=sDAFsATgTgAKVyDpNCT+FN9NScOfWEkUETuy37ziGqzNTQJz1+Ld tRb+dGc7Nr2NNMUypH6mB/SDP7w1ShOcmlcloVaTm5OFDtSzBDHWY92GjP+cxCFO i36nzcFmDN8HoeH7CI1kWx14QevzFuXYAyTsgBx06pKy0a73MMemP58= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id CE48B286057 for ; Thu, 30 Aug 2012 09:26:03 -0700 (PDT) Received: by dadf8 with SMTP id f8so1269999dad.31 for ; Thu, 30 Aug 2012 09:26:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.211.105 with SMTP id nb9mr12487377pbc.67.1346343962971; Thu, 30 Aug 2012 09:26:02 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 30 Aug 2012 09:26:02 -0700 (PDT) In-Reply-To: <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 11:26:02 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 16:26:05 -0000 On Thu, Aug 30, 2012 at 11:13 AM, William Mills wrote: > One purpose of the user key is as a routing hint. Are you sayng that would > never be needed in a GS2 environment? Can you add some detail regarding routing? Routing of what? How does an authz-id help with routing? (The I-D doesn't go into any more detail; a search for 'rout', 'database', 'lookup', or 'hint' did not turn up anything more than the one sentence in section 3.1 about this.) Not knowing what the routing thing is about I can't tell you if that would be needed in a GSS/non-SASL context. However, since pure OAuth on the web clearly doesn't need this routing hint (otherwise you'd not be adding it here, right?), I don't think we should need it in a pure GSS (GSS, not GS2) environment. Nico -- From wmills@yahoo-inc.com Thu Aug 30 09:42:18 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A6621F8570 for ; Thu, 30 Aug 2012 09:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.557 X-Spam-Level: X-Spam-Status: No, score=-17.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 zBTKVZIwqEV2 for ; Thu, 30 Aug 2012 09:42:17 -0700 (PDT) Received: from nm7-vm0.bullet.mail.ac4.yahoo.com (nm7-vm0.bullet.mail.ac4.yahoo.com [98.139.52.228]) by ietfa.amsl.com (Postfix) with SMTP id 283C821F854D for ; Thu, 30 Aug 2012 09:42:17 -0700 (PDT) Received: from [98.139.52.188] by nm7.bullet.mail.ac4.yahoo.com with NNFMP; 30 Aug 2012 16:42:10 -0000 Received: from [98.139.52.170] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 30 Aug 2012 16:42:10 -0000 Received: from [127.0.0.1] by omp1053.mail.ac4.yahoo.com with NNFMP; 30 Aug 2012 16:42:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 769734.55871.bm@omp1053.mail.ac4.yahoo.com Received: (qmail 40566 invoked by uid 60001); 30 Aug 2012 16:42:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346344930; bh=5jdzzZg1XWIRS1e3BY+LdcxNLluXnlttDKbEtpytnEY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BD0mMnrM4PZZfUwGAQwyjc8E21Zgptys2dhol0W6w85b0aIMYvJW15hr+QbEjEyPOrDtsagwymiPQ0wKbYPo1qC1y/aTx7voOJfy7fS8U6QJEXaEiy/6qiUSgkxv+7/10Yzdo9Ad75TY/bgGlBvd6ngroSamhakEElNJuoQzjII= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pBt5C9bOSfqZAfVksL8QKdPISJ2NFbiXsFWSNV+e6I5PrJFp5ggb3SI3jLwDXoTi456kpdEcFDfqSt48cFmDyVBPy+DCpI4ldF9cPdvVN13d01GUoBuBgGXVpOZ8A/KKjjpPSOvmCZl3G7EhKtV+uZA4jDogQDZUyXE2KfuzpAc=; X-YMail-OSG: ZgMe3f0VM1kJHqKaGMgh_uQBmoaY2VgH4Taw.hYJGIrvjJs JsNL_FRgUqjL7_y_6C4o1Lug6hmk4bNdGQ_l9EU5FGm4dTXGNrXPiUrR4RG4 MzEzNFIOI.egJQJbppc.CbpikMrdN0RgtlSKK2K2vYRECCU7tXVTuJq223oa UGeDIlFQDxM8QTDxl0_9jNm6n8IeSil4Gfs5j8w2lONSxUTnuZQubcCcAKDP AzlUZf2dPn36ynvSBspyFt8WKtNL6o6gqtoHLanMhUQLJsLgAwlyfJMfgInI s78PN9NzVrUo.ZNSZ.kEu1lgCV63rm_HojXDmOAobsLidkG9nCC.4lAxqXDm Am105nKM7jThjHcjgHktZzeUsqBrHbUzWUf02_tFJ02Li.YbWxVnLv0q5RLM CyEZ7X3KdzDksA_XDz5BKzYB0Vvy1Mbzlw6.R1lwk_uR7kzND_0L7z7gPgHS dt5Wd8A-- Received: from [209.131.62.115] by web31802.mail.mud.yahoo.com via HTTP; Thu, 30 Aug 2012 09:42:09 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> Message-ID: <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 09:42:09 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-1691638635-1346344929=:36729" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 16:42:18 -0000 ---1036955950-1691638635-1346344929=:36729 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The problem the routing hint solves is large installations that have "shard= s" an you want to be able to send proxied traffic on to the correct interna= l endpoint.=0A=0A=0A=0A=0A=0A>________________________________=0A> From: Ni= co Williams =0A>To: William Mills =0A>Cc: Simon Josefsson ; "kitten@ietf.org" =0A>Sent: Thursday, August 30, 2012 9:26 AM=0A>Subject: Re: [k= itten] Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>On Thu, Aug 30, 2012= at 11:13 AM, William Mills wrote:=0A>> One purpose = of the user key is as a routing hint.=A0 Are you sayng that would=0A>> neve= r be needed in a GS2 environment?=0A>=0A>Can you add some detail regarding = routing?=A0 Routing of what?=A0 How does=0A>an authz-id help with routing?= =A0 (The I-D doesn't go into any more=0A>detail; a search for 'rout', 'data= base', 'lookup', or 'hint' did not=0A>turn up anything more than the one se= ntence in section 3.1 about=0A>this.)=0A>=0A>Not knowing what the routing t= hing is about I can't tell you if that=0A>would be needed in a GSS/non-SASL= context.=A0 However, since pure OAuth=0A>on the web clearly doesn't need t= his routing hint (otherwise you'd not=0A>be adding it here, right?), I don'= t think we should need it in a pure=0A>GSS (GSS, not GS2) environment.=0A>= =0A>Nico=0A>--=0A>=0A>=0A> ---1036955950-1691638635-1346344929=:36729 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The probl= em the routing hint solves is large installations that have "shards" an you= want to be able to send proxied traffic on to the correct internal endpoin= t.


From: Nico Williams <nico@cryptonector.com>
To: William Mills <wmills@yaho= o-inc.com>
Cc: Simo= n Josefsson <simon@josefsson.org>; "kitten@ietf.org" <kitten@ietf.org> Sent: Thursday, August 3= 0, 2012 9:26 AM
Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05
=
On Thu, Aug 30, 2012 at 11:13 AM, William Mills <wmills@yahoo-i= nc.com> wrote:
> One purpose of the user key is as a routing h= int.  Are you sayng that would
> never be needed in a GS2 enviro= nment?

Can you add some detail regarding routing?  Routing of w= hat?  How does
an authz-id help with routing?  (The I-D doesn'= t go into any more
detail; a search for 'rout', 'database', 'lookup', or= 'hint' did not
turn up anything more than the one sentence in section 3= .1 about
this.)

Not knowing what the routing thing is about I can't tell you if that
would be needed in a GSS/non-SASL context. = However, since pure OAuth
on the web clearly doesn't need this routing = hint (otherwise you'd not
be adding it here, right?), I don't think we s= hould need it in a pure
GSS (GSS, not GS2) environment.

Nico
-= -


---1036955950-1691638635-1346344929=:36729-- From nico@cryptonector.com Thu Aug 30 12:21:25 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C84521F861A for ; Thu, 30 Aug 2012 12:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 wDetNEDe-cNl for ; Thu, 30 Aug 2012 12:21:24 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id E6CC121F84B8 for ; Thu, 30 Aug 2012 12:21:23 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 7B581594061 for ; Thu, 30 Aug 2012 12:21:23 -0700 (PDT) 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; s=cryptonector.com; bh=TSGbzXl1MiUfvwotxyg3 KCv9tk8=; b=HPfQDjM6GDSYlx6hFgTSPilZAd2CK15jm+Vwy3DETNgIHgzW+jqK yhesqs7V7CVVt0Bk4k/MOmA3gg6nUoNKYUPIbCS+6E0vL91vUVgLxvNOAwjh/HJN SEyIIIpvMLmB6BTHOTdWtoIIArUCZs2s8sm9BwnVlbh63HR6UIIcfsk= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 60B0F59405E for ; Thu, 30 Aug 2012 12:21:23 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3521985pbb.31 for ; Thu, 30 Aug 2012 12:21:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.129.73 with SMTP id nu9mr13116814pbb.59.1346354482917; Thu, 30 Aug 2012 12:21:22 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 30 Aug 2012 12:21:22 -0700 (PDT) In-Reply-To: <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 14:21:22 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 19:21:25 -0000 On Thu, Aug 30, 2012 at 11:42 AM, William Mills wrote: > The problem the routing hint solves is large installations that have > "shards" an you want to be able to send proxied traffic on to the correct > internal endpoint. I must be missing a lot of context. What's that got to do with authz-ids?? Can't the authenticated ID be used for this? How does OAuth, natively, outside SASL, deal with this? From rtroll@google.com Thu Aug 30 12:52:22 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F21221F861A for ; Thu, 30 Aug 2012 12:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.926 X-Spam-Level: X-Spam-Status: No, score=-102.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 UnVRRcG7Teew for ; Thu, 30 Aug 2012 12:52:21 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E0B3621F8616 for ; Thu, 30 Aug 2012 12:52:20 -0700 (PDT) Received: by qcac10 with SMTP id c10so1794914qca.31 for ; Thu, 30 Aug 2012 12:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=Luy9ZOERpYpDH1r0RngVTkmrWdaHikJih/gkB+DmVQg=; b=cZzhfzifmU8W3v0AELhVmcDm3JG0D2zsZRoVf6I/0Ynt1Pf4Pls/gE/phwFN1MSISR NJ3CFZXIFn5AENB2KXHvLhliQm8Osh5WzOqAs7LDn0R4Bgy69VaugtRBQNcu2CjRCLfp jtQCjDDA3eJNWpvaBoTbR+EpkTSLquvnkjR5A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Luy9ZOERpYpDH1r0RngVTkmrWdaHikJih/gkB+DmVQg=; b=czAO+lxvl2FXyAIPUviQDtg6D/9GXtMfPz4qdQ2d5a4Y2EOREnkgWiAxbO7RVQFZcp ymUdbQE1kKe0sWFC3I6MVqQEOFdTVISmkkXfQaU0trivd4ihUGj6wf2gol20AzXF0tNK htjno3EuLQXu3sHJoPMwHAeeTTN2+x/Pd40i4ylTJoTEUc5IazTmOSaD+0OxkvEule0n PPfWPNHqT5Wzu4DOa974+up0f5DDWqb7vLdPYC42+M0TLiF1N8kwCV0+9Ws5MmBDFPww 78CPOKWxVnHbhZMyPtVbtfz/4bj3Pun5Bv3nK01r69rKOAOVz0jfiCOqSzg30vnzQNtg agtw== Received: by 10.229.135.21 with SMTP id l21mr3661037qct.7.1346356340234; Thu, 30 Aug 2012 12:52:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.21 with SMTP id l21mr3661026qct.7.1346356339977; Thu, 30 Aug 2012 12:52:19 -0700 (PDT) Received: by 10.49.132.202 with HTTP; Thu, 30 Aug 2012 12:52:19 -0700 (PDT) In-Reply-To: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 12:52:19 -0700 Message-ID: From: Ryan Troll To: Nico Williams Content-Type: multipart/alternative; boundary=00248c768ed262ae8304c8810356 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmpw/FwFBBgG6wSsU+y1PJJBbflVALjM+kjyQ7kxXHVnttjGdbCYucymcp2o/QeWQVe7ENN0ECE9yl5N+IV7m+vLtlSRBSaSSuYhIZ/vWnYAZAdGhFUcvIqalvYjW/agDreBZ7bd831BpXLf3znVkhned9vK22k6HQhyACWCM0j65vRztfWf2Qz+w4RWJou/N9qq3lf Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 19:52:22 -0000 --00248c768ed262ae8304c8810356 Content-Type: text/plain; charset=ISO-8859-1 I asked for this to be included, so let me give my use case. Our resource servers are fronted with proxies, which take care of routing requests to a back-end capable of servicing the entire request. The proxy needs to be able to determine which back-end to talk to. This applies to multiple classes of resource servers -- being accessed via IMAP, SMTP, XMPP, etc. The proxy makes its back-end determination based on "a hint" sent by the client. We believe the proxy should be able to determine the hint without the need to actually verify the OAuth Token -- especially important when the tokens are Opaque, and possibly require additional round trips to unpack. Prior to this discussion, back around draft -03, we introduced the User header in order to pass the User header. After reading through this discussion - and I admit, I'm still confused about when the gs2 header is and isn't present - I believe the "hint" should be the SASL Authorization Identity. Here's my rationale, comments welcome: Looking at "SASL PLAIN", one of the simplest mechanisms, I believe this is how things should work: AUTH PLAIN bob \0 jane \0 jane-password should successfully allow Jane, to perform actions on Bob's behalf, assuming jane-password is correct *and* the server knows Jane's been given access to access Bob's account. The proxy described above would be able to route based on "bob". Likewise: AUTH PLAIN jane \0 jane-password would let Jane perform actions on her own behalf, and the proxy would route on "jane". (Authzid based on Authcid, RFC 4616, section 2, next to last paragraph.) It would be beneficial to do the same in the OAuth mechanism. Even if the Authzid equivalent field is defined the same way PLAIN does (optional, if missing server bases authzid on authcid), services that require this hint may leverage it. -R On Thu, Aug 30, 2012 at 12:21 PM, Nico Williams wrote: > On Thu, Aug 30, 2012 at 11:42 AM, William Mills > wrote: > > The problem the routing hint solves is large installations that have > > "shards" an you want to be able to send proxied traffic on to the correct > > internal endpoint. > > I must be missing a lot of context. What's that got to do with > authz-ids?? Can't the authenticated ID be used for this? How does > OAuth, natively, outside SASL, deal with this? > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > --00248c768ed262ae8304c8810356 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I asked for this to be included, so let me give my use case.

=
Our resource servers are fronted with proxies, which take care of rout= ing requests to a back-end capable of servicing the entire request. =A0The = proxy needs to be able to determine which back-end to talk to. =A0This appl= ies to multiple classes of resource servers -- being accessed via IMAP, SMT= P, XMPP, etc.

The proxy makes its back-end determination based on &qu= ot;a hint" sent by the client. =A0We believe the proxy should be able = to determine the hint without the need to actually verify the OAuth Token -= - especially important when the tokens are Opaque, and possibly require add= itional round trips to unpack.

Prior to this discussion, back around draft -03, we int= roduced the User header in order to pass the User header.


After reading through this discussion - and I admit,= I'm still confused about when the gs2 header is and isn't present = - I believe the "hint" should be the SASL Authorization Identity.= =A0Here's my rationale, comments welcome:


Looking at "SASL PLAIN", one o= f the simplest mechanisms, I believe this is how things should work:
<= div>
=A0 AUTH PLAIN bob \0 jane \0 jane-password

should successfully allow Jane, to perform actions on Bob= 9;s behalf, assuming jane-password is correct *and* the server knows Jane&#= 39;s been given access to access Bob's account. =A0The proxy described = above would be able to route based on "bob".

Likewise:

=A0 AUTH PLAIN jane = \0 jane-password

would let Jane perform actions on= her own behalf, and the proxy would route on "jane". =A0(Authzid= based on Authcid, RFC 4616, section 2, next to last paragraph.)


It would be beneficial to do the same in= the OAuth mechanism. =A0Even if the Authzid equivalent field is defined th= e same way PLAIN does (optional, if missing server bases authzid on authcid= ), services that require this hint may leverage it.

-R



On Thu, Aug 30, 2012 at 12:21 PM, Nico Williams <ni= co@cryptonector.com> wrote:
On Thu, Aug 30, 2012 at 11= :42 AM, William Mills <wmills@ya= hoo-inc.com> wrote:
> The problem the routing hint solves is large installations that have > "shards" an you want to be able to send proxied traffic on t= o the correct
> internal endpoint.

I must be missing a lot of context. =A0What's that got to do with=
authz-ids?? =A0Can't the authenticated ID be used for this? =A0How does=
OAuth, natively, outside SASL, deal with this?
___________________________________= ____________
Kitten mailing list
Kitten@ietf.org
= https://www.ietf.org/mailman/listinfo/kitten

--00248c768ed262ae8304c8810356-- From wmills@yahoo-inc.com Thu Aug 30 12:56:27 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B18821F859C for ; Thu, 30 Aug 2012 12:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.557 X-Spam-Level: X-Spam-Status: No, score=-17.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 neEWExaFo8dx for ; Thu, 30 Aug 2012 12:56:26 -0700 (PDT) Received: from nm25.bullet.mail.sp2.yahoo.com (nm25.bullet.mail.sp2.yahoo.com [98.139.91.95]) by ietfa.amsl.com (Postfix) with SMTP id C535021F856D for ; Thu, 30 Aug 2012 12:56:26 -0700 (PDT) Received: from [72.30.22.78] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 30 Aug 2012 19:56:22 -0000 Received: from [98.139.91.46] by tm12.bullet.mail.sp2.yahoo.com with NNFMP; 30 Aug 2012 19:56:21 -0000 Received: from [127.0.0.1] by omp1046.mail.sp2.yahoo.com with NNFMP; 30 Aug 2012 19:56:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 962794.79102.bm@omp1046.mail.sp2.yahoo.com Received: (qmail 40685 invoked by uid 60001); 30 Aug 2012 19:56:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346356581; bh=fcWlXxssAEvvLo6llHdvnVECGT4mrJE7qf50k96h5/I=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Rw0ici4t+g639KcCNouBQAp88i0oxWHKNsrN85536YWJpUfsRzCT8nnf97j22dF4NWeS50v8Gvz/IqG5pI1eLbu3K3oek9jGRFkPKDeyx63sitheroKSPwhlfHwUgyBf2E+5aufu2J06A+qBQMOYbeoDoA12zkqPaaeKW9leCS0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OKo2U6whsKMGufjNOCOwgKPwCfq/DEF5iNcA6z/+HrKvcviqNIla/ulPgizuHniQ8CtLmiL8GeTt50L9AcDqoMdW2BdngJNmTOETlHFzKV08u94uRQx6EvBNYWYNF88XIRNS0McdED+fXlOBYl9viryXeC8G5BIJhnA5tf9OISA=; X-YMail-OSG: ma_Tb.IVM1lwElDPhLxtnbn9WwSOrYiFZ6FO3xroqrV4x1a 8IYqv7FzU0T.C1cioeGcvUArYIPf_g9vwp0REhp52MFwa3cN5.GRYvKI5ayg 26bAGJiJOPT9aRYMmYQ5vKWx8m9hkueNF9kWJdz_9O.HsSc3gbex1y8z.Dve TPd9sgKmrX.x9RoDzfPIQg_xTykHuS_MZUawALUoK_3qls3uvp6o1vHTJ7TG TZVHg3SktTDiwlkl2UgBbus_BuhAllC1mJO4HvgYaW2uhxLYySztNZGGK0UB eWgBjyhXhFiqcRFT8_X1eG7LRjMllzq5o5qIOg3akIqCNEDucOHDaT89r9y7 1vOHVt0ty09kTqiG0Dut5cjjdUZNchQzeQSBISzkS1H1mmKz10eAgZ8hPlus fzW4X_PVorPPm.m08xGiIqbqQE8j4YXdfA5kvNWjrG28Hzj1Ww3O8ELb57ZF mzfhQ5A-- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Thu, 30 Aug 2012 12:56:20 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346343215.93231.YahooM ailNeo@web31812.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> Message-ID: <1346356580.40426.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 12:56:20 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-913297834-1346356580=:40426" Cc: "kitten@ietf.org" , Simon Josefsson Subject: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 19:56:27 -0000 ---1238014912-913297834-1346356580=:40426 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OAuth doesn't deal with it.=A0 Some applications do.=A0 =0A=0AHere are the = requirements, I DO NOT CARE how this gets solved but I really want to stop = going around and around on this.=A0 We went from user field in the spec, to= gs2-header, to gs2-header and user field, now we're back to gs2-header onl= y.=A0 Requirements:=0A=0A-=A0=A0=A0 user name available to the mechanism ou= tside the credential.=A0 I am presuming this needs to be true even when the= gs2-header is stripped.=0A=0A-=A0=A0=A0 authZ =0Aand authN IDs have to be = based on the credential but are not part of the actual credential validatio= n.=A0 =A0 =0A=0A-=A0=A0=A0 Mismatch between the user name above and the act= ual identity from the credential causes a fail. =0A=0AGimme a solution an I= 'll write it that way.=A0 I am assuming the current text I sent to the list= isn't acceptable.=0A=0A-bill=0A=0A=0A=0A=0A>______________________________= __=0A> From: Nico Williams =0A>To: William Mills =0A>Cc: Simon Josefsson ; "kitten@= ietf.org" =0A>Sent: Thursday, August 30, 2012 12:21 PM=0A= >Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>On T= hu, Aug 30, 2012 at 11:42 AM, William Mills wrote:= =0A>> The problem the routing hint solves is large installations that have= =0A>> "shards" an you want to be able to send proxied traffic on to the cor= rect=0A>> internal endpoint.=0A>=0A>I must be missing a lot of context.=A0 = What's that got to do with=0A>authz-ids??=A0 Can't the authenticated ID be = used for this?=A0 How does=0A>OAuth, natively, outside SASL, deal with this= ?=0A>=0A>=0A> ---1238014912-913297834-1346356580=:40426 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OAuth doe= sn't deal with it.  Some applications do. 

Here are the r= equirements, I DO NOT CARE how this gets solved but I really want to stop g= oing around and around on this.  We went from user field in the spec, = to gs2-header, to gs2-header and user field, now we're back to gs2-header o= nly.  Requirements:

-    use= r name available to the mechanism outside the credential.  I am presum= ing this needs to be true even when the gs2-header is stripped.
<= div style=3D"color: rgb(0, 0, 0); font-size: 18.6667px; font-family: Courie= r New,courier,monaco,monospace,sans-serif; background-color: transparent; f= ont-style: normal;">-    authZ = =0Aand authN IDs have to be based on the credential but=0A are not part of = the actual credential validation.   
-    Mismatch between the user= name above and the actual identity from the credential causes a fail.

Gimme a solution an I'll write it that way.  I am assuming the c= urrent text I sent to the list isn't acceptable.

-bill

From: Nico Wil= liams <nico@cryptonector.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: Simon Josefsson <simon@j= osefsson.org>; "kitten@ietf.org" <kitten@ietf.org>
Sent: Thursday, August 30, 2012 12:2= 1 PM
Subject: Re: [kit= ten] Comma vs. %x01 Re: OAuth SASL draft -05

On Thu,= Aug 30, 2012 at 11:42 AM, William Mills <wmills@yahoo-inc.com&= gt; wrote:
> The problem the routing hint solves is large installatio= ns that have
> "shards" an you want to be able to send proxied traffi= c on to the correct
> internal endpoint.

I must be missing a l= ot of context.  What's that got to do with
authz-ids??  Can't = the authenticated ID be used for this?  How does
OAuth, natively, outside SASL, deal with this?


---1238014912-913297834-1346356580=:40426-- From nico@cryptonector.com Thu Aug 30 13:09:02 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF8321F854B for ; Thu, 30 Aug 2012 13:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 z4Ac9APkFFnY for ; Thu, 30 Aug 2012 13:09:02 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1241121F855D for ; Thu, 30 Aug 2012 13:09:02 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id A655C76805C for ; Thu, 30 Aug 2012 13:09:01 -0700 (PDT) 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; s=cryptonector.com; bh=8iQS1X27KlZBW4iK4wVD 7lXf2WE=; b=Pw+TklV59v4pzK+vqoS7BtrNWloBC9ONQHYI7cxawsCB+DTMzq7G zo1+DiwTyRySLbmQ+LCv/peUonU6FKeGnS4vVbmWntVWU7VBe8aXy/Te6/NS5qg3 JH8dUenGRzfHxNeKLeCXoBd97XopPYHzo49clQbZG1KxvDcrMV6n47o= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 8D90B768059 for ; Thu, 30 Aug 2012 13:09:01 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3573283pbb.31 for ; Thu, 30 Aug 2012 13:09:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.34 with SMTP id ib2mr12940076pbc.164.1346357341196; Thu, 30 Aug 2012 13:09:01 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 30 Aug 2012 13:09:00 -0700 (PDT) In-Reply-To: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 15:09:00 -0500 Message-ID: From: Nico Williams To: Ryan Troll Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 20:09:02 -0000 On Thu, Aug 30, 2012 at 2:52 PM, Ryan Troll wrote: > I asked for this to be included, so let me give my use case. > > Our resource servers are fronted with proxies, which take care of routing > requests to a back-end capable of servicing the entire request. The proxy > needs to be able to determine which back-end to talk to. This applies to > multiple classes of resource servers -- being accessed via IMAP, SMTP, XMPP, > etc. > > The proxy makes its back-end determination based on "a hint" sent by the > client. We believe the proxy should be able to determine the hint without > the need to actually verify the OAuth Token -- especially important when the > tokens are Opaque, and possibly require additional round trips to unpack. OK, but why should the 'user' be the hint for this? Why not something else? > After reading through this discussion - and I admit, I'm still confused > about when the gs2 header is and isn't present - I believe the "hint" should > be the SASL Authorization Identity. Here's my rationale, comments welcome: The gs2-header will be present in all SASL contexts -- that is, in SASL apps: - IMAP - LDAP - POP3 - SUBMIT (SMTP) - ... The gs2-header will be absent in all pure GSS contexts: - NFS (v3 and v4) - SSHv2 (yes, SSHv2 can use GSS) - FTP - DNS updates with GSS-TSIG - ... > Looking at "SASL PLAIN", one of the simplest mechanisms, I believe this is > how things should work: SASL PLAIN is not a GS2 mechanism. We should probably explain what GS2 is again :) GS2 is a "bridge" that allows GSS-API mechanisms to be used as SASL mechanisms. Alternative phrasing: GS2 is a pattern for constructing SASL mechanisms such that they can also be used as GSS-API mechanisms. Here we're building a SASL mechanism based on OAuth such that it can also be used as a GSS mechanism. The main requirement for this is the gs2-header: it must be prepended to the first message from the client, and it must be prepended to the channel binding data. There exist implementations of SASL/GS2 that use GSS-API to implement the GS2 mechanisms for arbitrary GSS-API mechanisms. These implementations could never use the authz-id as a routing hint: the GSS-API layer wouldn't receive it. Duplicating the authz-id beyond the gs2-header is *fine*, but only if it's OPTIONAL, and in pure GSS-API contexts it would always be absent, which includes SASL/GS2 client implementations that use the GSS-API. > AUTH PLAIN bob \0 jane \0 jane-password > > should successfully allow Jane, to perform actions on Bob's behalf, assuming > jane-password is correct *and* the server knows Jane's been given access to > access Bob's account. The proxy described above would be able to route > based on "bob". > > Likewise: > > AUTH PLAIN jane \0 jane-password > > would let Jane perform actions on her own behalf, and the proxy would route > on "jane". (Authzid based on Authcid, RFC 4616, section 2, next to last > paragraph.) But basing the authzid on the authcid is a completely local thing. You can't have the OAuth SASL mechanism specification depend on it. My first reaction to the routing hint idea is that basing it on the authz-id is very much the wrogn thing to do. You should use only the authcid, if that. My second reaction is the same :) but maybe I'm missing something? > It would be beneficial to do the same in the OAuth mechanism. Even if the > Authzid equivalent field is defined the same way PLAIN does (optional, if > missing server bases authzid on authcid), services that require this hint > may leverage it. This says that you're prepared to have the routing hint be missing. Good. See above. Nico -- From nico@cryptonector.com Thu Aug 30 13:19:50 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C9421F84C2 for ; Thu, 30 Aug 2012 13:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=-0.917, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 4vvok2AErQPk for ; Thu, 30 Aug 2012 13:19:50 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE9321F8495 for ; Thu, 30 Aug 2012 13:19:50 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id C193C1F0087 for ; Thu, 30 Aug 2012 13:19:49 -0700 (PDT) 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; s=cryptonector.com; bh=WUUzZbvyhv1HW+Ic0fvY /3U53ZQ=; b=rEonympIVNNCAvrkrQd8Zv+uuy9iTumt/xL7cz08O9Oy+v51i8O9 RkNZXgCYLa2eGWkXp1gH33atFfs5qJSziobEBZBwcpUuNKMXv7naz5VoVk9AD+E6 OYIeV4fj49tleAZ9/8piXFs6ZbnjWHEo4MfxZfWcNzBNNDEulfuPOC0= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 9E7301F0089 for ; Thu, 30 Aug 2012 13:19:49 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3586336pbb.31 for ; Thu, 30 Aug 2012 13:19:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.77.7 with SMTP id o7mr11394927paw.37.1346357989195; Thu, 30 Aug 2012 13:19:49 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 30 Aug 2012 13:19:49 -0700 (PDT) In-Reply-To: <1346356580.40426.YahooMailNeo@web31816.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> <1346356580.40426.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 15:19:49 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 20:19:51 -0000 Regarding your frustration, I think it'd be a good idea ot have a conference call. I'd be happy to have such a call with you -perhaps a video call?- and I'd be happy to have a conference call with more people. Right now it seems that having a conference call with at least you and Ryan plus one or more of the SASL and GSS-API usual suspects would be good, but I can do a 1-1 call on short notice this week, right now. Note that part of the frustration here is that the "routing hint" was not described in any detail, thus it was very easy for anyone reviewing the I-D to miss completely. Thus we've been unable to understand each other. Now that the routing hint is becoming clearer we will probably communicate better. On Thu, Aug 30, 2012 at 2:56 PM, William Mills wrote: > OAuth doesn't deal with it. Some applications do. > > Here are the requirements, I DO NOT CARE how this gets solved but I really > want to stop going around and around on this. We went from user field in > the spec, to gs2-header, to gs2-header and user field, now we're back to > gs2-header only. Requirements: > > - user name available to the mechanism outside the credential. I am > presuming this needs to be true even when the gs2-header is stripped. It would never be present in a pure GSS-API context since there's no such concept in GSS_Init_sec_context(). You say you "presume" that this must be present -- how can you know that this is a requirement if you're only presuming it? Meanwhile Ryan has explained why he asked for this and it seems (to my reading of what Ryan said) that it is not really required. Certainly it's not required by OAuth itself since otherwise you'd not be *adding* this key/value in the first place. So is this a requirement? To me it seems that the answer is "no". Moreover, this requirement, if it really is a requirement, basically makes it impossible to use this as a GSS-API mechanism. But I have very strong doubts about this being an actual requirement. > - authZ and authN IDs have to be based on the credential but are not part > of the actual credential validation. In SASL authz-ids are NOT to be used by the mechanism in any way. SASL authz-ids are application-specific, and it's up to the client whether to assert one or not. This means you can't possibly rely on the authz-id to setup a required-to-be-present 'user' key/value. You could use the authz-id when one is given, but what would you do when one is not? > - Mismatch between the user name above and the actual identity from the > credential causes a fail. > > Gimme a solution an I'll write it that way. I am assuming the current text > I sent to the list isn't acceptable. We should hear from Ryan a response to my response to him about this. I suspect the routing hint is either not strictly necessary or else that we'll decide that we don't want it at all, which in either case would make this issue go away. Nico -- From nico@cryptonector.com Thu Aug 30 13:30:35 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882C821F8518 for ; Thu, 30 Aug 2012 13:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=-0.910, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 5LaQWPF6fuPU for ; Thu, 30 Aug 2012 13:30:34 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id D0D9821F8510 for ; Thu, 30 Aug 2012 13:30:28 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 5CA9C3B8062 for ; Thu, 30 Aug 2012 13:30:28 -0700 (PDT) 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; s=cryptonector.com; bh=jJ3L6BT+3Ci8WyA7RAxL jThhohU=; b=sAIE9q1xEx0Hu8+ZDO5zeEbTYiRIip5Uh+F8TFp0qQi1je0KvgDK zJYPi3w85aod/ln1YSZ7W9nINDf5gWa6lqfp72OuvhaoMCVrd4J83KPXQyMCKMgm SJNT/+DkNPkdjzolpLz8C4umhkEFbK21O3SZ2448+ya0O86qVEH/QR0= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 3B7873B805B for ; Thu, 30 Aug 2012 13:30:28 -0700 (PDT) Received: by dadf8 with SMTP id f8so1393120dad.31 for ; Thu, 30 Aug 2012 13:30:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr11482128pbc.149.1346358627731; Thu, 30 Aug 2012 13:30:27 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 30 Aug 2012 13:30:27 -0700 (PDT) In-Reply-To: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 15:30:27 -0500 Message-ID: From: Nico Williams To: Ryan Troll Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 20:30:35 -0000 Also, I think that the semantics of the SASL authz-id really preclude using it as a way of representing impersonation/delegation/delegation-of-authorization in the OAuth sense. I see that it might be tempting to do so, but I don't think it's appropriate. Nico -- From stpeter@stpeter.im Thu Aug 30 13:39:18 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B8E21F859C for ; Thu, 30 Aug 2012 13:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 MTN10TWDh789 for ; Thu, 30 Aug 2012 13:39:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A954421F857D for ; Thu, 30 Aug 2012 13:39:17 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 76C4540067; Thu, 30 Aug 2012 14:39:18 -0600 (MDT) Message-ID: <503FCF73.9030706@stpeter.im> Date: Thu, 30 Aug 2012 14:39:15 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Nico Williams References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 20:39:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/30/12 2:30 PM, Nico Williams wrote: > Also, I think that the semantics of the SASL authz-id really > preclude using it as a way of representing > impersonation/delegation/delegation-of-authorization in the OAuth > sense. I see that it might be tempting to do so, but I don't > think it's appropriate. I tend to agree, and I think it would be good to explain why (somewhere; it doesn't necessarily belong in this I-D). That would help avoid similar confusion in the future. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA/z3MACgkQNL8k5A2w/vx19gCgtG9fBDwd1dGCZcgwjG/1/P8p t3EAnjjP0QN9YGEzWwF9Utn41T4f1YWT =Asni -----END PGP SIGNATURE----- From rtroll@google.com Thu Aug 30 13:44:44 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDD521F852D for ; Thu, 30 Aug 2012 13:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.933 X-Spam-Level: X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 ZBShIz89tY6Z for ; Thu, 30 Aug 2012 13:44:43 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3230021F8525 for ; Thu, 30 Aug 2012 13:44:43 -0700 (PDT) Received: by qan41 with SMTP id 41so528338qan.10 for ; Thu, 30 Aug 2012 13:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=eFHJHwmm7TCSwKByKWqy1D6NLUXhZBgfmIYDzfZNFlM=; b=I8FQFhtT0xgCWTv+CwNn9ihFh8Y9AlIjPJofSCSTYwWZVRfh0fH8fNKwPp4vAEgpsa 8MctZbvhcQGjvqjF2e5eJBDaKpnZeYxuBPW1nvaxevXEAtXxF70jw60CJwsJA8MDWBBS Vbihj0O3+u9WpwNdyLpW7peDRGR8YF70OJ2GY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=eFHJHwmm7TCSwKByKWqy1D6NLUXhZBgfmIYDzfZNFlM=; b=TnJngEGPPWuTcreceKzraq8o74d6AcdwWrae4amlEvQfaCfgmRNSnoe/UBKdRj1GjO TU1oouFSRAdyzMejP5i3iU0qcSrp+EkKmWNLG/BRvwk3NTPeLmF9chSWrpSD1DnrAJmV b70uUBxnX69vpx1HRQ/dPWMprK2g5PqHyqG7Lb8Zn+eMbdDAPQj/wZGCt46xz7Ziy0U0 wwa/ppm+ReLYtdzxNMfQa3TZxWbJvp5uh0J6nONZJU465wDJSfbxoa4jJfSf/26XzY8U DF/UOvsYcJrt4p/QtsaGCZ7t3gOqxNYKrGWUsN8XkURkSbou+NrDWZ1lq3TaBc+6lDmm cXvA== Received: by 10.224.1.72 with SMTP id 8mr13613458qae.76.1346359482682; Thu, 30 Aug 2012 13:44:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.1.72 with SMTP id 8mr13613433qae.76.1346359482498; Thu, 30 Aug 2012 13:44:42 -0700 (PDT) Received: by 10.49.132.202 with HTTP; Thu, 30 Aug 2012 13:44:42 -0700 (PDT) In-Reply-To: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 13:44:42 -0700 Message-ID: From: Ryan Troll To: Nico Williams Content-Type: multipart/alternative; boundary=20cf3074b154b1c07f04c881be9b X-System-Of-Record: true X-Gm-Message-State: ALoCoQlr0ND7wFezq4sQh9gORbfNC6smp5SxIb9MYyYW1zIayNaDqTsaHgrpxVuk1pjHzngKmKI4/rDt9Hvswr9GUrUf/ZjGWsOQ5uZzItI4wwgUCkUDlLmI72hqoOU0KhDzCp6BUeCinZcrDa6HWCb0ZQl6a+LjDVkbWV4enQ/vimkUIsBpw14UN8F41lczxZoOBDmSmjyI Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 20:44:44 -0000 --20cf3074b154b1c07f04c881be9b Content-Type: text/plain; charset=ISO-8859-1 > The proxy makes its back-end determination based on "a hint" sent by the > > client. We believe the proxy should be able to determine the hint > without > > the need to actually verify the OAuth Token -- especially important when > the > > tokens are Opaque, and possibly require additional round trips to unpack. > > OK, but why should the 'user' be the hint for this? Why not something > else? > The quick, service specific answer: because I want to route your IMAP request to the systems that house your IMAP data. As a resource server, I know where "nico@example.com"'s mail is housed, and want to connect you to it, for the quickest, best data access possible. Why not something else? I'm open to suggestions - my guess is that it's really service specific. > Looking at "SASL PLAIN", one of the simplest mechanisms, I believe this is > > how things should work: > > SASL PLAIN is not a GS2 mechanism. > True, but for the purpose of demonstrating my use case, not using a GS2 mechanism was preferred. I opted for using the simplest scenario to explain it, and that got us to some good discussion points about authz-id vs authc-id. But basing the authzid on the authcid is a completely local thing. > You can't have the OAuth SASL mechanism specification depend on it. > I'm sorry, I don't understand. We have existing SASL mechanisms that state just this - PLAIN being an example. Are they incorrect? My first reaction to the routing hint idea is that basing it on the > authz-id is very much the wrogn thing to do. You should use only the > authcid, if that. My second reaction is the same :) but maybe I'm > missing something? > Using authc-id sounds reasonable. I phrased things as authz-id, rather than authc-id, as the first definition I found for the two indicated authz-id was "identity to act as", and I was trying to come up with a use case that demonstrated this need. My example was a bit of a stretch, and using authc-id instead works for me. > It would be beneficial to do the same in the OAuth mechanism. Even if the > > Authzid equivalent field is defined the same way PLAIN does (optional, if > > missing server bases authzid on authcid), services that require this hint > > may leverage it. > > This says that you're prepared to have the routing hint be missing. > Good. See above. > Yes, but that support is likely to be "fail the request, and in the error response return a link to the faq". Our faq / developer documentation would cover what needs to be done, on top of this work, in order to get clients to interoperate with us. I originally brought this idea to the list because we have/will require this "hint", and I'd prefer to see use a well defined, potentially optional field. This has the benefit of working for more than just us -- if another resource server of significant size wanted to do the same thing, they can use the same data, and clients won't need to do something "unique" for each service provider. Authc-id will work, as long as it's available without the need to unpack the OAuth credential. -R --20cf3074b154b1c07f04c881be9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > The proxy makes its back-end determination based on "a hint"= sent by the
<= div class=3D"im"> > client. =A0We believe the proxy should be able to determine the hint w= ithout
> the need to actually verify the OAuth Token -- especially important wh= en the
> tokens are Opaque, and possibly require additional round trips to unpa= ck.

OK, but why should the 'user' be the hint for this? =A0Why no= t something else?

The quick, service sp= ecific answer: because I want to route your IMAP request to the systems tha= t house your IMAP data. =A0As a resource server, I know where "nico@example.com"'s mail is house= d, and want to connect you to it, for the quickest, best data access possib= le.

Why not something else? =A0I'm open to suggestions = - my guess is that it's really service specific.



> Looking at "SASL PLAIN", one of the simple= st mechanisms, I believe this is
> how things should work:

SASL PLAIN is not a GS2 mechanism.

True, but for the purpose of demonstrating my use case, not using a GS2 m= echanism was preferred. =A0I opted for using the simplest scenario to expla= in it, and that got us to some good discussion points about authz-id vs aut= hc-id.

<Cutting out excellent, clear description of when an= d why GS2 is present -- thanks for the clarification!> =A0
=A0=


But basing the authzid on the authcid is a completely loc= al thing.
You can't have the OAuth SASL mechanism specification depend on it.
=

I'm sorry, I don't understand.

We have existing SASL mechanisms that state just this= - PLAIN being an example. =A0Are they incorrect?

=A0

= My first reaction to the routing hint idea is that basing it on the
authz-id is very much the wrogn thing to do. =A0You should use only the
authcid, if that. =A0My second reaction is the same :) =A0but maybe I'm=
missing something?

Using authc-id sound= s reasonable.

I phrased things as authz-id, rather= than authc-id, as the first definition I found for the two indicated authz= -id was "identity to act as", and I was trying to come up with a = use case that demonstrated this need. =A0My example was a bit of a stretch,= and using authc-id instead works for me.

=A0

> It would be beneficial to do the same in the OAuth m= echanism. =A0Even if the
> Authzid equivalent field is defined the same way PLAIN does (optional,= if
> missing server bases authzid on authcid), services that require this h= int
> may leverage it.

This says that you're prepared to have the routing hint be missin= g.
Good. =A0See above.
=A0

Yes, = but that support is likely to be "fail the request, and in the error r= esponse return a link to the faq". =A0Our faq / developer documentatio= n would cover what needs to be done, on top of this work, in order to get c= lients to interoperate with us.

I originally brought this idea to the list because we h= ave/will require this "hint", and I'd prefer to see use a wel= l defined, potentially optional field. =A0This has the benefit of working f= or more than just us -- if another resource server of significant size want= ed to do the same thing, they can use the same data, and clients won't = need to do something "unique" for each service provider.=A0

Authc-id will work, as long as it's available witho= ut the need to unpack the OAuth credential.

-R
--20cf3074b154b1c07f04c881be9b-- From rtroll@google.com Thu Aug 30 13:48:36 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E19221F84AE for ; Thu, 30 Aug 2012 13:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 55AY4d7-eMWB for ; Thu, 30 Aug 2012 13:48:36 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C5DDC21F84A0 for ; Thu, 30 Aug 2012 13:48:35 -0700 (PDT) Received: by qcac10 with SMTP id c10so1836114qca.31 for ; Thu, 30 Aug 2012 13:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=WuDNFyc4NqmLXeFm++1eBZrHp78bP5tW9iywetDGmW0=; b=TcgG0jLQPwi5nn4tFbOkY/K5GgdB+urySC4itvDzHmsw7PztcID2dTX2riGbAbdTqy UAuTo175jnB8JITCiR9/i4D7Jl0ahljMdSSC57yc4iATVjpev7sSCxNT3DaBCrzfARvm /CDsvVNVIaHKwQw0IxTquQMiBKFYdBcMcbsW4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=WuDNFyc4NqmLXeFm++1eBZrHp78bP5tW9iywetDGmW0=; b=SjXmmcjydWkeaGx1bye/ZLxKIwle6ybmVXzq0XDMNFpXXSM/W12gxlj8YT7Jdf1NUZ 8xQXgNwskoc0Tv9qJ3/vysp0runSK8/ASgHOzXf8wpaqBUHxZjai08Ff53dUt7wf1SG9 LaswvcuH5SJ9Ebv63QzBVmniqQsYOP4I6LceLwhwmruHte3Ip9hT60nM6x8pmjHzcu+L mjGStJ3JlR0GQPyETOhUl5oeZeJGONocwbwUaG2p3pXMsSDPwi+wiL/Li/QTOerb74FH Yq1S5CId84yS66AoXN6D1qidrZBnCRNEkABoMbQjX7Xe5I7KcND/kcqTBUJhtV2c0eEy Mqbw== Received: by 10.224.1.72 with SMTP id 8mr13632902qae.76.1346359715260; Thu, 30 Aug 2012 13:48:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.1.72 with SMTP id 8mr13632884qae.76.1346359715121; Thu, 30 Aug 2012 13:48:35 -0700 (PDT) Received: by 10.49.132.202 with HTTP; Thu, 30 Aug 2012 13:48:35 -0700 (PDT) In-Reply-To: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> <1346356580.40426.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 13:48:35 -0700 Message-ID: From: Ryan Troll To: Nico Williams Content-Type: multipart/alternative; boundary=20cf3074b1548f495b04c881ccc4 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlye9EDGCscXxATTzKg2gkRzx6TVsjZgYcLrlJnoRloTJTXXEt3mUklQJ9aeP0AVx0r0HFzZyPMxvWGSAEP79Kxc0JqtdZpQ8ezGvNcuRcfQQVYvNd1OAEYGrCEb2SL8Tz3jjktRoQhmKYZ4rkibhQvEQFfG/YEvCitu/HhFeum78PG8EYn5Hy6xJIIRTdS2oAUmCCs Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 20:48:36 -0000 --20cf3074b1548f495b04c881ccc4 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 30, 2012 at 1:19 PM, Nico Williams wrote: > Regarding your frustration, I think it'd be a good idea ot have a > conference call. I'd be happy to have such a call with you -perhaps a > video call?- and I'd be happy to have a conference call with more > people. Right now it seems that having a conference call with at > least you and Ryan plus one or more of the SASL and GSS-API usual > suspects would be good, but I can do a 1-1 call on short notice this > week, right now. > If this will help, a video call will work. Somebody will need to walk me through what you guys use for your VCs. :) Meanwhile Ryan has explained why he asked for this and it seems (to my reading of what Ryan said) that it is not really required. [Follow-up in the other thread.] -R --20cf3074b1548f495b04c881ccc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Aug 30, 2012 at 1:19 PM, Nico Wi= lliams <nico@cryptonector.com> wrote:
Regarding your frustration, I think it'd be a good idea ot have a
conference call. =A0I'd be happy to have such a call with you -perhaps = a
video call?- and I'd be happy to have a conference call with more
people. =A0Right now it seems that having a conference call with at
least you and Ryan plus one or more of the SASL and GSS-API usual
suspects would be good, but I can do a 1-1 call on short notice this
week, right now.

If this will help, a v= ideo call will work. =A0Somebody will need to walk me through what you guys= use for your VCs. :)


Meanwhile Ryan has explained why he asked for this and it seems (to my
reading of what Ryan said) that it is not really required.

[Follow-up in the other thread.]

= -R
--20cf3074b1548f495b04c881ccc4-- From shawn.emery@oracle.com Thu Aug 30 13:56:39 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4416D21F853C for ; Thu, 30 Aug 2012 13:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 5eh9M34xgrJ8 for ; Thu, 30 Aug 2012 13:56:38 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id A4B5321F8535 for ; Thu, 30 Aug 2012 13:56:38 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7UKuZSm006910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Aug 2012 20:56:36 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7UKuWw3023940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Aug 2012 20:56:33 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7UKuWTC021439; Thu, 30 Aug 2012 15:56:32 -0500 Received: from [10.159.84.110] (/10.159.84.110) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 Aug 2012 13:56:31 -0700 Message-ID: <503FD32A.2020707@oracle.com> Date: Thu, 30 Aug 2012 14:55:06 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.6esrpre) Gecko/20120731 Thunderbird/10.0.6 MIME-Version: 1.0 To: Ryan Troll References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> <1346356580.40426.YahooMailNeo@web31816.mail.mud.yahoo.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090604070900000601020301" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 20:56:39 -0000 This is a multi-part message in MIME format. --------------090604070900000601020301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/30/12 02:48 PM, Ryan Troll wrote: > On Thu, Aug 30, 2012 at 1:19 PM, Nico Williams > wrote: > > Regarding your frustration, I think it'd be a good idea ot have a > conference call. I'd be happy to have such a call with you -perhaps a > video call?- and I'd be happy to have a conference call with more > people. Right now it seems that having a conference call with at > least you and Ryan plus one or more of the SASL and GSS-API usual > suspects would be good, but I can do a 1-1 call on short notice this > week, right now. > > > If this will help, a video call will work. Somebody will need to walk > me through what you guys use for your VCs. :) We've used the IETF's account for audio conferencing through WebEx in the past. For the folks that wish to join this call please respond to me individually so that we can agree upon a time. > Meanwhile Ryan has explained why he asked for this and it seems (to my > > reading of what Ryan said) that it is not really required. > > > [Follow-up in the other thread.] Shawn. -- --------------090604070900000601020301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/30/12 02:48 PM, Ryan Troll wrote:
On Thu, Aug 30, 2012 at 1:19 PM, Nico Williams <nico@cryptonector.com> wrote:
Regarding your frustration, I think it'd be a good idea ot have a
conference call.  I'd be happy to have such a call with you -perhaps a
video call?- and I'd be happy to have a conference call with more
people.  Right now it seems that having a conference call with at
least you and Ryan plus one or more of the SASL and GSS-API usual
suspects would be good, but I can do a 1-1 call on short notice this
week, right now.

If this will help, a video call will work.  Somebody will need to walk me through what you guys use for your VCs. :)

We've used the IETF's account for audio conferencing through WebEx in the past.  For the folks that wish to join this call please respond to me individually so that we can agree upon a time.

Meanwhile Ryan has explained why he asked for this and it seems (to my
reading of what Ryan said) that it is not really required.

[Follow-up in the other thread.]
Shawn.
--
--------------090604070900000601020301-- From nico@cryptonector.com Thu Aug 30 14:15:10 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA75C11E808E for ; Thu, 30 Aug 2012 14:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.88 X-Spam-Level: X-Spam-Status: No, score=-2.88 tagged_above=-999 required=5 tests=[AWL=-0.903, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 5NYeQknyArWt for ; Thu, 30 Aug 2012 14:15:09 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id E779C11E808D for ; Thu, 30 Aug 2012 14:15:09 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id AD23167C06E for ; Thu, 30 Aug 2012 14:15:09 -0700 (PDT) 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; s=cryptonector.com; bh=In+Uh9xPt0ymfT6yfwWE jLGAigs=; b=BvaAWaoxRezewMKis5rQUhcexX9PxaqT5T+ljCCU1DaahzoTCLWe n6hSaz1Fi1htJrju1WGorPO4AyhPv8SeSeuZcdOEfmEjR1dviRJtc7gEM7lNjok8 fs8nAOtiC4XJEtTPCu58hAL+acGOd4XRhi1DCrrRFtwhEjTYgUq6Xuk= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 90A4F67C069 for ; Thu, 30 Aug 2012 14:15:09 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3651887pbb.31 for ; Thu, 30 Aug 2012 14:15:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.129.73 with SMTP id nu9mr13610015pbb.59.1346361309222; Thu, 30 Aug 2012 14:15:09 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 30 Aug 2012 14:15:09 -0700 (PDT) In-Reply-To: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 16:15:09 -0500 Message-ID: From: Nico Williams To: Ryan Troll Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 21:15:10 -0000 On Thu, Aug 30, 2012 at 3:44 PM, Ryan Troll wrote: > The quick, service specific answer: because I want to route your IMAP > request to the systems that house your IMAP data. As a resource server, I > know where "nico@example.com"'s mail is housed, and want to connect you to > it, for the quickest, best data access possible. > > Why not something else? I'm open to suggestions - my guess is that it's > really service specific. Oh, I thought this was a routing that OAuth needed, not the application. This helps a lot. So, the IMAP server should check the authz-id that comes out of SASL (really, the gs2-header, in the case of GS2 mechanisms) or, if there's no authz-id, then the authcid, and use that. You'll almost certainly be using mailbox names or some sort of user ID as the authz-id when it's present, and this is something that you tell your users to do, so you have control over this. If there's no authz-id you may need to do some lookup based on the authcid because there's no requirement that the two types of ID be of the same form (indeed, they'll almost never be of the same form). This was never something you should have asked of the OAuth SASL mechanism :) As an application that uses SASL your application should use the attributes that SASL exposes -- this will make your application able to use other SASL mechanisms. (The whole point of SASL, and GSS-API, is to be pluggable security framework so that SASL (or GSS) apps can be pluggable themselves. A pluggable layer must impose some constraints on their plugins, else the pluggable layer is infeasible. A constraint here is that you must treat the mechanisms' messages as opaque, and that you must deal with the mechanisms in ways that SASL (or GSS) specify. So, for example, your application should not parse mechanism messages to extract authz-ids! Instead you must get that out of a SASL layer. Of course, you could build an application that just has a switch statement and implements some mechanisms all by itself, but your application then won't be pluggable. Note that SASL apps and mechanisms came first, then the SASL specification came latter: it turned out that a certain pattern was followed every time and developers wanted a library instead of big switch statements in their code. Abstraction as a pluggable layer was possible because the pattern was repeated, and abstraction made it easier to re-use code.) I'm eliding the rest -though I may respond to some of it separately- because I think the above is sufficient to get us past this problem. I think it should be clear now that we don't need the 'user' key/value, that the routing function that you want to perform is an application-routing function that should use as inputs only SASL outputs (rather than OAuth mechanism-specific items), and that this routing function must be mindful of SASL semantics (there's always an authcid, but it's mechanism-specific, whereas there may, but need not be, an authz-id that is *application-specific* (and typially application-specific means that a user types in some string as the authz-id into a field of some UI, and the server operator tells the user what string to type in there when the user enrolls, which means that in a way the server operator has control over the form of authz-ids). I want to expand a bit more on the difference between authcid and authz-id. An authcid is always mechanism-specific. For some mechanisms the authcid is free-form (e.g., PLAIN), but for others it has very specific forms (e.g., Kerberos, where the form will be a principal name in the string representation given in RFC1964, usually of the form username@REALM in the case of IMAP clients). Whereas the authz-id is application-specific. An application protocol is free to define the form of authz-ids: for example, LDAP could say that authz-ids *must* be DNs (and IIRC it does say so, but I'm not going to check right now). But some application protocols don't specify the form of the authz-id, in which case the server operator has full control over the form of authz-ids (even in the case of LDAP the server operator controls the DNs that clients are free to assert as authz-ids anyways, the operator just doesn't get to specify forms other than DNs). Nico -- From nico@cryptonector.com Thu Aug 30 14:19:37 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B35021F852B for ; Thu, 30 Aug 2012 14:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 TayQ8CJLemVf for ; Thu, 30 Aug 2012 14:19:36 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0FA21F8526 for ; Thu, 30 Aug 2012 14:19:36 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 4BE0776806D for ; Thu, 30 Aug 2012 14:19:36 -0700 (PDT) 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; s=cryptonector.com; bh=dgyLFlSORNAPPGDgJFj1 tc/vt9I=; b=OIijsHqjrvHY/he+13r0OiRsdYO3C0oY8hpFzkUL7fpbO+MGBUxO xXm4/Lg0nu6dSUGAvBRD5u5IlrFy65kBH74zFOazEH7doUQUEQz48+wnc3B1BLsY nTdPL11H7cpj7ZL8fh5LD4wykomeePnq5DuCCFz50lDG5yLtUbc9dSY= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 30A7776806A for ; Thu, 30 Aug 2012 14:19:36 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3656503pbb.31 for ; Thu, 30 Aug 2012 14:19:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.85.133 with SMTP id h5mr6852896paz.10.1346361575812; Thu, 30 Aug 2012 14:19:35 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 30 Aug 2012 14:19:35 -0700 (PDT) In-Reply-To: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> <1346356580.40426.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 16:19:35 -0500 Message-ID: From: Nico Williams To: Ryan Troll Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 21:19:37 -0000 On Thu, Aug 30, 2012 at 3:48 PM, Ryan Troll wrote: > If this will help, a video call will work. Somebody will need to walk me > through what you guys use for your VCs. :) As Shawn says webex is what we typically use for IETF meetings. For a 1-1 call I'd be happy to use Skype or Google Talk. But any meetings that go beyond 1-1 should generally be announced here and open to all participants (in particular any consensus arrived at on conference calls or physical meetings must be confirmed on the list; also the IETF NOTE WELL rules should be announced in any conference call). I'm offering to do 1-1s with you and with William just to clear up confusion over SASL semantics and GS2. Nico -- From nico@cryptonector.com Thu Aug 30 14:31:40 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FB521F851B for ; Thu, 30 Aug 2012 14:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 UYysAqODQmnM for ; Thu, 30 Aug 2012 14:31:40 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2194521F852D for ; Thu, 30 Aug 2012 14:31:40 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id DEAA11F007C for ; Thu, 30 Aug 2012 14:31:39 -0700 (PDT) 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; s=cryptonector.com; bh=4BQ6sLgr7xsOy1+aOqPR 6+XaC8g=; b=JXu9eOy8++h/gjjL620f/Eh6WSiagL6Y3U01aljnDVcp6rT5/8bz LxThJbgtkVLQkP7edbbxdfdxdaJIf2rf8VYKktG5cZsBE2+lxxbBI9iSvzXLLiF1 DPeRywUZBwtHJEpAU1r9FUX1LY29ZLKFr7JQrJ/bXZeqoiiy78nyCzM= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id B40871F001E for ; Thu, 30 Aug 2012 14:31:39 -0700 (PDT) Received: by dadf8 with SMTP id f8so1421470dad.31 for ; Thu, 30 Aug 2012 14:31:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr11773975pbc.149.1346362299393; Thu, 30 Aug 2012 14:31:39 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 30 Aug 2012 14:31:39 -0700 (PDT) In-Reply-To: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 16:31:39 -0500 Message-ID: From: Nico Williams To: Ryan Troll Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 21:31:40 -0000 On Thu, Aug 30, 2012 at 3:44 PM, Ryan Troll wrote: >> SASL PLAIN is not a GS2 mechanism. > > True, but for the purpose of demonstrating my use case, not using a GS2 > mechanism was preferred. I opted for using the simplest scenario to explain > it, and that got us to some good discussion points about authz-id vs > authc-id. Actually, it's a bad example because it doesn't really constrain authcids, and so you will be tempted to think that authcid and authz-ids share the same namespace, and to be clear, they do not. A better example would be Kerberos, where the authcids are Kerberos principal names written as strings of this form: [/[.../@ with '/' and '@' in any components escaped with a '\'. Typically user principal names have one component. >> But basing the authzid on the authcid is a completely local thing. >> You can't have the OAuth SASL mechanism specification depend on it. > > I'm sorry, I don't understand. See my other replies. > We have existing SASL mechanisms that state just this - PLAIN being an > example. Are they incorrect? Does the specification of PLAIN contradict me? It's possible, but if so it will be an anachronism. >> My first reaction to the routing hint idea is that basing it on the >> authz-id is very much the wrogn thing to do. You should use only the >> authcid, if that. My second reaction is the same :) but maybe I'm >> missing something? > > Using authc-id sounds reasonable. Just remember that the form of authcids varies by mechanism. > I phrased things as authz-id, rather than authc-id, as the first definition > I found for the two indicated authz-id was "identity to act as", and I was > trying to come up with a use case that demonstrated this need. My example > was a bit of a stretch, and using authc-id instead works for me. Yes, this is very confusing about authcid and authz-ids. They have different namespaces but "identity to act as" tends to imply that they have the same namespace. They don't. >> > [...] >> >> This says that you're prepared to have the routing hint be missing. >> Good. See above. > > Yes, but that support is likely to be "fail the request, and in the error > response return a link to the faq". Our faq / developer documentation would > cover what needs to be done, on top of this work, in order to get clients to > interoperate with us. Exactly; now you understand :) You will likely tell your users to specify the authz-id, not in such terms but, rather, you'll tell them what to put in in the typical GUIs (in Evolution, in Thunderbird, in Outlook, etcetera). > I originally brought this idea to the list because we have/will require this > "hint", and I'd prefer to see use a well defined, potentially optional > field. This has the benefit of working for more than just us -- if another > resource server of significant size wanted to do the same thing, they can > use the same data, and clients won't need to do something "unique" for each > service provider. > > Authc-id will work, as long as it's available without the need to unpack the > OAuth credential. And of course it absolutely should be. If you look at Cyrus SASL, for one example, you'll find that the authcid is exposed to the server application. The application also gets the mechanism name, so that it can interpret the authcid if necessary (though typically you'll just use the authcid as a DB lookup key, though you should really be using {, } as a compound lookup key...). Nico -- From rtroll@google.com Thu Aug 30 14:40:34 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0100521F851C for ; Thu, 30 Aug 2012 14:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.943 X-Spam-Level: X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 ZRVzqXIv2Dzg for ; Thu, 30 Aug 2012 14:40:33 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFE721F8513 for ; Thu, 30 Aug 2012 14:40:33 -0700 (PDT) Received: by qcac10 with SMTP id c10so1870184qca.31 for ; Thu, 30 Aug 2012 14:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=h7vrP0sVv1IjvVM65MmZuUitSM5JQklDE6mQb65rnrU=; b=B3S1c68P6P3hw0ITSonP7eZuHk9EHY2kG/2E8A1NWlFxgLlxp+Xo/U3YzTUq8GtuU5 e2I+tXvYBj8ogJ1rvJWEpUCL+7qqr5pjyAoNqF98ESOffjQ02rQa9n0+cdzi6PT21Z+I MOah4appaYIJnJkE1FlG+xRqntwzln6Rud9Z0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=h7vrP0sVv1IjvVM65MmZuUitSM5JQklDE6mQb65rnrU=; b=V2sxDvhR/lnzgDmTzma7XYPzXH30pNB9mxJdM2QYotyb9esNAl3Yuah+sR2an6D9MT x6UcdunJ3+ODeX9wpdBuUcSrSgiYF8b+rR0+Ead0V1ELdFp0N5AKmM2nec8EbmkZI3Pj QNKWHzwPwJvBUMd0Rx9l/z3rXDUau5HEfsNrC+lyC/QD3pfC6YmUr9USBhfiyn1enOR3 v7dqmquDZEQKfFujUsMsfDaHERMgNrqwABefqDM8q+ICtVP8jqF/u/vhftMWIOjoE6B/ XsuFwXNA1b4UtDd5iOa7U8mDJSInDPkZHO0SgpfgVyOcaUFg57JajmnEO4358fbFpZcw e38Q== Received: by 10.224.217.130 with SMTP id hm2mr13877637qab.87.1346362832151; Thu, 30 Aug 2012 14:40:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.217.130 with SMTP id hm2mr13877603qab.87.1346362831882; Thu, 30 Aug 2012 14:40:31 -0700 (PDT) Received: by 10.49.132.202 with HTTP; Thu, 30 Aug 2012 14:40:31 -0700 (PDT) In-Reply-To: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346343215.93231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 14:40:31 -0700 Message-ID: From: Ryan Troll To: Nico Williams Content-Type: multipart/alternative; boundary=20cf300fb23f5549bd04c8828693 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm91Dy85QqhJoZRHcMeUjHoqqaE+LlSDiPlrZfms8BgN4+01Sw/3x7dS+gjKNWPgVFBT1ogEe6ex678xbuE8GbEsntO7N1CfjBiBvaxT05dbKj+yvzM7YiXExsOwtRRE0fZeYictJL8j4N3Cz79bjWcxPEa2McBQmVe1gqBkJHKzvnhpvEMxsyd4bbNQm59kYCUhO5V Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 21:40:34 -0000 --20cf300fb23f5549bd04c8828693 Content-Type: text/plain; charset=ISO-8859-1 > > Authc-id will work, as long as it's available without the need to unpack > the > > OAuth credential. > > And of course it absolutely should be. Perhaps this is the root of the problem - I was unable to see how, in any of the pre-GS2 based OAUTH/SASL specs, I was going to determine the authc-id without mucking with the OAuth2 token. Now that we're all in agreement that GS2 must be present in the SASL request, and that folks such as myself should use the {,} for shard hinting, I could really use an example that shows where the authcid is within the OAUTH/SASL protocol. Your example of Thunderbird is a great one. What do we tell the Mozilla developers - assuming they have a UI that allows a user to enter a name ( nico@example.com) and an oauth token (nicos-refresh-token), and Mozilla supports all of the appropriate OAuth magic, where does Thunderbird put the name (nico@example.com) in the "AUTHENTICATE OAUTH" command? -R --20cf300fb23f5549bd04c8828693 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Authc-id will work, as long as it's available without the need to = unpack the
> OAuth credential.

And of course it absolutely should be. =A0

Perhaps this is the root of the problem - I was unable to see how, in= any of the pre-GS2 based OAUTH/SASL specs, I was going to determine the au= thc-id without mucking with the OAuth2 token.

Now that we're all in agreement that GS2 must be pr= esent in the SASL request, and that folks such as myself should use the {&l= t;mechanism>,<authcid>} for shard hinting, I could really use an e= xample that shows where the authcid is within the OAUTH/SASL protocol.



Your example of Thunderbi= rd is a great one. =A0What do we tell the Mozilla developers - assuming the= y have a UI that allows a user to enter a name (nico@example.com) and an oauth token (nicos-refresh-token), an= d Mozilla supports all of the appropriate OAuth magic, where does Thunderbi= rd put the name (nico@example.com) = in the "AUTHENTICATE OAUTH" command?

-R
--20cf300fb23f5549bd04c8828693-- From lukeh@padl.com Thu Aug 30 16:21:48 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42CB21F850C for ; Thu, 30 Aug 2012 16:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.781 X-Spam-Level: X-Spam-Status: No, score=-2.781 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599] 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 MKV3MhlFYu9v for ; Thu, 30 Aug 2012 16:21:48 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 0467721F8508 for ; Thu, 30 Aug 2012 16:21:47 -0700 (PDT) Received: by us.padl.com with ESMTP id q7UNLXIQ019512; Thu, 30 Aug 2012 19:21:36 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: Date: Fri, 31 Aug 2012 09:21:31 +1000 Content-Transfer-Encoding: 7bit Message-Id: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346343215.93231.Yahoo! MailNeo@web31812.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> To: Nico Williams X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 23:21:48 -0000 On 31/08/2012, at 7:15 AM, Nico Williams wrote: > define the form of authz-ids: for example, LDAP could say that > authz-ids *must* be DNs (and IIRC it does say so, but I'm not going to > check right now). But some application protocols don't specify the RFC 4513 5.2.1.8: authzId = dnAuthzId / uAuthzId ; distinguished-name-based authz id dnAuthzId = "dn:" distinguishedName ; unspecified authorization id, UTF-8 encoded uAuthzId = "u:" userid userid = *UTF8 ; syntax unspecified -- Luke From wmills@yahoo-inc.com Thu Aug 30 18:45:13 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3484F11E80E1 for ; Thu, 30 Aug 2012 18:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.558 X-Spam-Level: X-Spam-Status: No, score=-17.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 oE9EtEalENhc for ; Thu, 30 Aug 2012 18:45:12 -0700 (PDT) Received: from nm9.bullet.mail.bf1.yahoo.com (nm9.bullet.mail.bf1.yahoo.com [98.139.212.168]) by ietfa.amsl.com (Postfix) with SMTP id 9089311E80E0 for ; Thu, 30 Aug 2012 18:45:11 -0700 (PDT) Received: from [98.139.212.151] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 31 Aug 2012 01:45:10 -0000 Received: from [98.139.212.236] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 31 Aug 2012 01:45:10 -0000 Received: from [127.0.0.1] by omp1045.mail.bf1.yahoo.com with NNFMP; 31 Aug 2012 01:45:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 629159.53394.bm@omp1045.mail.bf1.yahoo.com Received: (qmail 49692 invoked by uid 60001); 31 Aug 2012 01:45:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346377509; bh=+vCkWtqSJXTdZpWK26nEu90yF5TFbQI2VXCCqjoqQS8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=oB3qvoMNVgvqn7G/qFz92QfOcbE+TpeJvNfx1N3fzUGKWNVjmw9MXhDIcVmIJGaTKKdS6nee9aGQQHmCkrXjrne3JPo6Fxi7xxO5R9lfMubMQ3oCQtMrCHx01xKvULayhk3S3AsWPYwX5DFQMxCw+YQLSrWC/lapLO9JASn7GXQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pel0ay/xA1KrTPeq1gRSduKdkYn7lgc0Og7ZZeCaxZmXikFjyiIWQ9Tbn/uPqWl1ewEHXV9fkBHFEfh+XpFiAgkqwmFWD6eK9+MPAIPtl/yTu3pehS4VvJWVxJPqtWcbvroW+Iu+t0vQLsE5I6eYNK6N3B/ckUMU5AAazyIsvVY=; X-YMail-OSG: tmIWRe0VM1kOqE4aPaUMWQCcVul05uml.aMEL3LoVggrQw1 VyohZ3rOgcBgqV_RMjoZsIqxGzaJI75QslDiNAVvLEPU1Q6j2.znYvBzKkVb pH1L7q6UOPltrm95cO.KBd2tAXAsxFB_pqqWElTZzOYmtfdavKjyt2rHAFq7 .N63_pBnO3a8FWhfjGX7oDEOB2N2oA_2SI08wjCEUZoRato15rO8VzJoFl.t 9DYDYDN8VlfcYlyZOgOmXlYVt.PW3A4nmc2KJNTfburGUa6L9KLDMoQANQap uT.TuAKSyXLQjfTEVC7bYcxe.QK4K8oFN3zbTlfsGoj9ZrO8.9h_ObVD0ZmN byWWLJBKv8Ci.MdL7hWrANDIp7AcXS3eZGojpTyjDOtuGRJlWWuyZIZM_3q8 Jan7rriXmFcXpqp109WeTAcWT2dHDx87sJSF6z6NKUNNv2uCepYjuyGYWCs. c0JKd6trT Received: from [209.131.62.113] by web31811.mail.mud.yahoo.com via HTTP; Thu, 30 Aug 2012 18:45:09 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> <1346356580.40426.YahooMailNeo@web31816.mail.mud.yahoo.com> Message-ID: <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 18:45:09 -0700 (PDT) From: William Mills To: Nico Williams , Ryan Troll In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-1717583545-1346377509=:19979" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 01:45:13 -0000 --764183289-1717583545-1346377509=:19979 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable A conference call can happen, and I'd be happy to do that, but I don't know= if it's really needed.=A0 The problem statement is pretty clear I think at= this point.=0A=0AWhether or not it is "according to spec" there will be im= plementations that will be making decisions like which storage node to talk= to based on the ID we get from the SASL mechanism.=0A=0AAll that remains i= s to determine how the ID of the user/entity is being conveyed.=0A=0A-bill= =0A=0A=0A=0A=0A=0A>________________________________=0A> From: Nico Williams= =0A>To: Ryan Troll =0A>Cc: Wi= lliam Mills ; "kitten@ietf.org" ; Si= mon Josefsson =0A>Sent: Thursday, August 30, 2012 2:1= 9 PM=0A>Subject: Re: [kitten] requirements/context/frustration Re: Comma vs= . %x01 Re: OAuth SASL draft -05=0A> =0A>On Thu, Aug 30, 2012 at 3:48 PM, Ry= an Troll wrote:=0A>> If this will help, a video call = will work.=A0 Somebody will need to walk me=0A>> through what you guys use = for your VCs. :)=0A>=0A>As Shawn says webex is what we typically use for IE= TF meetings.=A0 For a=0A>1-1 call I'd be happy to use Skype or Google Talk.= =A0 But any meetings=0A>that go beyond 1-1 should generally be announced he= re and open to all=0A>participants (in particular any consensus arrived at = on conference=0A>calls or physical meetings must be confirmed on the list; = also the=0A>IETF NOTE WELL rules should be announced in any conference call= ).=A0 I'm=0A>offering to do 1-1s with you and with William just to clear up= =0A>confusion over SASL semantics and GS2.=0A>=0A>Nico=0A>--=0A>=0A>=0A> --764183289-1717583545-1346377509=:19979 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
A confere= nce call can happen, and I'd be happy to do that, but I don't know if it's = really needed.  The problem statement is pretty clear I think at this = point.

Whether or not it is "according to spec" there will be implem= entations that will be making decisions like which storage node to talk to = based on the ID we get from the SASL mechanism.

All that remains is = to determine how the ID of the user/entity is being conveyed.

-bill<= br>


From: Nico Williams <nico@cryptonector.com>
= To: Ryan Troll <rtroll@goo= glers.com>
Cc: Will= iam Mills <wmills@yahoo-inc.com>; "kitten@ietf.org" <kitten@ietf.o= rg>; Simon Josefsson <simon@josefsson.org>
Sent: Thursday, August 30, 2012 2:19 PM
= Subject: Re: [kitten] requ= irements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05

On Thu, Aug 30, 2012 at 3:48 PM, Ryan Troll <rtr= oll@googlers.com> wrote:
> If this will help, a video call wil= l work.  Somebody will need to walk me
> through what you guys u= se for your VCs. :)

As Shawn says webex is what we typically use for IETF meeti= ngs.  For a
1-1 call I'd be happy to use Skype or Google Talk. = ; But any meetings
that go beyond 1-1 should generally be announced here= and open to all
participants (in particular any consensus arrived at on= conference
calls or physical meetings must be confirmed on the list; al= so the
IETF NOTE WELL rules should be announced in any conference call).=   I'm
offering to do 1-1s with you and with William just to clear u= p
confusion over SASL semantics and GS2.

Nico
--


<= /div>
--764183289-1717583545-1346377509=:19979-- From nico@cryptonector.com Thu Aug 30 21:47:26 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22B621F8440 for ; Thu, 30 Aug 2012 21:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.859 X-Spam-Level: X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 n+XpMryiT0ni for ; Thu, 30 Aug 2012 21:47:26 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 14F3521F843E for ; Thu, 30 Aug 2012 21:47:26 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id A75C11DE059 for ; Thu, 30 Aug 2012 21:47:25 -0700 (PDT) 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; s=cryptonector.com; bh=teudCaIbmif2RDX0rOaQ 1lNjt8Y=; b=cRIRfZ3H6eXKaC2q0wOMVfxNUEaq+nXi2kawTbJn+OYfEuZ+x98d IqsGOoEkNIUiSzVaau85L6IatOwp9cOKu3AzXPipe4cLooQrdwCpD/+IEETlCcq9 eT5QhBzsURHAw75Iwb4t6IKSCeAO/RScMn+6sjre+Edomn0YpDfCExI= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 968831DE00C for ; Thu, 30 Aug 2012 21:47:25 -0700 (PDT) Received: by dadf8 with SMTP id f8so1605529dad.31 for ; Thu, 30 Aug 2012 21:47:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.77.7 with SMTP id o7mr13380806paw.37.1346388445209; Thu, 30 Aug 2012 21:47:25 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 30 Aug 2012 21:47:25 -0700 (PDT) In-Reply-To: <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346344929.36729.YahooMailNeo@web31802.mail.mud.yahoo.com> <1346356580.40426.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 23:47:25 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 04:47:26 -0000 On Thu, Aug 30, 2012 at 8:45 PM, William Mills wrote: > A conference call can happen, and I'd be happy to do that, but I don't know > if it's really needed. The problem statement is pretty clear I think at > this point. > > Whether or not it is "according to spec" there will be implementations that > will be making decisions like which storage node to talk to based on the ID > we get from the SASL mechanism. > > All that remains is to determine how the ID of the user/entity is being > conveyed. If you ask Ryan I think he'll tell you that it's settled: remove the 'user' key/value (and section 3.1.2). Nico -- From wmills@yahoo-inc.com Thu Aug 30 23:00:39 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8511421F852D for ; Thu, 30 Aug 2012 23:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.558 X-Spam-Level: X-Spam-Status: No, score=-17.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 JTQXOnZFSTaf for ; Thu, 30 Aug 2012 23:00:38 -0700 (PDT) Received: from nm16-vm0.bullet.mail.ne1.yahoo.com (nm16-vm0.bullet.mail.ne1.yahoo.com [98.138.91.49]) by ietfa.amsl.com (Postfix) with SMTP id 4428021F852B for ; Thu, 30 Aug 2012 23:00:38 -0700 (PDT) Received: from [98.138.90.51] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 06:00:33 -0000 Received: from [98.138.88.235] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 06:00:33 -0000 Received: from [127.0.0.1] by omp1035.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 06:00:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 62691.68096.bm@omp1035.mail.ne1.yahoo.com Received: (qmail 16289 invoked by uid 60001); 31 Aug 2012 06:00:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346392832; bh=I3kWnMgkbCrMdChstL69SYnbP/zQen0Bl5Q+JNlzL/k=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cy/5AFGAB3GePKvXda0cGzkboG3fU/41lsVZk0RjY6Agxzsq1xu1TeetvLVYtp13RdrIwFz1yoIZnF9NWtg8NZDuKwWy1WhNT1y7Thy89G0bptr2kpa6/UzHEDSHK/NlqHvmenwuf0SChFIqz2xjmodRy/DiJZWgUQuJDjTAufQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=oP9KGkrO/8G6GJW5u+92IS5O2cTKLcbSO/Rlb+cIlxGvJt8eZxkAOpxODvL7KFnjokBKe9f9a1cT6kfr2x6t5y6NJE0c+FlXtThP/N5SRPYKv6rpDGcs95dy8DGcaO9pJ5YoDRTnmdTf1kAPR7VygfVIG+3/HLUaa80DPcabJ3Q=; X-YMail-OSG: uiCPFfkVM1nIzRJ47iUziWd0aTnbVWvfAu7IxkV4hL60VII 16fHW.jR2hRhOnIsEHsx2VuE1_cGqmhLe0S3BiQoksclZnlTkl5Gw7p0TJTW GC9faFm1Le.uYXOOXFhJnF9ILeWdVJ8LpFYIy4Pj2js_6f9E5ldXxlhrCuQQ LhkeAo98uLhr6RjdLfxwKp_omz54yjGXtm.54a7pzkN4pC8ZB9xzMkFhp5rm zuSLVsBfP7Rg2uuipjcMlVT3Nhk7Yhk_zUcAzgeaYCUr05AjycYEwLSLFBAa Si9sEwU5uovXEnwKoRXAJCPgZSmGJK2OI4lCdyIOAUoaRFFvRG42Z5nSMMwv MEREhILzy2r7h45Odyitvm7kTjLgDR13V96TeMi5aRXq1p1nkX8ZgnhvI99W PRbwhKKw0SOYN87.OyuTRlZjz0DZbxAmyWwRWksB11zLrt_3tz0Ewx3SiFUt YX489i.HJ Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Thu, 30 Aug 2012 23:00:32 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346344929.36729.YahooM ailNeo@web31802.mail.mud.yahoo.com> <1346356580.40426.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> Message-ID: <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Thu, 30 Aug 2012 23:00:32 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-564528672-1346392832=:58517" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 06:00:39 -0000 ---1055047407-564528672-1346392832=:58517 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Where does that username come from in a GS2 mechanism? =0A=0A=0A=0A=0A>____= ____________________________=0A> From: Nico Williams =0A>To: William Mills =0A>Cc: Ryan Troll ; "kitten@ietf.org" ; Simon Josefsson =0A>Sent: Thursday, August 30, 2012 9:47 PM=0A>Subject: Re: [k= itten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL d= raft -05=0A> =0A>On Thu, Aug 30, 2012 at 8:45 PM, William Mills wrote:=0A>> A conference call can happen, and I'd be happy to d= o that, but I don't know=0A>> if it's really needed.=A0 The problem stateme= nt is pretty clear I think at=0A>> this point.=0A>>=0A>> Whether or not it = is "according to spec" there will be implementations that=0A>> will be maki= ng decisions like which storage node to talk to based on the ID=0A>> we get= from the SASL mechanism.=0A>>=0A>> All that remains is to determine how th= e ID of the user/entity is being=0A>> conveyed.=0A>=0A>If you ask Ryan I th= ink he'll tell you that it's settled: remove the=0A>'user' key/value (and s= ection 3.1.2).=0A>=0A>Nico=0A>--=0A>=0A>=0A> ---1055047407-564528672-1346392832=:58517 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Where doe= s that username come from in a GS2 mechanism?

From: Nico Williams <nico@cryptonector.com= >
To: William Mills= <wmills@yahoo-inc.com>
Cc:= Ryan Troll <rtroll@googlers.com>; "kitten@ietf.org" <k= itten@ietf.org>; Simon Josefsson <simon@josefsson.org>
Sent: Thursday, August 30, 2012 9:= 47 PM
Subject: Re: [ki= tten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL dr= aft -05

On Thu, Aug 30, 2012 at 8:45 PM, William Mil= ls <wmills@yahoo-inc.com> wrote:
> A conference call c= an happen, and I'd be happy to do that, but I don't know
> if it's re= ally needed.  The problem statement is pretty clear I think at
>= this point.
>
> Whether or not it is "according to spec" there= will be implementations that
> will be making decisions like which s= torage node to talk to based on the ID
> we get from the SASL mechani= sm.
>
> All that remains is to determine how the ID of the user= /entity is being
> conveyed.

If you ask Ryan I think he'll tel= l you that it's settled: remove the
'user' key/value (and section 3.1.2).=

Nico
--


---1055047407-564528672-1346392832=:58517-- From lukeh@padl.com Thu Aug 30 23:10:43 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C10021F8535 for ; Thu, 30 Aug 2012 23:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 LJqDY2NXQj-8 for ; Thu, 30 Aug 2012 23:10:42 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 74D5221F852D for ; Thu, 30 Aug 2012 23:10:42 -0700 (PDT) Received: by us.padl.com with ESMTP id q7V6AZun001058; Fri, 31 Aug 2012 02:10:37 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_34A3CF3F-10F8-46F4-BE06-608E819A3923" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 16:10:31 +1000 Message-Id: <4120B6E9-C6E3-412F-B45D-E804179E6B7C@padl.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346344929.36729.Yahoo! M ailNeo@web31802.mail.mud.yahoo.com> <1346356580.40426.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 06:10:43 -0000 --Apple-Mail=_34A3CF3F-10F8-46F4-BE06-608E819A3923 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 It can be sent in the authorisation ID field of the GS2 header. On 31/08/2012, at 4:00 PM, William Mills wrote: > Where does that username come from in a GS2 mechanism?=20 >=20 > From: Nico Williams > To: William Mills =20 > Cc: Ryan Troll ; "kitten@ietf.org" = ; Simon Josefsson =20 > Sent: Thursday, August 30, 2012 9:47 PM > Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. = %x01 Re: OAuth SASL draft -05 >=20 > On Thu, Aug 30, 2012 at 8:45 PM, William Mills = wrote: > > A conference call can happen, and I'd be happy to do that, but I = don't know > > if it's really needed. The problem statement is pretty clear I = think at > > this point. > > > > Whether or not it is "according to spec" there will be = implementations that > > will be making decisions like which storage node to talk to based on = the ID > > we get from the SASL mechanism. > > > > All that remains is to determine how the ID of the user/entity is = being > > conveyed. >=20 > If you ask Ryan I think he'll tell you that it's settled: remove the > 'user' key/value (and section 3.1.2). >=20 > Nico > -- >=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com --Apple-Mail=_34A3CF3F-10F8-46F4-BE06-608E819A3923 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 It = can be sent in the authorisation ID field of the GS2 = header.

On 31/08/2012, at 4:00 PM, William Mills = <wmills@yahoo-inc.com> = wrote:

Where does that username come from in a GS2 = mechanism?

From: Nico Williams <nico@cryptonector.com>
= To: William Mills = <wmills@yahoo-inc.com> =
Cc: Ryan Troll = <rtroll@googlers.com>; = "kitten@ietf.org" <kitten@ietf.org>; Simon Josefsson = <simon@josefsson.org> =
Sent: Thursday, = August 30, 2012 9:47 PM
Subject: Re: [kitten] requirements/context/frustration = Re: Comma vs. %x01 Re: OAuth SASL draft -05

On = Thu, Aug 30, 2012 at 8:45 PM, William Mills <wmills@yahoo-inc.com> = wrote:
> A conference call can happen, and I'd be happy to do = that, but I don't know
> if it's really needed.  The problem = statement is pretty clear I think at
> this point.
>
> = Whether or not it is "according to spec" there will be implementations = that
> will be making decisions like which storage node to talk to = based on the ID
> we get from the SASL mechanism.
>
> = All that remains is to determine how the ID of the user/entity is = being
> conveyed.

If you ask Ryan I think he'll tell you that it's settled: remove the
'user' key/value (and section = 3.1.2).

Nico
--


=
_______________________________________________
Kitten = mailing list
Kitten@ietf.org
https://www.ietf.or= g/mailman/listinfo/kitten


= --Apple-Mail=_34A3CF3F-10F8-46F4-BE06-608E819A3923-- From nico@cryptonector.com Thu Aug 30 23:21:34 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B3221F854E for ; Thu, 30 Aug 2012 23:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.853 X-Spam-Level: X-Spam-Status: No, score=-2.853 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 LqdVBNgVxqs7 for ; Thu, 30 Aug 2012 23:21:34 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0081221F8530 for ; Thu, 30 Aug 2012 23:21:33 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 97FB935005B for ; Thu, 30 Aug 2012 23:21:33 -0700 (PDT) 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; s=cryptonector.com; bh=/rTfQML7cCtf+mf+YzVz EGO6HfE=; b=KecHsPddl4/5Bdhcp4TO7Ggu1cVuiKYNTq2g3XIPhpOOzjCvN8kO iXkV61GEDwONUWWukjJ3InuMDnZGtPj5sDdNXxh/JKlgHmxiOzPldD6Le2f+dJ8E CLjVcv9wGgVNBa8FpV0MXS6phDcu2JXOo4VwlIBmvuAqg8+Y+03Rt7I= Received: from mail-vc0-f172.google.com (mail-vc0-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-a66.g.dreamhost.com (Postfix) with ESMTPSA id 72FB0350057 for ; Thu, 30 Aug 2012 23:21:33 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so3307170vcb.31 for ; Thu, 30 Aug 2012 23:21:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.35.141 with SMTP id h13mr5514445vej.11.1346394092697; Thu, 30 Aug 2012 23:21:32 -0700 (PDT) Received: by 10.220.228.8 with HTTP; Thu, 30 Aug 2012 23:21:32 -0700 (PDT) In-Reply-To: <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346356580.40426.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 01:21:32 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 06:21:34 -0000 On Fri, Aug 31, 2012 at 1:00 AM, William Mills wrote: > Where does that username come from in a GS2 mechanism? We should speak of authcid and authz-id. The authcid comes from the SASL mechanism. The authz-id is provided by the client application and transported by the SASL mechanism. SASL/GS2 mechanisms transport the authz-id in the gs2-header. (GSS-API mechanisms have no concept of authz-id. GSS-API applications that want an authz-id, like SSHv2, have to find some other way to transport it. SASL/GS2 *is* a GSS-API application of sorts, and it uses the gs2-header (integrity protected by being prefixed to the CB data) to transport the authz-id.) Nico -- From wmills@yahoo-inc.com Fri Aug 31 07:35:20 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C1D21F85A7 for ; Fri, 31 Aug 2012 07:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.558 X-Spam-Level: X-Spam-Status: No, score=-17.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 oU-Z6JcgI6af for ; Fri, 31 Aug 2012 07:35:19 -0700 (PDT) Received: from nm40-vm5.bullet.mail.bf1.yahoo.com (nm40-vm5.bullet.mail.bf1.yahoo.com [72.30.239.213]) by ietfa.amsl.com (Postfix) with SMTP id 50FFE21F861F for ; Fri, 31 Aug 2012 07:35:17 -0700 (PDT) Received: from [98.139.215.142] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 31 Aug 2012 14:35:16 -0000 Received: from [98.139.212.213] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 31 Aug 2012 14:35:16 -0000 Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP; 31 Aug 2012 14:35:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 833722.7863.bm@omp1022.mail.bf1.yahoo.com Received: (qmail 94679 invoked by uid 60001); 31 Aug 2012 14:35:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346423716; bh=7C48TybAZ5kcM/KJUzESQMrJ0e4s9u199hbixAWs3Nw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OfZw997CxuPCayGyjDU6Y6q4+Li5IH+SH7JAOl+FtErk80u/O2slZ8UqZXDuYM1IhTYJl+LqVpogZ/DfuI4nyAjXF1kDekHKm31NOH7PtZM/YjP1bdYmS/ROw5+MMDqL/3RIgwNnwEmOOG91GYZ1DL/kiIcv0OpBcFmeX4hdDqc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PoLzDluph+YgFbOyfMGI6MJF55PCIAylUherNLygF7SyWCYWfoWS2ftZBMgh7uHNOpvnAPo0gUcngLYea5FTblySJ5HPg6QvUUK+sAvN6GY6UhOKZLJ2mm6ZC8A02wUQL5SwNHBivy8shts2kemPg21B0zYMpIwXRbkauwDEHHk=; X-YMail-OSG: vPAsaB0VM1n4kVh8QwXrAtnWhH2Dpq18Y7ziP5KULtl4A84 69m0QGNpQ.FVTDB6V3_.jJ96dKBeUoaPCNbFeasPls2hexTNrWqMERNhLq1T iSUIky34ne9stEgp8FH70d8ijuet6nAAZTwaRdrgqQuH8g8cCIgpuNELLtUM BA3VWJz.tgYIP8oeBZO61mVVZfOxxuOy.3Kh_aVQTsTkt5h3cRHwrS2F9zMU j7veNbm03HQYjvzJpM2RmykPmM1qAmwmtwh1325NibC3ntY8nLP6EnBKqI5l fQyAvpIaJIAUVHCZM..DdjFKoCNdEWmcmAXVzFxTDn3yOc0Gjqi.u8Zum5zR P5AHD3Q755B7gBbM2eGNINSBA2aUyPNNAulbcF_eKAPSjc04IMqQe9_40D2q N7Ict2.ElIxTFGwScxJ8EnivAlZvgARDihEtMP1C_0qiAsR0Nvz7koYpFsid Duc85zqKwvSkFg4IAuA-- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Fri, 31 Aug 2012 07:35:16 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346356580.40426.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 07:35:16 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-906494992-1346423716=:90231" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 14:35:20 -0000 --1458549034-906494992-1346423716=:90231 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So even though the gs2-header is stripped off before being passed into the = mechanism that information is available to the mechanism?=0A=0A=0A=0A=0A=0A= >________________________________=0A> From: Nico Williams =0A>To: William Mills =0A>Cc: Ryan Troll ; "kitten@ietf.org" ; Simon Josefsson =0A>Sent: Thursday, August 30, 2012 11:21 PM=0A>Subject: = Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth = SASL draft -05=0A> =0A>On Fri, Aug 31, 2012 at 1:00 AM, William Mills wrote:=0A>> Where does that username come from in a GS2 m= echanism?=0A>=0A>We should speak of authcid and authz-id.=A0 The authcid co= mes from the=0A>SASL mechanism.=A0 The authz-id is provided by the client a= pplication=0A>and transported by the SASL mechanism. SASL/GS2 mechanisms tr= ansport=0A>the authz-id in the gs2-header.=0A>=0A>(GSS-API mechanisms have = no concept of authz-id.=A0 GSS-API applications=0A>that want an authz-id, l= ike SSHv2, have to find some other way to=0A>transport it.=A0 SASL/GS2 *is*= a GSS-API application of sorts, and it=0A>uses the gs2-header (integrity p= rotected by being prefixed to the CB=0A>data) to transport the authz-id.)= =0A>=0A>Nico=0A>--=0A>=0A>=0A> --1458549034-906494992-1346423716=:90231 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
So even t= hough the gs2-header is stripped off before being passed into the mechanism= that information is available to the mechanism?

<= /div>

From: Nico Will= iams <nico@cryptonector.com>
Cc: Ryan Troll <rtroll@googlers.co= m>; "kitten@ietf.org" <kitten@ietf.org>; Simon Josefsson <simon@josef= sson.org>
Sent: Th= ursday, August 30, 2012 11:21 PM
= Subject: Re: [kitten] requirements/context/frustration Re: Comma= vs. %x01 Re: OAuth SASL draft -05

On Fri, Aug 31, 2= 012 at 1:00 AM, William Mills <wmills@yahoo-inc.com> wrote:<= br>> Where does that username come from in a GS2 mechanism?

We sh= ould speak of authcid and authz-id.  The authcid comes from the
SAS= L mechanism.  The authz-id is provided by the client application
an= d transported by the SASL mechanism. SASL/GS2 mechanisms transport
the a= uthz-id in the gs2-header.

(GSS-API mechanisms have no concept of au= thz-id.  GSS-API applications
that want an authz-id, like SSHv2, have to find some other way to
transport it.  SASL/GS2 *is* a GSS-= API application of sorts, and it
uses the gs2-header (integrity protecte= d by being prefixed to the CB
data) to transport the authz-id.)

N= ico
--


--1458549034-906494992-1346423716=:90231-- From nico@cryptonector.com Fri Aug 31 07:51:37 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B22721F8621 for ; Fri, 31 Aug 2012 07:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[AWL=-0.870, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 PVwBFY7UTAZF for ; Fri, 31 Aug 2012 07:51:36 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 8AADA21F861A for ; Fri, 31 Aug 2012 07:51:36 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 31C1D2C806E for ; Fri, 31 Aug 2012 07:51:36 -0700 (PDT) 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; s=cryptonector.com; bh=V+YOCxEcJ9ibIzUhbRbM ZjZvqMg=; b=IlLoLUO4t4qLXsKhloigX562AdgdfgfZzaTbUBOcE1+axF4TLPMi nzijAieapCCdmZxzD9z0twz3liNxyXxCqL1KgMs0GFTi73JysDEnaTLfdjLuxWpv WWix1LI65K2nICsQXMLD9SHrx57oGUpivmMTk8hgPbnOno7rENk7/38= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 21A262C806C for ; Fri, 31 Aug 2012 07:51:36 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4767622pbb.31 for ; Fri, 31 Aug 2012 07:51:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.85.133 with SMTP id h5mr10872216paz.10.1346424695598; Fri, 31 Aug 2012 07:51:35 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 31 Aug 2012 07:51:35 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 31 Aug 2012 07:51:35 -0700 (PDT) In-Reply-To: <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346356580.40426.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 09:51:35 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: multipart/alternative; boundary=f46d042ef4a3b2adc604c890eddd Cc: kitten@ietf.org, Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 14:51:37 -0000 --f46d042ef4a3b2adc604c890eddd Content-Type: text/plain; charset=UTF-8 On Aug 31, 2012 10:35 AM, "William Mills" wrote: > > So even though the gs2-header is stripped off before being passed into the mechanism that information is available to the mechanism? Not to OAuth the GSS mechanism, no, but that's ok. It's the OAuth SASL mech that must output the authz-id, and that's before the gs2-header gets stripped, so all's good. Nico -- --f46d042ef4a3b2adc604c890eddd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 31, 2012 10:35 AM, "William Mills" <wmills@yahoo-inc.com> wrote:
>
> So even though the gs2-header is stripped off before being passed into= the mechanism that information is available to the mechanism?

Not to OAuth the GSS mechanism, no, but that's ok.=C2=A0 It's th= e OAuth SASL mech that must output the authz-id, and that's before the = gs2-header gets stripped, so all's good.

Nico
--

--f46d042ef4a3b2adc604c890eddd-- From wmills@yahoo-inc.com Fri Aug 31 08:08:33 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B5121F85C0 for ; Fri, 31 Aug 2012 08:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.559 X-Spam-Level: X-Spam-Status: No, score=-17.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 1XR72P-A2256 for ; Fri, 31 Aug 2012 08:08:32 -0700 (PDT) Received: from nm14-vm1.bullet.mail.ne1.yahoo.com (nm14-vm1.bullet.mail.ne1.yahoo.com [98.138.91.38]) by ietfa.amsl.com (Postfix) with SMTP id F40B521F8530 for ; Fri, 31 Aug 2012 08:08:31 -0700 (PDT) Received: from [98.138.90.57] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 15:08:25 -0000 Received: from [98.138.89.244] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 15:08:25 -0000 Received: from [127.0.0.1] by omp1058.mail.ne1.yahoo.com with NNFMP; 31 Aug 2012 15:08:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 828454.40645.bm@omp1058.mail.ne1.yahoo.com Received: (qmail 77749 invoked by uid 60001); 31 Aug 2012 15:08:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346425705; bh=z7BkZCaAP5VeuO5AXEhR3NpgBbj5XhNS/Vo2giZ84v8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GvIrIC2Y8RospNqFoktBAD4/NP+E2pI1/7Nx/PI6PUyzkkXosB66/8mDH8rdEHszBNWhHAQsT6CnALOggRXLeh8S1GGnIdr7HnEkuIvWn9nN1rrRBWWqhMDfzt1pW8Eg3fgGAONjmXc4nGPTqeKa2SCn7HTKW9TWoXkxaszzaT0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZRV3Ou2vaHdsQVHrIvasLG5mbmrmsg/fwKIz/YYaZaMq65MqkrcqVGP3ifz3GUFqS8UoeqOHgNfTPBv43OwJdEiNz/Whr/VN0U4dE+RNExTofRXugVoAXsga6fC4CLGvkzqI67tki6pw+tR8xQYIUO05hLmAACVmYwZXYRIh0CI=; X-YMail-OSG: TbGFpf0VM1l9bW1zHgANyFoi6FefxAyPmVJLU.p97USkhnp 9pmX8KEe6o8hNtf8lt1TiNGU7ozbnWNWRjtJ_iR8HAI.T6Tdjyo5vWhgNVqe PkzSmOi8jpwNMzIiqCRK2rS0eO0fCE9yfG9DqhoAETadxZulHn5Dg3wvrq5f Ag0518GmYJUUL1OCB7E4pr0ZcHhgwDRl8HpCzWL0gKBaSIvkCNBBcGe.By7a xgAh7DBzGO8VupwRGVvz30dlg_yvw66GbQW_1Bl.xOd.FQkjMmGujZmqo6Oo dpX977Rc15kNmbrgMKPQe3egT21FlnZyzrhdaFs72v75PzHnMuC66tPWqG_n qpTIE5i6nsvElIW_DSmzUJwStNhbH2im7BX5raspOTiKt.4_.mjOjHzW7nss nyU5hJo9.cag_SGLpdmS7PDuv0yS3qqLFqizaZuOjdvk3LguFimUtBExpS1F v3Rg5xjUP Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Fri, 31 Aug 2012 08:08:25 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346356580.40426.YahooM ailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> Message-ID: <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 08:08:25 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-1557782633-1346425705=:73062" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 15:08:33 -0000 ---125733401-1557782633-1346425705=:73062 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable But then we lack the cleartext value in the GSS mechanism?=0A=0A=0A=0A=0A= =0A>________________________________=0A> From: Nico Williams =0A>To: William Mills =0A>Cc: kitten@ietf.o= rg; Ryan Troll ; Simon Josefsson = =0A>Sent: Friday, August 31, 2012 7:51 AM=0A>Subject: Re: [kitten] require= ments/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05=0A> = =0A>=0A>=0A>On Aug 31, 2012 10:35 AM, "William Mills" wrote:=0A>>=0A>> So even though the gs2-header is stripped off before bei= ng passed into the mechanism that information is available to the mechanism= ?=0A>Not to OAuth the GSS mechanism, no, but that's ok.=A0 It's the OAuth S= ASL mech that must output the authz-id, and that's before the gs2-header ge= ts stripped, so all's good.=0A>Nico=0A>-- =0A>=0A> ---125733401-1557782633-1346425705=:73062 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
But then = we lack the cleartext value in the GSS mechanism?

=

From: Nico Wil= liams <nico@cryptonector.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: kitten@ietf.org; Ryan Troll <= rtroll@googlers.com>; Simon Josefsson <simon@josefsson.org>
<= b>Sent: Friday, August 31, 2012 7:51= AM
Subject: Re: [kitt= en] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draf= t -05


=0AOn Aug 3= 1, 2012 10:35 AM, "William Mills" <wmills@yahoo-inc.com> wrote:
=0A>
=0A> So even though= the gs2-header is stripped off before being passed into the mechanism that= information is available to the mechanism?
=0A
Not to OAuth the G= SS mechanism, no, but that's ok.  It's the OAuth SASL mech that must o= utput the authz-id, and that's before the gs2-header gets stripped, so all'= s good.
=0A
Nico
=0A--
=0A


---125733401-1557782633-1346425705=:73062-- From nico@cryptonector.com Fri Aug 31 08:25:34 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DBA21F8487 for ; Fri, 31 Aug 2012 08:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.84 X-Spam-Level: X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Eozj7afpU+AK for ; Fri, 31 Aug 2012 08:25:33 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id D613621F851B for ; Fri, 31 Aug 2012 08:25:32 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 8E6FFB805B for ; Fri, 31 Aug 2012 08:25:32 -0700 (PDT) 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; s=cryptonector.com; bh=yiCQLMPXzalvNPf0ihOy kgdXw7o=; b=crpb2L53jCGuAy9KPd4hJiRKKhhtkcwaU9Oq6iPpiZoR6mdJ6zP8 ALJpfxpPdkcqmmMpSl3ZUx++YHfxp/XMRV0wEGlMPJfA+P7oC2pLFkUK2ncdDWI2 APOfPMO54hMWwd4CotEeC3m/KCyKJlW/XR4I/Xvs7Pe4Vy97onfDF94= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 74487B8057 for ; Fri, 31 Aug 2012 08:25:32 -0700 (PDT) Received: by dadf8 with SMTP id f8so1936363dad.31 for ; Fri, 31 Aug 2012 08:25:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr16144910pbc.149.1346426732096; Fri, 31 Aug 2012 08:25:32 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 31 Aug 2012 08:25:32 -0700 (PDT) In-Reply-To: <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 10:25:32 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 15:25:34 -0000 On Fri, Aug 31, 2012 at 10:08 AM, William Mills wrote: > But then we lack the cleartext value in the GSS mechanism? The GSS mechanism doesn't deal in authz-ids -- authz-ids are foreign to the GSS-API. Nico -- From wmills@yahoo-inc.com Fri Aug 31 08:45:55 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383D221F8669 for ; Fri, 31 Aug 2012 08:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.559 X-Spam-Level: X-Spam-Status: No, score=-17.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 QiwnL4xlVocH for ; Fri, 31 Aug 2012 08:45:54 -0700 (PDT) Received: from nm3.bullet.mail.ac4.yahoo.com (nm3.bullet.mail.ac4.yahoo.com [98.139.52.200]) by ietfa.amsl.com (Postfix) with SMTP id 4DB0821F8668 for ; Fri, 31 Aug 2012 08:45:54 -0700 (PDT) Received: from [98.139.52.194] by nm3.bullet.mail.ac4.yahoo.com with NNFMP; 31 Aug 2012 15:45:42 -0000 Received: from [98.139.52.143] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 31 Aug 2012 15:45:42 -0000 Received: from [127.0.0.1] by omp1026.mail.ac4.yahoo.com with NNFMP; 31 Aug 2012 15:45:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 166892.84212.bm@omp1026.mail.ac4.yahoo.com Received: (qmail 67080 invoked by uid 60001); 31 Aug 2012 15:45:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346427941; bh=7CXvRNxURLdSNcLgNNTWE/QKbx7hh52y1FZ+vhZWuZ4=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kGGLJfrmyndQONfhgSdXTSq+uJyCSGXtjMRLo0y7xM0TAT4D5EE1fnaaXUFYV9hgKI3gR2aPUWThtVIAeC012w0vufKyXiPHwKldAC6Y9CtXY060f8TjAmowawd+V3xlAZfut4cvniIjfiROM85rrBLwl9GRaRP4ADSnd1u4+jY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=USbzOo2wi/9WNH9rAJl9SimgE4tWF0/4BbzDomDcChI76hqAJscIKw2pCSrauCesbwM4Rm3O5/I4jeorMFqDdhOyrzIG5XA1lWHyZRDXTpegF8CTRD9exi6BjIIby3AnbtGcHt5LluqPcKC+1oIONbJlwWVn0E/ivE/UUdedRis=; X-YMail-OSG: wBDvsBMVM1mE7JcpeKWSzpobQogoh4lTnK7CqBg8aCvJkGo jbtNn3ImW0hvLtNkakUbaYq5rdG89P_CljAGH4LEn9J8jz0YIzTDeX5hNe0o J0RH79MOjVXQgHBQ5Eq68HYBe6Ls_O8Y.zhPpJAADQ0iO8IP8ynyid35fYEO aaE8RmXsFwL7u0Fz3G0e85fEcYkFEWG8XO0adb7lB4zU_aCBk3nsBW6uQelv 6HdRcdsI_WurBT1lNhtkE2H2MPG5RnoBFeZzYEJNbg0nmzixZEdtFWfUqzSj Z0OD0Popz5bUVfuGlbtKdiNgTPA5XCwunMDcCnmJ3XTiNE87GWea714utSdo SKvQNdk0hROKtZwBuZJ7GiuLLF4Hjqk5RTimAfX02I5URxBqAPwMa1AOanfs uQoFST2m0AT5fjNcIjZEGVRmNKx1HeuFWTrxNdvByo0LI.9O0KwUVi4rYo3b 0kzZDbu4- Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Fri, 31 Aug 2012 08:45:40 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> Message-ID: <1346427940.66948.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 08:45:40 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-2109223120-1346427940=:66948" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 15:45:55 -0000 ---1055047407-2109223120-1346427940=:66948 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable We want an ID in clear text (not contained in the token) to be present for = use by the mechanism, how do we solve this?=A0 Gs2-header clearly isn't it.= =0A=0A=0A=0A=0A=0A>________________________________=0A> From: Nico Williams= =0A>To: William Mills =0A>Cc= : "kitten@ietf.org" ; Ryan Troll ; Si= mon Josefsson =0A>Sent: Friday, August 31, 2012 8:25 = AM=0A>Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. = %x01 Re: OAuth SASL draft -05=0A> =0A>On Fri, Aug 31, 2012 at 10:08 AM, Wil= liam Mills wrote:=0A>> But then we lack the cleartex= t value in the GSS mechanism?=0A>=0A>The GSS mechanism doesn't deal in auth= z-ids -- authz-ids are foreign=0A>to the GSS-API.=0A>=0A>Nico=0A>--=0A>=0A>= =0A> ---1055047407-2109223120-1346427940=:66948 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
We want a= n ID in clear text (not contained in the token) to be present for use by th= e mechanism, how do we solve this?  Gs2-header clearly isn't it.


From:= Nico Williams <nico@cryptonector.com>
To: William Mills <wmills@yahoo-inc.c= om>
Cc: "kitten@iet= f.org" <kitten@ietf.org>; Ryan Troll <rtroll@googlers.com>; Simon Jos= efsson <simon@josefsson.org>
Sent: Friday, August 31, 2012 8:25 AM
Subject: Re: [kitten] requirements/context/fr= ustration Re: Comma vs. %x01 Re: OAuth SASL draft -05
On Fri, Aug 31, 2012 at 10:08 AM, William Mills <wmills@yahoo-inc= .com> wrote:
> But then we lack the cleartext value in the GSS= mechanism?

The GSS mechanism doesn't deal in authz-ids -- authz-ids= are foreign
to the GSS-API.

Nico
--


=
---1055047407-2109223120-1346427940=:66948-- From nico@cryptonector.com Fri Aug 31 08:53:59 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA5B21F85C7 for ; Fri, 31 Aug 2012 08:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 lqZDhRK0u1ud for ; Fri, 31 Aug 2012 08:53:58 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id D82E021F85A8 for ; Fri, 31 Aug 2012 08:53:57 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 9042F77805B for ; Fri, 31 Aug 2012 08:53:57 -0700 (PDT) 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; s=cryptonector.com; bh=qNNPxDhGwpR4cWIEBaDI pRo+Y/k=; b=xkLkd1zsyNkKyAvF82kM6XuyfV9cax7YkvXsNiw2wCkYBgQuEQUp k80QzSjZGWhLX1/iClIFehhJ0BGOj6HWPwXq4lVwMvN2KiDIadXphgfATFPqQe5h u+VtvDVVRzbj150Dbx+z30JK0GJ8b91Yqf1qAEeFHEOO7ufwYYzWlck= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 7F198778057 for ; Fri, 31 Aug 2012 08:53:57 -0700 (PDT) Received: by dadf8 with SMTP id f8so1951260dad.31 for ; Fri, 31 Aug 2012 08:53:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.34 with SMTP id ib2mr17842577pbc.164.1346428437189; Fri, 31 Aug 2012 08:53:57 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 31 Aug 2012 08:53:57 -0700 (PDT) In-Reply-To: <1346427940.66948.YahooMailNeo@web31806.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346427940.66948.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 10:53:57 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 15:54:00 -0000 On Fri, Aug 31, 2012 at 10:45 AM, William Mills wrote: > We want an ID in clear text (not contained in the token) to be present for > use by the mechanism, how do we solve this? Gs2-header clearly isn't it. Now I'm the one who's frustrated. I suspect you're not reading what I wrote, probably because you've reached the frustration level where you'd stop reading what we have to say. You only need an authz-id in a SASL context. You do not need an authz-id in a GSS context. gs2-header present -> SASL context. gs2-header absent -> GSS context. Ryan needs an authz-id, absolutely needs it. He only needs it in SASL contexts. Nico -- From wmills@yahoo-inc.com Fri Aug 31 09:01:47 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4827D21F8688 for ; Fri, 31 Aug 2012 09:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.56 X-Spam-Level: X-Spam-Status: No, score=-17.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 W8E138gNz0a8 for ; Fri, 31 Aug 2012 09:01:46 -0700 (PDT) Received: from nm5-vm0.bullet.mail.ac4.yahoo.com (nm5-vm0.bullet.mail.ac4.yahoo.com [98.139.52.68]) by ietfa.amsl.com (Postfix) with SMTP id 3DD1721F866E for ; Fri, 31 Aug 2012 09:01:46 -0700 (PDT) Received: from [98.139.52.195] by nm5.bullet.mail.ac4.yahoo.com with NNFMP; 31 Aug 2012 16:01:42 -0000 Received: from [98.139.52.171] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 31 Aug 2012 16:01:42 -0000 Received: from [127.0.0.1] by omp1054.mail.ac4.yahoo.com with NNFMP; 31 Aug 2012 16:01:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 356049.48029.bm@omp1054.mail.ac4.yahoo.com Received: (qmail 46751 invoked by uid 60001); 31 Aug 2012 16:01:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346428901; bh=00r5OaMMIuIg5H/uauMWliS//6M/SEb3M756EoaXzuE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pyBEDSSks8T90nYpaBW58F3BeAJEHoqeNgZaJJS26ev7DgcJOhYiXhx80Zz9huZm5Cwyk2maNjQm4kVThFkSyJRwJMII4VK2GdFoF9T/sq4RK/DCn9IrdRxr0OKpAQuofWYxVlDIxdYjVTm+2Kw2ARbeBM0G80Kk2vZjvh4L4BU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=i1YjPynSd11nm9Me8sPRlWq3fQYJ6KjFBRQjasgcFfUWsT6MMA03ug/oPwjkdHafuUPxDgc/ti7+phd0Q10BzL8KEdARyXa3cdbkErCYLlezBjlq/oCULTUK45ZE8+/rpv8NeqIbpXFN4nrt/qyI7B9oDTW0rHWtQe8DkshYqyg=; X-YMail-OSG: jmbv6jcVM1mE03oYSN4bEZScyimN0tORl8iOhClmumHmDy0 P1LxEpYmT_FjvfjrMijkXEh_L2Ikn7c5.pP455D.LM9cCz1WG159YmClPV8O nGcTFMKRMo0TkGYgNot6fbV792CKw1ocDMBu9QDQCkY_BfrWcmb9ZI7uiVcG utV6uRGOs8y.s8tfokMivlEhCg7cMM4KuDDWFMbUcuUgyKni4ybuItlpQED6 9zC6vzDOMturL0z3Hil9Tr7cE3ewYfyws8faC7caYNkIEfuRtBVuTIbKMFeg Na..0dwDQTyN3xz684dO41_GDdgLrwSVLqTXqFpF1wH9EOpWR48dUSg7E5Ch XE1I9HTUumdAkzURvKvuncWvksMNs4_aofvwlxUS53MtGeiJZsmCd0lt4vHb mDqG9EdLG9HS1iVfrKvn0ErvH2wVLQUyDcms6nfJ7Kt2GSut6g4jOuAEfLzo hyX7coM5q Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Fri, 31 Aug 2012 09:01:41 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346427940.66948.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: <1346428901.34367.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 09:01:41 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-1652981494-1346428901=:34367" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 16:01:47 -0000 --1458549034-1652981494-1346428901=:34367 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I was looking for parity between the GSS and SASL contexts so that the same= things can be supported in both.=A0 =0A=0A=0A=0A=0A>______________________= __________=0A> From: Nico Williams =0A>To: William M= ills =0A>Cc: "kitten@ietf.org" ; Ry= an Troll ; Simon Josefsson =0A>S= ent: Friday, August 31, 2012 8:53 AM=0A>Subject: Re: [kitten] requirements/= context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>On = Fri, Aug 31, 2012 at 10:45 AM, William Mills wrote:= =0A>> We want an ID in clear text (not contained in the token) to be presen= t for=0A>> use by the mechanism, how do we solve this?=A0 Gs2-header clearl= y isn't it.=0A>=0A>Now I'm the one who's frustrated.=A0 I suspect you're no= t reading what I=0A>wrote, probably because you've reached the frustration = level where=0A>you'd stop reading what we have to say.=0A>=0A>You only need= an authz-id in a SASL context.=A0 You do not need an=0A>authz-id in a GSS = context.=0A>=0A>gs2-header present -> SASL context.=0A>=0A>gs2-header absen= t -> GSS context.=0A>=0A>Ryan needs an authz-id, absolutely needs it.=A0 He= only needs it in SASL contexts.=0A>=0A>Nico=0A>--=0A>=0A>=0A> --1458549034-1652981494-1346428901=:34367 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I was loo= king for parity between the GSS and SASL contexts so that the same things c= an be supported in both. 

From: Nico Williams <nico@cryptonector.com>
To: William Mills <wmills@yah= oo-inc.com>
Cc: "ki= tten@ietf.org" <kitten@ietf.org>; Ryan Troll <rtroll@googlers.com&= gt;; Simon Josefsson <simon@josefsson.org>
Sent: Friday, August 31, 2012 8:53 AM
Subject: Re: [kitten] requirements/conte= xt/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05
On Fri, Aug 31, 2012 at 10:45 AM, William Mills <wmills@yaho= o-inc.com> wrote:
> We want an ID in clear text (not contained= in the token) to be present for
> use by the mechanism, how do we so= lve this?  Gs2-header clearly isn't it.

Now I'm the one who's f= rustrated.  I suspect you're not reading what I
wrote, probably bec= ause you've reached the frustration level where
you'd stop reading what = we have to say.

You only need an authz-id in a SASL context.  Y= ou do not need an
authz-id in a GSS context.

gs2-header present -> SASL context.

gs2-header absent -> GSS context.

Rya= n needs an authz-id, absolutely needs it.  He only needs it in SASL co= ntexts.

Nico
--


<= /div> --1458549034-1652981494-1346428901=:34367-- From nico@cryptonector.com Fri Aug 31 09:04:11 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA1A21F85AD for ; Fri, 31 Aug 2012 09:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 hTXaW5-GDk6J for ; Fri, 31 Aug 2012 09:04:11 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id C526121F85A1 for ; Fri, 31 Aug 2012 09:04:10 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 00832428079 for ; Fri, 31 Aug 2012 09:03:59 -0700 (PDT) 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; s=cryptonector.com; bh=HZm08mmfiX28ewTJJuuo ZddyPds=; b=Oh/bHpqAOeVWvcYMoOiEMVu+d49sXTDtiwgCwPUpse41XUyiIgi5 kKAu1DXIej5dKyGEhDPVdKLDgEMZ/p7f1T+k4CcReNTbGDXxrIzh8R8uz1ISmuBG xnqsi1JMMXlRJUZxXwIOcKqCL5c2BmR9qATFPHxMQbwQG4K81+2MVbA= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id E41CE428014 for ; Fri, 31 Aug 2012 09:03:58 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4866768pbb.31 for ; Fri, 31 Aug 2012 09:03:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.220.104 with SMTP id pv8mr17967758pbc.119.1346429038606; Fri, 31 Aug 2012 09:03:58 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 31 Aug 2012 09:03:58 -0700 (PDT) In-Reply-To: <1346428901.34367.YahooMailNeo@web31812.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346427940.66948.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346428901.34367.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 11:03:58 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 16:04:12 -0000 On Fri, Aug 31, 2012 at 11:01 AM, William Mills wrote: > I was looking for parity between the GSS and SASL contexts so that the same > things can be supported in both. Semantically infeasible. That's why we have GS2, to bridge the gap. Be conformant to GS2 and you get SASL and GSS for the price of one. From rtroll@google.com Fri Aug 31 14:44:17 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E25811E80DC for ; Fri, 31 Aug 2012 14:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.946 X-Spam-Level: X-Spam-Status: No, score=-102.946 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 a+NdUzBRL-yA for ; Fri, 31 Aug 2012 14:44:16 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6526811E80BA for ; Fri, 31 Aug 2012 14:44:16 -0700 (PDT) Received: by qadz3 with SMTP id z3so1385290qad.10 for ; Fri, 31 Aug 2012 14:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=F37nNVtE1eBEg7xa23D4TDln7v+AZnexhdyswUbwAfs=; b=HFP4nAyXgDrBETwpRo+g3JfpJ73PmWG29Ao1ZKfJz8YpUOWsx1BRGgfRGKufJWeP53 4dLHZiQI2dTIyae0Gw4qt47UranQwvsUduLzEPAoJvMcXS3M5/qTZ2uNdCY9QizgvjLi 5ByR8TmXrrDcoFs8Mbk7w2oFQ1T3DL8UGhrS4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=F37nNVtE1eBEg7xa23D4TDln7v+AZnexhdyswUbwAfs=; b=hDb/5Dp+bvWr8BXr2GXHrJPEFT1ApcI2nUzbQPV2ZL+BMiYhF10oWugbV69SDiw0kQ xMsfppqka7YKtJkAIIoYBrlyXw0km7rXRoVgD1JUWQEg4Mp/7Sc8zMnTh1ZGslvKJGb2 xtpUfMc6kvd6D6Hh8FYPLI68F9COfZjuQT02eyf9pPnCQe22bUMiCyxSx5Qm1PlU1jaM RK0P20nvf5Ati9ZKucs1U1+oF3SK97753Mq/1qMOT6dEXk0gLwzJiPTtKiZNB74X8qun jYEimv9NB5rSsrEgCvyCG1wj7jlaxgfmoLdRdibHfJcoxD1D+KN0s+C1QZLo8Gu3HhVd fxvg== Received: by 10.224.9.13 with SMTP id j13mr20579264qaj.49.1346449455476; Fri, 31 Aug 2012 14:44:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.9.13 with SMTP id j13mr20579242qaj.49.1346449455279; Fri, 31 Aug 2012 14:44:15 -0700 (PDT) Received: by 10.49.132.202 with HTTP; Fri, 31 Aug 2012 14:44:15 -0700 (PDT) In-Reply-To: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346427940.66948.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346428901.34367.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 14:44:15 -0700 Message-ID: From: Ryan Troll To: Nico Williams Content-Type: multipart/alternative; boundary=bcaec51b1b217d6e9904c896b1af X-System-Of-Record: true X-Gm-Message-State: ALoCoQnV8723lAxzmzCYAvE16L8PnY8/4qluILCt5iaIL71RS5BeaMahHrlHVUM/pMnFkcJv9hqiIlsBNq7PdrnLz3G6WzE1p14XkI1j1GkbXxhZHzWHNTjPrEUNqffE9FqmJ+90ZWgDdEQSeyN+v20Jc+ZQJqyG0Kj2avtB8sK0dZGexjcaelDdXSCUw8s8zUHTyjRnUOz2 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 21:44:17 -0000 --bcaec51b1b217d6e9904c896b1af Content-Type: text/plain; charset=ISO-8859-1 Sorry for the delay in responding - I just got back and read through this. I suspect you're both right, the frustration level in this thread is high. One thing that was eye-opening to me is that the GS2 header winds up only being available to the SASL mechanism. Given the name - GS2 - when I first read about it, I formed the opinion that it would be present when the mechanism is being used within GSS-API, and not SASL. Nico's clarified that a few messages ago, which helped me. For protocols utilizing SASL, the proposal would be that the body communicated from the Client to the Server contains a GS2 header, and that header would be available for use by the OAuth mechanism. The data I'm looking for, and originally asked to be in the User: header, is in the GS2 header. As a result, the presence of the GS2 header lets me meet my needs. My assumption is that, for protocols utilizing GSS-API, the information within the GS2 header is actually communicated between the Client and the Server via (given my lack of GSS-API knowledge) GSS-API Magic. The OAuth mechanism can get to this information - for example, the authz-id - by looking at the GSS-API wrapper, rather than the data transmitted as part of the OAuth mechanism. In other words, the GS2 header defines a way to transmit the data that GSS-API sends, but SASL doesn't. *Nico:* If this summary sounds correct, I'm declaring a small victory for your description and helping me along. And I agree, the GS2 header contains the data I want, and meets my needs. *Bill: *If Nico says this summary is correct, I believe that your ultimate goal -- parity between SASL and GSS such that OAuth mechanism authors (Client and/or Server) have access to all of the same information -- has been achieved, with the addition of the GS2 header. Finally, if you both agree, I believe a phone call is not necessary. -R On Fri, Aug 31, 2012 at 9:03 AM, Nico Williams wrote: > On Fri, Aug 31, 2012 at 11:01 AM, William Mills > wrote: > > I was looking for parity between the GSS and SASL contexts so that the > same > > things can be supported in both. > > Semantically infeasible. That's why we have GS2, to bridge the gap. > Be conformant to GS2 and you get SASL and GSS for the price of one. > --bcaec51b1b217d6e9904c896b1af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry for the delay in responding - I just got back and read through this.<= div>

I suspect you're both right, the frus= tration level in this thread is high. =A0One thing that was eye-opening to = me is that the GS2 header winds up only being available to the SASL mechani= sm. =A0Given the name - GS2 - when I first read about it, I formed the opin= ion that it would be present when the mechanism is being used within GSS-AP= I, and not SASL. =A0Nico's clarified that a few messages ago, which hel= ped me.


For protocols utilizing SASL, the propos= al would be that the body communicated from the Client to the Server contai= ns a GS2 header, and that header would be available for use by the OAuth me= chanism. =A0The data I'm looking for, and originally asked to be in the= User: header, is in the GS2 header. =A0As a result, the presence of the GS= 2 header lets me meet my needs.

My assumption is that, for protocols utilizing GSS-API,= the information within the GS2 header is actually communicated between the= Client and the Server via (given my lack of GSS-API knowledge) GSS-API Mag= ic. =A0The OAuth mechanism can get to this information - for example, the a= uthz-id - by looking at the GSS-API wrapper, rather than the data transmitt= ed as part of the OAuth mechanism. =A0In other words, the GS2 header define= s a way to transmit the data that GSS-API sends, but SASL doesn't. =A0<= /div>

Nico:=A0 If this summary sounds correct, I'm= declaring a small victory for your description and helping me along. =A0An= d I agree, the GS2 header contains the data I want, and meets my needs.

Bill: =A0If Nico says this summary is correct, I= believe that your ultimate goal -- parity between SASL and GSS such that O= Auth mechanism=A0authors=A0(Client and/or Server) have access to all of the= same information -- has been achieved, with the addition of the GS2 header= .=A0

Finally, if you both agree, I believe a phone call is n= ot necessary.

-R


On Fri, Aug 31, 2012 at 9:03 AM, Nico Williams <nico@crypt= onector.com> wrote:
On Fri, Aug 31, 2012 at 11= :01 AM, William Mills <wmills@ya= hoo-inc.com> wrote:
> I was looking for parity between the GSS and SASL contexts so that the= same
> things can be supported in both.

Semantically infeasible. =A0That's why we have GS2, to bridge the= gap.
Be conformant to GS2 and you get SASL and GSS for the price of one.

--bcaec51b1b217d6e9904c896b1af-- From nico@cryptonector.com Fri Aug 31 15:02:13 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A25911E80BA for ; Fri, 31 Aug 2012 15:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 z9kDxftcvY4m for ; Fri, 31 Aug 2012 15:02:12 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 298D521F84AE for ; Fri, 31 Aug 2012 15:02:12 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 8503826C05E for ; Fri, 31 Aug 2012 15:02:05 -0700 (PDT) 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; s=cryptonector.com; bh=obL3luTIKftCtZeZ7H+f kz4EB/Y=; b=ddYEpD5b6D7uouIUaRUR2Q8TE2v5p6a8V7ufDMtT807J7ML395DI 4PyaiHjHBR9wpaOJODZWKS9GipdQsV2cDRM+H8O0g27Qc18QPWdFZjwsZ80acust dOsMyPnR9EDZvPHGAecowoYid6NgfCJszGc5cXMYpY14m6C7iQ/HVNU= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 6BCF526C057 for ; Fri, 31 Aug 2012 15:02:05 -0700 (PDT) Received: by dadf8 with SMTP id f8so2119463dad.31 for ; Fri, 31 Aug 2012 15:02:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.241.65 with SMTP id wg1mr20277360pbc.25.1346450525007; Fri, 31 Aug 2012 15:02:05 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 31 Aug 2012 15:02:04 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 31 Aug 2012 15:02:04 -0700 (PDT) In-Reply-To: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346427940.66948.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346428901.34367.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 17:02:04 -0500 Message-ID: From: Nico Williams To: Ryan Troll Content-Type: multipart/alternative; boundary=047d7b339c7b40311004c896f135 Cc: kitten@ietf.org, Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 22:02:13 -0000 --047d7b339c7b40311004c896f135 Content-Type: text/plain; charset=UTF-8 On Aug 31, 2012 5:44 PM, "Ryan Troll" wrote: > > Sorry for the delay in responding - I just got back and read through this. > > > I suspect you're both right, the frustration level in this thread is high. One thing that was eye-opening to me is that the GS2 header winds up only being available to the SASL mechanism. Given the name - GS2 - when I first read about it, I formed the opinion that it would be present when the mechanism is being used within GSS-API, and not SASL. Nico's clarified that a few messages ago, which helped me. Ah, heh. "GS2" = next generation replacement for the first SASL/GSS bridge. We took to calling them gs1 and gs2. If you look at RFC2222 you'll see the original bridge. There were some aspects of gs1 that made us sad, useful though it had been. So we built a replacement. (GS1 became RFC4752.] > For protocols utilizing SASL, the proposal would be that the body communicated from the Client to the Server contains a GS2 header, and that header would be available for use by the OAuth mechanism. The data I'm looking for, and originally asked to be in the User: header, is in the GS2 header. As a result, the presence of the GS2 header lets me meet my needs. Right. > My assumption is that, for protocols utilizing GSS-API, the information within the GS2 header is actually communicated between the Client and the Server via (given my lack of GSS-API knowledge) GSS-API Magic. The OAuth mechanism can get to this information - for example, the authz-id - by looking at the GSS-API wrapper, rather than the data transmitted as part of the OAuth mechanism. In other words, the GS2 header defines a way to transmit the data that GSS-API sends, but SASL doesn't. Pure GSS-API apps must communicate anything like an authz-id in the app prptocol. Look at how SSHv2 does it -- see RFC4256. > Nico: If this summary sounds correct, I'm declaring a small victory for your description and helping me along. And I agree, the GS2 header contains the data I want, and meets my needs. Yes, see above for a slight correction regarding pure GSS-API apps. > Bill: If Nico says this summary is correct, I believe that your ultimate goal -- parity between SASL and GSS such that OAuth mechanism authors (Client and/or Server) have access to all of the same information -- has been achieved, with the addition of the GS2 header. Do not try to get SASL features in the pure GSS case that GSS doesn't support. Just usr the gs2-header in the SASL case and accept the absence of authz-id in the GSS case. > Finally, if you both agree, I believe a phone call is not necessary. It'd still be good to "meet" so we can firm a better relationship such that in the future we might avoid frustration altogether :) Nico -- --047d7b339c7b40311004c896f135 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 31, 2012 5:44 PM, "Ryan Troll" <rtroll@googlers.com> wrote:
>
> Sorry for the delay in responding - I just got back and read through t= his.
>
>
> I suspect you're both right, the frustration level in this thread = is high. =C2=A0One thing that was eye-opening to me is that the GS2 header = winds up only being available to the SASL mechanism. =C2=A0Given the name -= GS2 - when I first read about it, I formed the opinion that it would be pr= esent when the mechanism is being used within GSS-API, and not SASL. =C2=A0= Nico's clarified that a few messages ago, which helped me.

Ah, heh.=C2=A0 "GS2" =3D next generation replacement for the f= irst SASL/GSS bridge.=C2=A0 We took to calling them gs1 and gs2.

If you look at RFC2222 you'll see the original bridge.=C2=A0 There w= ere some aspects of gs1 that made us sad, useful though it had been.=C2=A0 = So we built a replacement.=C2=A0 (GS1 became RFC4752.]

> For protocols utilizing SASL, the proposal would be that the body c= ommunicated from the Client to the Server contains a GS2 header, and that h= eader would be available for use by the OAuth mechanism. =C2=A0The data I&#= 39;m looking for, and originally asked to be in the User: header, is in the= GS2 header. =C2=A0As a result, the presence of the GS2 header lets me meet= my needs.

Right.

> My assumption is that, for protocols utilizing GSS-API, the informa= tion within the GS2 header is actually communicated between the Client and = the Server via (given my lack of GSS-API knowledge) GSS-API Magic. =C2=A0Th= e OAuth mechanism can get to this information - for example, the authz-id -= by looking at the GSS-API wrapper, rather than the data transmitted as par= t of the OAuth mechanism. =C2=A0In other words, the GS2 header defines a wa= y to transmit the data that GSS-API sends, but SASL doesn't. =C2=A0

Pure GSS-API apps must communicate anything like an authz-id in the app = prptocol.=C2=A0 Look at how SSHv2 does it -- see RFC4256.

> Nico:=C2=A0 If this summary sounds correct, I'm declaring a sma= ll victory for your description and helping me along. =C2=A0And I agree, th= e GS2 header contains the data I want, and meets my needs.

Yes, see above for a slight correction regarding pure GSS-API apps.

> Bill: =C2=A0If Nico says this summary is correct, I believe that yo= ur ultimate goal -- parity between SASL and GSS such that OAuth mechanism= =C2=A0authors=C2=A0(Client and/or Server) have access to all of the same in= formation -- has been achieved, with the addition of the GS2 header.=C2=A0<= /p>

Do not try to get SASL features in the pure GSS case that GSS doesn'= t support.=C2=A0 Just usr the gs2-header in the SASL case and accept the ab= sence of authz-id in the GSS case.

> Finally, if you both agree, I believe a phone call is not necessary= .

It'd still be good to "meet" so we can firm a better relat= ionship such that in the future we might avoid frustration altogether :)

Nico
--

--047d7b339c7b40311004c896f135-- From nico@cryptonector.com Fri Aug 31 16:28:28 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960E511E808E for ; Fri, 31 Aug 2012 16:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.815 X-Spam-Level: X-Spam-Status: No, score=-2.815 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 77j8XtdvCIRl for ; Fri, 31 Aug 2012 16:28:28 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 13EF411E808D for ; Fri, 31 Aug 2012 16:28:28 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id B9C5F1B4059 for ; Fri, 31 Aug 2012 16:28:27 -0700 (PDT) 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; s=cryptonector.com; bh=Sn7lWSK39dYTjQ2va+rc C9HbSec=; b=PG1K5D6f8DJjhkwgb39R4wqLLSiZuqGvJV/8KvITaSwDpbKAt0bt gjJJ4PKCsoTuyFw9+ozsSme7czOb7kZOY5HxUzBZJEoC7vz43OybyWsGpPY1foT7 WOeG7xKWyN01yuKZeZiAlhew65q8SeE6+lCzedzuX3WMLx+fdDSfG7c= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id A72491B4061 for ; Fri, 31 Aug 2012 16:28:27 -0700 (PDT) Received: by dadf8 with SMTP id f8so2152369dad.31 for ; Fri, 31 Aug 2012 16:28:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.220.104 with SMTP id pv8mr20271861pbc.119.1346455707367; Fri, 31 Aug 2012 16:28:27 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 31 Aug 2012 16:28:27 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 31 Aug 2012 16:28:27 -0700 (PDT) In-Reply-To: References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346427940.66948.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346428901.34367.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 18:28:27 -0500 Message-ID: From: Nico Williams To: Ryan Troll Content-Type: multipart/alternative; boundary=e89a8ff254cc24b91704c89826b2 Cc: kitten@ietf.org, Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 23:28:28 -0000 --e89a8ff254cc24b91704c89826b2 Content-Type: text/plain; charset=UTF-8 > Do not try to get SASL features in the pure GSS case that GSS doesn't support. Just usr the gs2-header in the SASL case and accept the absence of authz-id in the GSS case. I clarify: in the pure GSS case any missing features should added to the app protocol. Examples of that: how SSHv2 deals with the username when using GSS, NFS' RPCSEC_GSSv3, and if you think of GS2 as a GSS application (which it basically is), then GS2. --e89a8ff254cc24b91704c89826b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


> Do not try to get SASL features in the pure GSS case that GSS doesn= 9;t support.=C2=A0 Just usr the gs2-header in the SASL case and accept the = absence of authz-id in the GSS case.

I clarify: in the pure GSS case any missing features should added to the= app protocol.=C2=A0 Examples of that:=C2=A0 how SSHv2 deals with the usern= ame when using GSS, NFS' RPCSEC_GSSv3, and if you think of GS2 as a GSS= application (which it basically is), then GS2.

--e89a8ff254cc24b91704c89826b2-- From wmills@yahoo-inc.com Fri Aug 31 16:41:51 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9801A21F849D for ; Fri, 31 Aug 2012 16:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.575 X-Spam-Level: X-Spam-Status: No, score=-17.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 uDQr887Inzlo for ; Fri, 31 Aug 2012 16:41:50 -0700 (PDT) Received: from nm32-vm7.bullet.mail.bf1.yahoo.com (nm32-vm7.bullet.mail.bf1.yahoo.com [72.30.239.143]) by ietfa.amsl.com (Postfix) with SMTP id 3598C21F849C for ; Fri, 31 Aug 2012 16:41:50 -0700 (PDT) Received: from [98.139.212.149] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 31 Aug 2012 23:41:49 -0000 Received: from [98.139.212.248] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 31 Aug 2012 23:41:49 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 31 Aug 2012 23:41:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 444247.19387.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 23458 invoked by uid 60001); 31 Aug 2012 23:41:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346456508; bh=OyfEYK38uLQ7Lk3Owj0zQypHGmWal9NPJGm5Ss+HoVY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=sQso1EydYymbJt8t2HK7a0jGH7UNt1WESoT5OajiaV4ynA5k4wwo36Mg94DY9yAKL3yx89FZqn+C8Ozaj+cX0Kxdb1VmZNNpRv2go5AneesVC1GkGCLXGhmQZlulJonhknIuzC023iNNOlVfdl33DxEEwltV/9EbVh0akXSJRQ8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CF8SPReGrpn2Io3sNO/WQAP9vstcCsDjrJBhzzwWosq5TtrYtnsP2vE2lEQp8cvfuZAE5vl8rtVHbEya1Z7AL6U1XleOxWf7XROujTLbK+zSmPGoMZjZIA3bRP33Oy6TaOeKvdlY6dMUEG7yH3zJ3qzsNDf5j7g6IDFMDc/9lw8=; X-YMail-OSG: eEH.3h4VM1nPf8OlPALn5rmclZ4og7OLnjh8zrAVXVqRRqf Q9azudlSuHPX6pMU44dLVPw1U3FeeVEEp7AI8mxZx8J0NNevQkPqR0UrXf70 bi3m3OhcZz1_h5p3vZlpxqkyDpH5k7fs0v8rZcoYAEVSYgAI3UGhyUS.OE6z lJcTeS8ySTcXQCES.bPk37uwvNZRfzTPgGtP3uTgc0QaXjOUt3Uz4CJ0JNSW oYTqpebu_B6xZIXXyzsXKVDp6XmUGpNHYmXyb7H09cpFcTF2BiqJBjU7.9ta hZR0ZN8tsaSBRs52YlTD99dWsl7BXXAvEWr5uHS1q8fK9GyDI7WaQjVO3eZ0 AmPg.skVJXIP16uqbNcSMzw4ZEyBz22FG2qu5j8sW79fRrPXdaL88DhmLElB WAw8UO2NV3mzrn0ipKvFHA7o59yAeQfrHkI2sImaCQWbJ Received: from [99.31.212.42] by web31816.mail.mud.yahoo.com via HTTP; Fri, 31 Aug 2012 16:41:48 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346427940.66948.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346428901.34367.YahooMailNeo@web31812.mail.mud.yahoo.com> Message-ID: <1346456508.8798.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 16:41:48 -0700 (PDT) From: William Mills To: Nico Williams , Ryan Troll In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-213885224-1346456508=:8798" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 23:41:51 -0000 ---1238014912-213885224-1346456508=:8798 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Nico,=0A=0AAs a subtext here you keep saying "don't do that" to the use cas= e where we need to have access to the user ID.=A0=A0 That's a key part of t= he frustration here, you're not proposing a solution that solves the proble= m in all cases.=A0 Evidently there's some good reason for this.=A0 I person= ally don't care about the case where the gs2-header isn't present, but inte= llectually I want these things to be equivalent.=A0 =0A=0AIs the miscommuni= cation here that you do not accept the use case that we need access to the = identity?=A0 That we're solving different problems?=0A=0A-bill=0A=0A=0A=0A= =0A=0A=0A>________________________________=0A> From: Nico Williams =0A>To: Ryan Troll =0A>Cc: kitten@ietf= .org; William Mills ; Simon Josefsson =0A>Sent: Friday, August 31, 2012 3:02 PM=0A>Subject: Re: [kitten] r= equirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05= =0A> =0A>=0A>=0A>On Aug 31, 2012 5:44 PM, "Ryan Troll" wrote:=0A>>=0A>> Sorry for the delay in responding - I just got back and = read through this.=0A>>=0A>>=0A>> I suspect you're both right, the frustrat= ion level in this thread is high. =A0One thing that was eye-opening to me i= s that the GS2 header winds up only being available to the SASL mechanism. = =A0Given the name - GS2 - when I first read about it, I formed the opinion = that it would be present when the mechanism is being used within GSS-API, a= nd not SASL. =A0Nico's clarified that a few messages ago, which helped me.= =0A>Ah, heh.=A0 "GS2" =3D next generation replacement for the first SASL/GS= S bridge.=A0 We took to calling them gs1 and gs2.=0A>If you look at RFC2222= you'll see the original bridge.=A0 There were some aspects of gs1 that mad= e us sad, useful though it had been.=A0 So we built a replacement.=A0 (GS1 = became RFC4752.]=0A>=0A>> For protocols utilizing SASL, the proposal would = be that the body communicated from the Client to the Server contains a GS2 = header, and that header would be available for use by the OAuth mechanism. = =A0The data I'm looking for, and originally asked to be in the User: header= , is in the GS2 header. =A0As a result, the presence of the GS2 header lets= me meet my needs.=0A>Right.=0A>> My assumption is that, for protocols util= izing GSS-API, the information within the GS2 header is actually communicat= ed between the Client and the Server via (given my lack of GSS-API knowledg= e) GSS-API Magic. =A0The OAuth mechanism can get to this information - for = example, the authz-id - by looking at the GSS-API wrapper, rather than the = data transmitted as part of the OAuth mechanism. =A0In other words, the GS2= header defines a way to transmit the data that GSS-API sends, but SASL doe= sn't. =A0=0A>Pure GSS-API apps must communicate anything like an authz-id i= n the app prptocol.=A0 Look at how SSHv2 does it -- see RFC4256.=0A>> Nico:= =A0 If this summary sounds correct, I'm declaring a small victory for your = description and helping me along. =A0And I agree, the GS2 header contains t= he data I want, and meets my needs.=0A>Yes, see above for a slight correcti= on regarding pure GSS-API apps.=0A>> Bill: =A0If Nico says this summary is = correct, I believe that your ultimate goal -- parity between SASL and GSS s= uch that OAuth mechanism=A0authors=A0(Client and/or Server) have access to = all of the same information -- has been achieved, with the addition of the = GS2 header.=A0=0A>Do not try to get SASL features in the pure GSS case that= GSS doesn't support.=A0 Just usr the gs2-header in the SASL case and accep= t the absence of authz-id in the GSS case.=0A>> Finally, if you both agree,= I believe a phone call is not necessary.=0A>It'd still be good to "meet" s= o we can firm a better relationship such that in the future we might avoid = frustration altogether :)=0A>Nico=0A>-- =0A>=0A> ---1238014912-213885224-1346456508=:8798 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Nico,
=
As a subtext here you keep saying "don't do that" to the use case where= we need to have access to the user ID.   That's a key part of th= e frustration here, you're not proposing a solution that solves the problem= in all cases.  Evidently there's some good reason for this.  I p= ersonally don't care about the case where the gs2-header isn't present, but= intellectually I want these things to be equivalent. 

Is the = miscommunication here that you do not accept the use case that we need acce= ss to the identity?  That we're solving different problems?

-bi= ll



From: Nico Will= iams <nico@cryptonector.com>
Cc: kitten@ietf.org; William Mills <w= mills@yahoo-inc.com>; Simon Josefsson <simon@josefsson.org>
<= b>Sent: Friday, August 31, 20= 12 3:02 PM
Subject: Re= : [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SA= SL draft -05


=0AOn Aug 31, 2012 5:= 44 PM, "Ryan Troll" <rtroll@google= rs.com> wrote:
=0A>
=0A> Sorry for the delay in respondi= ng - I just got back and read through this.
=0A>
=0A>
=0A>= ; I suspect you're both right, the frustration level in this thread is high= .  One thing that was eye-opening to me is that the GS2 header winds u= p only being available to the SASL mechanism.  Given the name - GS2 - = when I first read about it, I formed the opinion that it would be present w= hen the mechanism is being used within GSS-API, and not SASL.  Nico's = clarified that a few messages ago, which helped me.
=0A=0A
Ah, heh= .  "GS2" =3D next generation replacement for the first SASL/GSS bridge= .  We took to calling them gs1 and gs2.
=0A
If you look at RF= C2222 you'll see the original bridge.  There were some aspects of gs1 = that made us sad, useful though it had been.  So we built a replacemen= t.  (GS1 became RFC4752.]
=0A
> For protocols utilizin= g SASL, the proposal would be that the body communicated from the Client to= the Server contains a GS2 header, and that header would be available for u= se by the OAuth mechanism.  The data I'm looking for, and originally a= sked to be in the User: header, is in the GS2 header.  As a result, th= e presence of the GS2 header lets me meet my needs.
=0A=0A
Right.<= /div>=0A
> My assumption is that, for protocols utilizing GSS-API, t= he information within the GS2 header is actually communicated between the C= lient and the Server via (given my lack of GSS-API knowledge) GSS-API Magic= .  The OAuth mechanism can get to this information - for example, the = authz-id - by looking at the GSS-API wrapper, rather than the data transmit= ted as part of the OAuth mechanism.  In other words, the GS2 header de= fines a way to transmit the data that GSS-API sends, but SASL doesn't. &nbs= p;
=0A=0A
Pure GSS-API apps must communicate anything like an auth= z-id in the app prptocol.  Look at how SSHv2 does it -- see RFC4256.=0A
> Nico:  If this summary sounds correct, I'm declaring = a small victory for your description and helping me along.  And I agre= e, the GS2 header contains the data I want, and meets my needs.
=0AYes, see above for a slight correction regarding pure GSS-API apps.
= =0A
> Bill:  If Nico says this summary is correct, I believe th= at your ultimate goal -- parity between SASL and GSS such that OAuth mechan= ism authors (Client and/or Server) have access to all of the same= information -- has been achieved, with the addition of the GS2 header.&nbs= p;
=0A=0A
Do not try to get SASL features in the pure GSS case tha= t GSS doesn't support.  Just usr the gs2-header in the SASL case and a= ccept the absence of authz-id in the GSS case.
=0A
> Finally, i= f you both agree, I believe a phone call is not necessary.
=0A
It'= d still be good to "meet" so we can firm a better relationship such that in= the future we might avoid frustration altogether :)
=0A
Nico
= =0A--
=0A


---1238014912-213885224-1346456508=:8798-- From cantor.2@osu.edu Fri Aug 31 17:46:31 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBD011E808E for ; Fri, 31 Aug 2012 17:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 5xGs7hz3jhSl for ; Fri, 31 Aug 2012 17:46:31 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 132E311E808D for ; Fri, 31 Aug 2012 17:46:24 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q810kKcY028356; Fri, 31 Aug 2012 20:46:22 -0400 Received: from CIO-TNC-D1MBX09.osuad.osu.edu ([fe80::1c1e:740:88e5:3701]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.02.0309.002; Fri, 31 Aug 2012 20:46:17 -0400 From: "Cantor, Scott" To: William Mills Thread-Topic: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNh9sy3nZGt9SIc06lTvTq9mV+0w== Date: Sat, 1 Sep 2012 00:46:17 +0000 Message-ID: In-Reply-To: <1346456508.8798.YahooMailNeo@web31816.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.74.80.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <1CC2F42F7964FE4B982FDC47CC86D7D2@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "kitten@ietf.org" Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 00:46:31 -0000 On 8/31/12 7:41 PM, "William Mills" wrote: > >As a subtext here you keep saying "don't do that" to the use case where >we need to have access to the user ID. You CANNOT do this with GSS-API. That's why he's saying "don't do that". >That's a key part of the frustration here, you're not proposing a >solution that solves the problem in all cases. Evidently there's some >good reason for this. I personally don't care about the case where the >gs2-header isn't present, but intellectually I want these things to be >equivalent. They can't be. GSS-API does not have a concept of an authorization ID. That's the "good reason". It's not appropriate for mechanisms to introduce concepts that would be expected to surface at the application layer because that would make applications non-portable to mechanisms that didn't support that concept. An exception to this is an example like the name attributes extension. That was developed so that modern mechanisms like SAML that expose user identity as more than just a simple string can expose that additional data. But by making it an extension, applications are able to control whether they directly depend on that extension rather than treating it as a mechanism specific feature. >Is the miscommunication here that you do not accept the use case that we >need access to the identity? That we're solving different problems? He's not denying your use case, it's simply not one that is permitted by the API. If you want that feature, it has to show up in the application protocol itself, much as it shows up in SASL generically (so thus becomes usable across protocols that support SASL). I think you should consider that when you started this, you had a SASL mechanism. Some of us want that mechanism to be GSS-capable. But in doing so, we do not ask that you provide a feature (authzid) that we know cannot in fact be part of your mechanism. So we're not asking you to provide that. Does that help? -- Scott From lukeh@padl.com Fri Aug 31 17:51:26 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA99821F84FA for ; Fri, 31 Aug 2012 17:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 aYATzJYi2Pq0 for ; Fri, 31 Aug 2012 17:51:26 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id CA17121F84F6 for ; Fri, 31 Aug 2012 17:51:25 -0700 (PDT) Received: by us.padl.com with ESMTP id q810pA9Z012142; Fri, 31 Aug 2012 20:51:13 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_CA2EEACF-DE5F-40DE-B450-B461B78F865B" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: <1346456508.8798.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Sat, 1 Sep 2012 10:51:07 +1000 Message-Id: <3008858F-8BF8-487F-B5EB-B3EB0D0BD35F@padl.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346427940.66948.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346428901.34367.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346456508.8798.YahooMailNeo! @web31816.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 00:51:27 -0000 --Apple-Mail=_CA2EEACF-DE5F-40DE-B450-B461B78F865B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Bill, On 01/09/2012, at 9:41 AM, William Mills wrote: > As a subtext here you keep saying "don't do that" to the use case = where we need to have access to the user ID. That's a key part of the = frustration here, you're not proposing a solution that solves the = problem in all cases. Evidently there's some good reason for this. I = personally don't care about the case where the gs2-header isn't present, = but intellectually I want these things to be equivalent. =20 I understand your concern. I believe the answer is: in protocols that = use GSS directly, the authorisation identity equivalent is transmitted = in the application protocol itself (for example SSH does this). Now, of course there may be application protocols that use GSS directly = and don't have such an equivalent. It's a trade-off, because to = introduce an authorisation identity directly into a GS2 mechanism would = result in this information being duplicated for the majority case, and = would break the abstraction (i.e. you couldn't implement OAuth as a GSS = mechanism and use it [with the appropriate bridge] with SASL). Also, = Ryan's requirement would only be satisfied for OAuth, rather than all = GS2 mechanisms (it seems less than ideal for a load-balancer to only = work with one particular security mechanism). The alternative is to specify a SASL mechanism that doesn't fit the GS2 = profile, which is fine. But then you don't get GSS support, so you're = back where you started. So my advice would be to accept this trade-off = and specify it as a GS2 mechanism. -- Luke= --Apple-Mail=_CA2EEACF-DE5F-40DE-B450-B461B78F865B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 wmills@yahoo-inc.com> = wrote:

As a subtext here you keep saying "don't do that" to the use = case where we need to have access to the user ID.   That's a = key part of the frustration here, you're not proposing a solution that = solves the problem in all cases.  Evidently there's some good = reason for this.  I personally don't care about the case where the = gs2-header isn't present, but intellectually I want these things to be = equivalent.  

I understand your concern. I = believe the answer is: in protocols that use GSS directly, the = authorisation identity equivalent is transmitted in the application = protocol itself (for example SSH does this).

Now, = of course there may be application protocols that use GSS directly and = don't have such an equivalent. It's a trade-off, because to introduce an = authorisation identity directly into a GS2 mechanism would result in = this information being duplicated for the majority case, and would break = the abstraction (i.e. you couldn't implement OAuth as a GSS mechanism = and use it [with the appropriate bridge] with SASL). Also, Ryan's = requirement would only be satisfied for OAuth, rather than all GS2 = mechanisms (it seems less than ideal for a load-balancer to only work = with one particular security mechanism).

The = alternative is to specify a SASL mechanism that doesn't fit the GS2 = profile, which is fine. But then you don't get GSS support, so you're = back where you started. So my advice would be to accept this trade-off = and specify it as a GS2 mechanism.

-- = Luke
= --Apple-Mail=_CA2EEACF-DE5F-40DE-B450-B461B78F865B-- From lukeh@padl.com Fri Aug 31 17:53:27 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B7321F8493 for ; Fri, 31 Aug 2012 17:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 17lqv1GrH9I8 for ; Fri, 31 Aug 2012 17:53:27 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 15BE421F848F for ; Fri, 31 Aug 2012 17:53:27 -0700 (PDT) Received: by us.padl.com with ESMTP id q810qn9w012159; Fri, 31 Aug 2012 20:52:52 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_D7513D0F-6D35-43B9-9A55-0DB366FAB457" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: <3008858F-8BF8-487F-B5EB-B3EB0D0BD35F@padl.com> Date: Sat, 1 Sep 2012 10:52:47 +1000 Message-Id: <8173AB7E-FE2A-453D-95CB-0D5F7A3E91D9@padl.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346427940.66948.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346428901.34367.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346456508.8798.YahooMailNeo! @web31816.mail.mud.yahoo.com> <3008858F-8BF8-487F-B5EB-B3EB0D0BD35F@padl.com> To: William Mills X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: kitten@ietf.org, Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 00:53:28 -0000 --Apple-Mail=_D7513D0F-6D35-43B9-9A55-0DB366FAB457 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I should have read Scott's message first, he explains things more = clearly/absolutely than I did. On 01/09/2012, at 10:51 AM, Luke Howard wrote: > Bill, >=20 > On 01/09/2012, at 9:41 AM, William Mills wrote: >=20 >> As a subtext here you keep saying "don't do that" to the use case = where we need to have access to the user ID. That's a key part of the = frustration here, you're not proposing a solution that solves the = problem in all cases. Evidently there's some good reason for this. I = personally don't care about the case where the gs2-header isn't present, = but intellectually I want these things to be equivalent. =20 >=20 >=20 > I understand your concern. I believe the answer is: in protocols that = use GSS directly, the authorisation identity equivalent is transmitted = in the application protocol itself (for example SSH does this). >=20 > Now, of course there may be application protocols that use GSS = directly and don't have such an equivalent. It's a trade-off, because to = introduce an authorisation identity directly into a GS2 mechanism would = result in this information being duplicated for the majority case, and = would break the abstraction (i.e. you couldn't implement OAuth as a GSS = mechanism and use it [with the appropriate bridge] with SASL). Also, = Ryan's requirement would only be satisfied for OAuth, rather than all = GS2 mechanisms (it seems less than ideal for a load-balancer to only = work with one particular security mechanism). >=20 > The alternative is to specify a SASL mechanism that doesn't fit the = GS2 profile, which is fine. But then you don't get GSS support, so = you're back where you started. So my advice would be to accept this = trade-off and specify it as a GS2 mechanism. >=20 > -- Luke -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com --Apple-Mail=_D7513D0F-6D35-43B9-9A55-0DB366FAB457 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = should have read Scott's message first, he explains things more = clearly/absolutely than I did.

On 01/09/2012, at 10:51 = AM, Luke Howard <lukeh@padl.com> wrote:

wmills@yahoo-inc.com> = wrote:

As a subtext here you keep saying "don't do that" to the use = case where we need to have access to the user ID.   That's a = key part of the frustration here, you're not proposing a solution that = solves the problem in all cases.  Evidently there's some good = reason for this.  I personally don't care about the case where the = gs2-header isn't present, but intellectually I want these things to be = equivalent.  

I understand your concern. I = believe the answer is: in protocols that use GSS directly, the = authorisation identity equivalent is transmitted in the application = protocol itself (for example SSH does this).

Now, = of course there may be application protocols that use GSS directly and = don't have such an equivalent. It's a trade-off, because to introduce an = authorisation identity directly into a GS2 mechanism would result in = this information being duplicated for the majority case, and would break = the abstraction (i.e. you couldn't implement OAuth as a GSS mechanism = and use it [with the appropriate bridge] with SASL). Also, Ryan's = requirement would only be satisfied for OAuth, rather than all GS2 = mechanisms (it seems less than ideal for a load-balancer to only work = with one particular security mechanism).

The = alternative is to specify a SASL mechanism that doesn't fit the GS2 = profile, which is fine. But then you don't get GSS support, so you're = back where you started. So my advice would be to accept this trade-off = and specify it as a GS2 mechanism.

-- = Luke


= --Apple-Mail=_D7513D0F-6D35-43B9-9A55-0DB366FAB457-- From wmills@yahoo-inc.com Fri Aug 31 17:56:08 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FC121F849A for ; Fri, 31 Aug 2012 17:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.56 X-Spam-Level: X-Spam-Status: No, score=-17.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 AlTDzHUvOMBU for ; Fri, 31 Aug 2012 17:56:07 -0700 (PDT) Received: from nm40-vm6.bullet.mail.bf1.yahoo.com (nm40-vm6.bullet.mail.bf1.yahoo.com [72.30.239.214]) by ietfa.amsl.com (Postfix) with SMTP id 405E221F8498 for ; Fri, 31 Aug 2012 17:56:07 -0700 (PDT) Received: from [98.139.212.150] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 01 Sep 2012 00:56:06 -0000 Received: from [98.139.212.246] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 01 Sep 2012 00:56:06 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 01 Sep 2012 00:56:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 590550.19089.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 79498 invoked by uid 60001); 1 Sep 2012 00:56:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346460964; bh=gpdegGzM2gZRb6u4Bg+1DQxrhLch9YFwpP4MRCe/eV0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=h12gZWVwy+GKmkZpVDEj7X+mqVS7VhTUK2DN8mqJVIiEsXpqJewgBqoLY5X5coQKXvWhjgx7Dj5Ok/kGH/MMr/tKK2N86hvYMizwi/t4S4oOPYVEu4zXX4kCMbNcS5UobQY/4JwSF4ns446q16In6N+iXumVqiIJWPPVFV+/G0s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cnZRD3C3aYDyXTUfnYN2/qdViTyWXgx2PH10uJD43IJdyhRrQHtR9B/A8TfzujH8xXP1hP7VhrhWM8U7ROXtXWQyT6wBEyjU02kmMDwvWZVfM03HplyY4CSZ7PqsEaDRJd9GRODWiz7keOltbKY9z3fBzosUH5kZ7QbREmfmT5Y=; X-YMail-OSG: 4R9gbfEVM1kqLY6xc78OS3mqs.ETOcC.t7dnilcVyOw9uRc P.hhuvffwg7wp98JCNCa3lIz7KQImWV3XZ3F8CVh.1GFmA7r4sHxFd_M2_Cp Gq3cfR6YbXmM2XJg.xWozQXi5hJV1LGL53V.BHwrPj11PKZMJJtsXalUCDWg ndfVlt4EDJ5L5LHB5G85ROB5acxgQQzz7g7XH7bJvRaWL5rBpZ43DOcqqPx1 bMqCl2iKoNswnniE5AoPCPucYLQftLSrN1WNqt96r0NurPEq3r8oxenlOA5s M1sDapD5N8EaDdsc3IGbW7UakngbEscn03W5vFOu_O5hHdAb1HHv3twzTTGa 7kBWgycq_UoBCqbapN7ybnvPK.IqzdLmhpuPzAKWx.8QjdtW4jUYctkjDMrc FjslLt_y_9ANULoXcdbPrFXUtetyvspw3YPtnKRhDjHs0vsWLCNpZcj92IbI ARKjjzQGC Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Fri, 31 Aug 2012 17:56:04 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346427940.66948.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346428901.34367.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346456508.8798.YahooMailNeo ! @web31816.mail.mud.yahoo.com> <3008858F-8BF8-487F-B5EB-B3EB0D0BD35F@padl.com> Message-ID: <1346460964.79308.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 17:56:04 -0700 (PDT) From: William Mills To: Luke Howard In-Reply-To: <3008858F-8BF8-487F-B5EB-B3EB0D0BD35F@padl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-1764189514-1346460964=:79308" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 00:56:08 -0000 ---551393103-1764189514-1346460964=:79308 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OK, between this and Scott's message I now understand.=0A=0AThank you.=0A= =0A=0A=0A=0A=0A>________________________________=0A> From: Luke Howard =0A>To: William Mills =0A>Cc: Nico Willi= ams ; Ryan Troll ; "kitten@ietf= .org" ; Simon Josefsson =0A>Sent: Fr= iday, August 31, 2012 5:51 PM=0A>Subject: Re: [kitten] requirements/context= /frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>=0A>Bill,= =0A>=0A>=0A>On 01/09/2012, at 9:41 AM, William Mills = wrote:=0A>=0A>As a subtext here you keep saying "don't do that" to the use= case where we need to have access to the user ID.=A0=A0 That's a key part = of the frustration here, you're not proposing a solution that solves the pr= oblem in all cases.=A0 Evidently there's some good reason for this.=A0 I pe= rsonally don't care about the case where the gs2-header isn't present, but = intellectually I want these things to be equivalent.=A0=A0=0A>>=0A>=0A>=0A>= I understand your concern. I believe the answer is: in protocols that use G= SS directly, the authorisation identity equivalent is transmitted in the ap= plication protocol itself (for example SSH does this).=0A>=0A>=0A>Now, of c= ourse there may be application protocols that use GSS directly and don't ha= ve such an equivalent. It's a trade-off, because to introduce an authorisat= ion identity directly into a GS2 mechanism would result in this information= being duplicated for the majority case, and would break the abstraction (i= .e. you couldn't implement OAuth as a GSS mechanism and use it [with the ap= propriate bridge] with SASL). Also, Ryan's requirement would only be satisf= ied for OAuth, rather than all GS2 mechanisms (it seems less than ideal for= a load-balancer to only work with one particular security mechanism).=0A>= =0A>=0A>The alternative is to specify a SASL mechanism that doesn't fit the= GS2 profile, which is fine. But then you don't get GSS support, so you're = back where you started. So my advice would be to accept this trade-off and = specify it as a GS2 mechanism.=0A>=0A>=0A>-- Luke=0A>=0A> ---551393103-1764189514-1346460964=:79308 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OK, betwe= en this and Scott's message I now understand.

Thank you.


From: Luke Howard <lukeh@padl.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: Nico Williams <nico@cryp= tonector.com>; Ryan Troll <rtroll@googlers.com>; "kitten@ietf.org" <kitten@ietf.org>; Simon Josefsson <simon@josefsson.org>
= Sent: Friday, August 31, 2= 012 5:51 PM
Subject: R= e: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth S= ASL draft -05

Bill,
On 01/09/2012, at 9:41 AM, William Mills <wmills@yahoo-inc.com> wrote:

As a subtext here you keep saying "don't = do that" to the use case where we need to have access to the user ID. =   That's a key part of the frustration here, you're not proposing a so= lution that solves the problem in all cases.  Evidently there's some g= ood reason for this.  I personally don't care about the case where the= gs2-header isn't present, but intellectually I want these things to be equ= ivalent.  

I understand your concern. I believ= e the answer is: in protocols that use GSS directly, the authorisation iden= tity equivalent is transmitted in the application protocol itself (for exam= ple SSH does this).

Now, of course there may be application protocols that use GSS directly and don't have such an equivalent. It's a = trade-off, because to introduce an authorisation identity directly into a G= S2 mechanism would result in this information being duplicated for the majo= rity case, and would break the abstraction (i.e. you couldn't implement OAu= th as a GSS mechanism and use it [with the appropriate bridge] with SASL). = Also, Ryan's requirement would only be satisfied for OAuth, rather than all= GS2 mechanisms (it seems less than ideal for a load-balancer to only work = with one particular security mechanism).

The alternative is t= o specify a SASL mechanism that doesn't fit the GS2 profile, which is fine.= But then you don't get GSS support, so you're back where you started. So m= y advice would be to accept this trade-off and specify it as a GS2 mechanis= m.

-- Luke


---551393103-1764189514-1346460964=:79308-- From internet-drafts@ietf.org Fri Aug 31 22:06:09 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324C011E80A6; Fri, 31 Aug 2012 22:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 eO2A1RW+DT1x; Fri, 31 Aug 2012 22:06:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3CC21F844C; Fri, 31 Aug 2012 22:06:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120901050600.16400.58667.idtracker@ietfa.amsl.com> Date: Fri, 31 Aug 2012 22:06:00 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-06.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 05:06:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. Title : A set of SASL and GSS-API Mechanisms for OAuth Author(s) : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-06.txt Pages : 29 Date : 2012-08-31 Abstract: OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) or the Generic Security Service Application Program Interface (GSS-API) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. Clients typically store the user's long term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a token. Tokens typically provided limited access rights and can be managed and revoked separately from the user's long-term credential (password). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wmills@yahoo-inc.com Fri Aug 31 22:08:38 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376BA21F848F for ; Fri, 31 Aug 2012 22:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.554 X-Spam-Level: X-Spam-Status: No, score=-17.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 1PLLGPZ42DLQ for ; Fri, 31 Aug 2012 22:08:37 -0700 (PDT) Received: from nm4-vm0.bullet.mail.sp2.yahoo.com (nm4-vm0.bullet.mail.sp2.yahoo.com [98.139.91.190]) by ietfa.amsl.com (Postfix) with SMTP id F188C21F8493 for ; Fri, 31 Aug 2012 22:08:36 -0700 (PDT) Received: from [98.139.91.66] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 01 Sep 2012 05:08:32 -0000 Received: from [98.139.91.43] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 01 Sep 2012 05:08:32 -0000 Received: from [127.0.0.1] by omp1043.mail.sp2.yahoo.com with NNFMP; 01 Sep 2012 05:08:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 313346.42827.bm@omp1043.mail.sp2.yahoo.com Received: (qmail 19815 invoked by uid 60001); 1 Sep 2012 05:08:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346476111; bh=iwy9ATMMf27MSgo0ZZ/wpC1j5uwSsDUkU7KE+2KVYeg=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YuaIox85sbH08m8/KU9I5LYgIhwLoQm07Ak+p5vPNTt/UuRI8YWx2Q5J5gOj5zfAvjEmi+gINeKV1/2Nkc8mNKVhxBrWePtR8Kq4dEFoUOW3vD0Ht2jVt8GWwy6zLbpOIRSip/XoGB2Ldc99p9gLfPCK5T+PJwrs2/VlmLsD8YY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OKWfrC1Xs+rW5hr1vsol7gTDVzqSAKfvZffAadE184JOfIcCiNIa36dI+OGwPup0VAQDMoLitJAc7S5jfdX+rtJCGQCaxQaGWeQ5RUXETCzNY+2ibBdJWlWuvkAa0t/FXac2ETau1sEQmdPlgFl+5AE0XSZPiEQ61/Btm9bO1U4=; X-YMail-OSG: IN0wNVkVM1luwSLh0b13s43Xsx6P8YfIOEDg2ilrhUAaI0S khkwdnIkoWGHOiH_W7P01gVRWAtpZexWjAhzo2NJd6gLpF.HwQbybeX4sUb9 L0I6cnP4xo7pJt9M0bOI_.50mIiYTzOHbswxQPHE5iDKkvBEbAhCwa1Q9Y.6 iVGTEtX04WjLvImgvsDWTMF65nEy1ivGLKLt30Zn2LHDZ4tjYoHRFkrjdeMA wpPu9Bb9.IuBqg4.e38VFwAGa5sCSOsdvUHJrzYlGFct3YaBBu4iWi7CQIiO O5zzWivHm5MGy_7npIlW_J2P6vnnbUQs7OX.D7TIKk3ArmtS2XqWigCg287z PrilagehSVHAJkPxUpHM_KzUiLKWjtXACAOvGEqSy1T9qNm4fg_bnIaM7xtV 9yNg23Bq2cMZ5jEVcnAQG5pWUdoL_gtlvA3LlXPDWV7sdXjOi4Xq6SfV6XJV tB1tfjiE- Received: from [209.131.62.115] by web31811.mail.mud.yahoo.com via HTTP; Fri, 31 Aug 2012 22:08:31 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346304940.59715.YahooMailNeo__3155.01940572194$1346304952$gmane$org@web31809.mail.mud.yahoo.com> <87fw742494.fsf@latte.josefsson.org> <1346339183.7746.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346340420.52884.YahooMailNeo@web31816.mail.mud.yahoo.com> <1346377509.19979.YahooMailNeo@web31811.mail.mud.yahoo.com> <1346392832.58517.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346423716.90231.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346425705.73062.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346427940.66948.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346428901.34367.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346456508.8798.YahooMailNeo ! @web31816.mail.mud.yahoo.com> <3008858F-8BF8-487F-B5EB-B3EB0D0BD35F@padl.com> <1346460964.79308.YahooMailNeo@web31805.mail.mud.yahoo.com> Message-ID: <1346476111.52370.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Fri, 31 Aug 2012 22:08:31 -0700 (PDT) From: William Mills To: William Mills , Luke Howard In-Reply-To: <1346460964.79308.YahooMailNeo@web31805.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-1540290007-1346476111=:52370" Cc: "kitten@ietf.org" , Simon Josefsson Subject: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 05:08:38 -0000 --764183289-1540290007-1346476111=:52370 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Draft -06 is posted.=A0 Ir removes the user field, adds canonicalization la= nguage, and once again fixes the examples to be current.=0A=0A-bill=0A=0A= =0A=0A=0A>________________________________=0A> From: William Mills =0A>To: Luke Howard =0A>Cc: "kitten@ietf.org= " ; Simon Josefsson =0A>Sent: Friday= , August 31, 2012 5:56 PM=0A>Subject: Re: [kitten] requirements/context/fru= stration Re: Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>=0A>OK, betwee= n this and Scott's message I now understand.=0A>=0A>Thank you.=0A>=0A>=0A>= =0A>=0A>=0A>=0A>>________________________________=0A>> From: Luke Howard =0A>>To: William Mills =0A>>Cc: Nico W= illiams ; Ryan Troll ; "kitten@= ietf.org" ; Simon Josefsson =0A>>Sen= t: Friday, August 31, 2012 5:51 PM=0A>>Subject: Re: [kitten] requirements/c= ontext/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05=0A>> =0A>>= =0A>>Bill,=0A>>=0A>>=0A>>On 01/09/2012, at 9:41 AM, William Mills wrote:=0A>>=0A>>As a subtext here you keep saying "don't do t= hat" to the use case where we need to have access to the user ID.=A0=A0 Tha= t's a key part of the frustration here, you're not proposing a solution tha= t solves the problem in all cases.=A0 Evidently there's some good reason fo= r this.=A0 I personally don't care about the case where the gs2-header isn'= t present, but intellectually I want these things to be equivalent.=A0=A0= =0A>>>=0A>>=0A>>=0A>>I understand your concern. I believe the answer is: in= protocols that use GSS directly, the authorisation identity equivalent is = transmitted in the application protocol itself (for example SSH does this).= =0A>>=0A>>=0A>>Now, of course there may be application protocols that use G= SS directly and don't have such an equivalent. It's a trade-off, because to= introduce an authorisation identity directly into a GS2 mechanism would re= sult in this information being duplicated for the majority case, and would = break the abstraction (i.e. you couldn't implement OAuth as a GSS mechanism= and use it [with the appropriate bridge] with SASL). Also, Ryan's requirem= ent would only be satisfied for OAuth, rather than all GS2 mechanisms (it s= eems less than ideal for a load-balancer to only work with one particular s= ecurity mechanism).=0A>>=0A>>=0A>>The alternative is to specify a SASL mech= anism that doesn't fit the GS2 profile, which is fine. But then you don't g= et GSS support, so you're back where you started. So my advice would be to = accept this trade-off and specify it as a GS2 mechanism.=0A>>=0A>>=0A>>-- L= uke=0A>>=0A>>=0A>_______________________________________________=0A>Kitten = mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/listinfo/ki= tten=0A>=0A>=0A> --764183289-1540290007-1346476111=:52370 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Draft -06 is posted.  Ir removes the user field, adds canonicalizati= on language, and once again fixes the examples to be current.
<= div style=3D"color: rgb(0, 0, 0); font-size: 18.6667px; font-family: Courie= r New,courier,monaco,monospace,sans-serif; background-color: transparent; f= ont-style: normal;">
-bill=

From: W= illiam Mills <wmills@yahoo-inc.com>
To: Luke Howard <lukeh@padl.com>
Cc: "kitten@ietf.org" <kitten@ietf.= org>; Simon Josefsson <simon@josefsson.org>
Sent: Friday, August 31, 2012 5:56 PM
<= b>Subject: Re: [kitten] requi= rements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05
=

OK, between this and Scott's message I now und= erstand.

Thank you.


<= font face=3D"Arial" size=3D"2">
From: Luke Howard <lukeh@padl.com>
To: William Mills <wmills@yahoo-= inc.com>
Cc: Nico Wi= lliams <nico@cryptonector.com>; Ryan Troll <rtroll@googlers.com>= ;; "kitten@ietf.org"=0A <kitten@ietf.org>; Simon Josefsson <simon@= josefsson.org>
Sent: Friday, August 31, 2012 5:51 PM
= Subject: Re: [kitten] requirements/context/frustration Re: Comma= vs. %x01 Re: OAuth SASL draft -05

Bill,

On 01/09/2012, at 9:41 AM, William Mi= lls <wmills@yahoo-inc.com&g= t; wrote:

As a= subtext here you keep saying "don't do that" to the use case where we need= to have access to the user ID.   That's a key part of the frustr= ation here, you're not proposing a solution that solves the problem in all = cases.  Evidently there's some good reason for this.  I personall= y don't care about the case where the gs2-header isn't present, but intelle= ctually I want these things to be equivalent.  
I understand your concern. I b= elieve the answer is: in protocols that use GSS directly, the authorisation= identity equivalent is transmitted in the application protocol itself (for= example SSH does this).

Now, of course there may be applicat= ion=0A protocols that use GSS directly and don't have such an equivalent. I= t's a trade-off, because to introduce an authorisation identity directly in= to a GS2 mechanism would result in this information being duplicated for th= e majority case, and would break the abstraction (i.e. you couldn't impleme= nt OAuth as a GSS mechanism and use it [with the appropriate bridge] with S= ASL). Also, Ryan's requirement would only be satisfied for OAuth, rather th= an all GS2 mechanisms (it seems less than ideal for a load-balancer to only= work with one particular security mechanism).

The alternativ= e is to specify a SASL mechanism that doesn't fit the GS2 profile, which is= fine. But then you don't get GSS support, so you're back where you started= . So my advice would be to accept this trade-off and specify it as a GS2 me= chanism.

-- Luke


_______________________________________________
Kitten mailing list
= Kitte= n@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

<= br> --764183289-1540290007-1346476111=:52370--
A new question in play, should the kv separator be converted= from %x01 to "," which makes it more compatible with the GS2 parsers out t= here?

I am not in favor of this, because one of the data elements to= be carried is the HTTP authentication header payload in which comma might = apprear, but control characters are not allowed.  I picked a control c= haracter specifically for this reason.

Regards,

-bill
---551393103-541554169-1345830537=:36750-- From nico@cryptonector.com Fri Aug 24 14:43:11 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97C821F8554 for ; Fri, 24 Aug 2012 14:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[AWL=-1.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 qU9xQUmPq3ZA for ; Fri, 24 Aug 2012 14:43:11 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2386121F8501 for ; Fri, 24 Aug 2012 14:43:11 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id A66D87E406F for ; Fri, 24 Aug 2012 14:43:10 -0700 (PDT) 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; s=cryptonector.com; bh=rTZwNU7f+dYfCqpUwiAn uiCIaJI=; b=oqfjcR8z7IbSmOcOd1kW7rsmp47OxWea07hOeMO3zOmxLV7UAYvV M4ZXjqd/vS+a8gKGL8ZtkB4lJ2RLSIC8Li1Sh7uMbUPP8hhrSFPtjC0cjtwcp3z+ eOys1KCJQ6sAGy0gAGhRSKz2MEAtOTNTswqENQLE9lendz5qat6V/8E= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 8C6F27E4065 for ; Fri, 24 Aug 2012 14:43:10 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4094057pbb.31 for ; Fri, 24 Aug 2012 14:43:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.34 with SMTP id ib2mr15257936pbc.164.1345844590105; Fri, 24 Aug 2012 14:43:10 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 24 Aug 2012 14:43:10 -0700 (PDT) In-Reply-To: <2F30A7A7-F364-44C3-893E-6590F9C63F6D@gmx.net> References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> <2F30A7A7-F364-44C3-893E-6590F9C63F6D@gmx.net> Date: Fri, 24 Aug 2012 16:43:10 -0500 Message-ID: From: Nico Williams To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 21:43:11 -0000 TLS w/ PKI is too a three party protocol. (Especially if CRLs are checked / OCSP is used.) There's quite a lot of duality between a symmetric key Needham-Schroeder type protocol (e.g., Kerberos) and PKI. Nico -- From nico@cryptonector.com Fri Aug 24 14:54:15 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FBE21F8613 for ; Fri, 24 Aug 2012 14:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[AWL=-1.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 FXS6YPMQKw9U for ; Fri, 24 Aug 2012 14:54:14 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 91C5421F8608 for ; Fri, 24 Aug 2012 14:54:14 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 53C8B77805B for ; Fri, 24 Aug 2012 14:54:14 -0700 (PDT) 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; s=cryptonector.com; bh=gYLjA2wDk32941NSLtsA zIAxs84=; b=U/CEMsq+HEuNWpJ8JMkTcQSiFcz+O50auZ25sVWGmNcPQtVd1EEF D5hei4MnLFxQQ3HZcZ3inxmOs3nkLSHemZ3oNuBkp4bL87ixsMszXIAq9MOlklXD tjCmCxQqoXVe0mRuEz+XnR/mplxb+Mn8qbqUJfUgo7gg7/ll4Jd7Fqw= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 3B14C778057 for ; Fri, 24 Aug 2012 14:54:14 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4105267pbb.31 for ; Fri, 24 Aug 2012 14:54:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.73 with SMTP id ra9mr15999781pbc.85.1345845253931; Fri, 24 Aug 2012 14:54:13 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 24 Aug 2012 14:54:13 -0700 (PDT) In-Reply-To: <3EC8A837-C13B-46AD-A349-DBF6774D494C@gmx.net> References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> <2F30A7A7-F364-44C3-893E-6590F9C63F6D@gmx.net> <50322FE7.6050803@secure-endpoints.com> <3EC8A837-C13B-46AD-A349-DBF6774D494C@gmx.net> Date: Fri, 24 Aug 2012 16:54:13 -0500 Message-ID: From: Nico Williams To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 21:54:15 -0000 On Mon, Aug 20, 2012 at 8:58 AM, Hannes Tschofenig wrote: > Interesting interpretation of TLS with respect to the parties. > > But I agree nevertheless that we agree on the channel binding issue. I have no problems with channel bindings for non-HTTP-based protocols. The whole point of channel binding to TLS in any protocol that uses TLS (including HTTPS) is to allow us to leverage whatever authentication of the server to the client might be provided by the authentication mechanism. This then makes up for weakness in the TLS server PKI (if it even gets used). Nico -- From lukeh@padl.com Sat Aug 25 01:20:11 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B465A21F8526 for ; Sat, 25 Aug 2012 01:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 yzGAi2Lupscj for ; Sat, 25 Aug 2012 01:20:09 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id A64F521F851B for ; Sat, 25 Aug 2012 01:20:08 -0700 (PDT) Received: by us.padl.com with ESMTP id q7P8JpTQ026455; Sat, 25 Aug 2012 04:19:53 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_0E8A1965-C0D9-4143-BE41-0458EB5A7EBC" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: <1345829385.29688.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Sat, 25 Aug 2012 18:19:59 +1000 Message-Id: <2AE97230-B6AD-415C-B54D-A99C4FAED802@padl.com> References: <87fw7cah2o.fsf@latte.josefsson.org> <1345829385.29688.YahooMailNeo@web31805.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 08:20:11 -0000 --Apple-Mail=_0E8A1965-C0D9-4143-BE41-0458EB5A7EBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 You shouldn't need a different OID for the -PLUS variant, this is = handled at the SASL layer. -- Luke On 25/08/2012, at 3:29 AM, William Mills wrote: > Updated to 3 OID's required, thank you. Is there a specific registry = process, or does the RFC editor take care of that? >=20 >=20 > From: Simon Josefsson > To: Hannes Tschofenig =20 > Cc: kitten@ietf.org=20 > Sent: Friday, August 24, 2012 12:23 AM > Subject: Re: [kitten] OAuth SASL draft -04 >=20 > I have a mild preference for trying this approach too. However, = doesn't > this suggest that there should be a separate OID for the GSS-API > mechanism side of each SASL mechanism? I think so. >=20 > Further, the -05 document just specify OAUTHBEARER, OAUTH10A, and > OAUTH10A-PLUS right now. >=20 > /Simon >=20 > Hannes Tschofenig writes: >=20 > > I think it is useful to have this list (CB and non-CB-based = variants) to > > avoid the trial-and-error approach. > > > > On 8/23/12 7:38 PM, "ext Ryan Troll" wrote: > > > >> No, I was alluding to a channel-binding enabled version of each = previous > >> token. For example "OAUTH2MAC", "OAUTH2MAC-PLUS", "OAUTH2BEARER", = and > >> "OAUTH2BEARER-PLUS", as draft -05 outlines. > >>=20 > >> -R > >>=20 > >> On Thu, Aug 23, 2012 at 2:20 AM, Alexey Melnikov = > >> wrote: > >>> =20 > >>> =20 > >>> On 22/08/2012 17:23, Ryan Troll wrote: > >>> =20 > >>> =20 > >>>> I vote for having separate mechanisms for OAUTH2MAC, = OAUTH2BEARER, > >>>> channel-binding versions, etc. > >>> Just to clarify: I hope you are not recommending to have a = separate OAUTH > >>> SASL mechanism for each channel binding type. That would make the = list of > >>> SASL mechanisms unmanageable. > >>> (Having separate mechanisms for MAC and BEARER seem to make = sense, IMHO. But > >>> no strong preferences.) > >>>=20 > >>> =20 > >>>> =20 > >>>> Negotiations within a SASL mechanism, which this is leading = towards, doesn't > >>>> sound good. By letting clients know exactly which tokens are = supported > >>>> up-front, clients are able to better choose, and understand the = implications > >>>> of those choices. > >>>> =20 > >>>>=20 > >>>> =20 > >>>> =20 > >>>> This should also allow us to remove the = error-message-in-server-challenge > >>>> and subsequent empty-client-challenge-response upon failure. > >>>> =20 > >>>>=20 > >>>> =20 > >>>> =20 > >>>> -R > >>>> =20 > >>>>=20 > >>>> =20 > >>>> =20 > >>>>=20 > >>>> =20 > >>>> On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott = wrote: > >>>> =20 > >>>>> =20 > >>>>> On 8/22/12 3:52 AM, "Hannes Tschofenig" = wrote: > >>>>> =20 > >>>>>> >That's inline with my thinking as well. > >>>>>> > > >>>>>> >And: I had also noticed the terminology issue; there is room = for wording > >>>>>> >changes here and there. > >>>>> =20 > >>>>> =20 > >>>>> There is, naturally, a similar issue in SAML-EC with the = subject > >>>>> confirmation being the determinant. I did build in some degree = of > >>>>> negotiation already, because some of it is inherited from the = HTTP use > >>>>> case on which the message exchange is inherited, but it does = have the > >>>>> problem that you have to dig into the exchange to know which = one is > >>>>> involved. > >>>>> =20 > >>>>> -- Scott > >>>>> =20 > >>>>> =20 > >>>>>=20 > >>>>> _______________________________________________ > >>>>> Kitten mailing list > >>>>> Kitten@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/kitten > >>>>> =20 > >>>>> =20 > >>>>> =20 > >>>> =20 > >>>> =20 > >>>> =20 > >>>> =20 > >>>> =20 > >>>> =20 > >>>> _______________________________________________ > >>>> Kitten mailing list > >>>> Kitten@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/kitten > >>>> =20 > >>> =20 > >>> =20 > >>> =20 > >>>=20 > >>> _______________________________________________ > >>> Kitten mailing list > >>> Kitten@ietf.org > >>> https://www.ietf.org/mailman/listinfo/kitten > >>>=20 > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> Kitten mailing list > >> Kitten@ietf.org > >> https://www.ietf.org/mailman/listinfo/kitten > > > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com --Apple-Mail=_0E8A1965-C0D9-4143-BE41-0458EB5A7EBC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 You = shouldn't need a different OID for the -PLUS variant, this is handled at = the SASL layer.

-- Luke

On = 25/08/2012, at 3:29 AM, William Mills <wmills@yahoo-inc.com> = wrote:

Updated to 3 OID's required, thank you.  Is = there a specific registry process, or does the RFC editor take care of = that?


=
=
From: = Simon Josefsson <simon@josefsson.org>
= To: Hannes Tschofenig = <Hannes.Tschofenig@nsn.com>= ;
Cc: kitten@ietf.org
Sent: Friday, August 24, 2012 = 12:23 AM
Subject: = Re: [kitten] OAuth SASL draft -04

I have a mild = preference for trying this approach too.  However, doesn't
this = suggest that there should be a separate OID for the GSS-API
mechanism = side of each SASL mechanism?  I think so.

Further, the -05 = document just specify OAUTHBEARER, OAUTH10A, and
OAUTH10A-PLUS right = now.

/Simon

Hannes Tschofenig <Hannes.Tschofenig@nsn.com>= ; writes:

> I think it is useful to have this list (CB and = non-CB-based variants) to
> avoid the trial-and-error = approach.
>
> On 8/23/12 7:38 PM, "ext Ryan Troll" <rtroll@googlers.com> wrote:
>
>> No, I was alluding to a channel-binding = enabled version of each previous
>> token.  For example = "OAUTH2MAC", "OAUTH2MAC-PLUS", "OAUTH2BEARER", and
>> = "OAUTH2BEARER-PLUS", as draft -05 outlines.
>>
>> = -R
>>
>> On Thu, Aug 23, 2012 at 2:20 AM, Alexey = Melnikov <alexey.melnikov@isode.com>= ;
>> wrote:
>>>    =
>>> 
>>> On 22/08/2012 17:23, Ryan Troll = wrote:
>>> 
>>> 
>>>> = I vote for having separate mechanisms for OAUTH2MAC, = OAUTH2BEARER,
>>>> channel-binding versions, = etc.
>>>  Just to clarify: I hope you are not = recommending to have a separate OAUTH
>>> SASL mechanism for = each channel binding type. That would make the list of
>>> SASL mechanisms unmanageable.
>>>  = (Having separate mechanisms for MAC and BEARER seem to make sense, IMHO. = But
>>> no strong preferences.)
>>> =
>>> 
>>>> 
>>>> = Negotiations within a SASL mechanism, which this is leading towards, = doesn't
>>>> sound good.  By letting clients know = exactly which tokens are supported
>>>> up-front, clients = are able to better choose, and understand the = implications
>>>> of those = choices.
>>>> 
>>>> =
>>>> 
>>>>  =
>>>> This should also allow us to remove the = error-message-in-server-challenge
>>>> and subsequent = empty-client-challenge-response upon failure.
>>>>  =
>>>>
>>>>  =
>>>> 
>>>> -R
>>>> 
>>>> =
>>>> 
>>>>  =
>>>>
>>>>  =
>>>>  On Wed, Aug 22, 2012 at 7:42 AM, Cantor, = Scott <cantor.2@osu.edu> = wrote:
>>>> 
>>>>>  =
>>>>> On 8/22/12 3:52 AM, "Hannes Tschofenig" <hannes.tschofenig@gmx.net>= ; wrote:
>>>>>  =
>>>>>>  >That's inline with my thinking as = well.
>>>>>>  = >
>>>>>>  >And: I had also noticed the = terminology issue; there is room for = wording
>>>>>>  >changes here and = there.
>>>>> 
>>>>> 
>>>>>  There is, = naturally, a similar issue in SAML-EC with the = subject
>>>>>  confirmation being the = determinant. I did build in some degree of
>>>>>  = negotiation already, because some of it is inherited from the HTTP = use
>>>>>  case on which the message exchange is = inherited, but it does have the
>>>>>  problem = that you have to dig into the exchange to know which one = is
>>>>>  involved.
>>>>>  =
>>>>>  -- Scott
>>>>>  =
>>>>> 
>>>>> =
>>>>>  = _______________________________________________
>>>>>&nb= sp; Kitten mailing list
>>>>>  Kitten@ietf.org
>>>>>= ;  https://www.ietf.org/mailman/listinfo/kitten
>= >>>> 
>>>>>  =
>>>>> 
>>>>  =
>>>> 
>>>>  =
>>>> 
>>>>  =
>>>> 
>>>> = _______________________________________________
>>>> = Kitten mailing list
>>>> Kitten@ietf.org
>>>> = https://www.ietf.org/mailman/listinfo/kitten
>= >>> 
>>> 
>>>  =
>>> 
>>>
>>> _______________________________________________
>>> Kitten = mailing list
>>> Kitten@ietf.org
>>> https://www.ietf.org/mailman/listinfo/kitten
>= >>
>>
>>
>>
>> = _______________________________________________
>> Kitten = mailing list
>> Kitten@ietf.org
>> https://www.ietf.org/mailman/listinfo/kitten
>=
> _______________________________________________
> Kitten = mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
____= ___________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

=
=
_______________________________________________
Kitten = mailing list
Kitten@ietf.org
https://www.ietf.or= g/mailman/listinfo/kitten


= --Apple-Mail=_0E8A1965-C0D9-4143-BE41-0458EB5A7EBC-- From wmills@yahoo-inc.com Sat Aug 25 13:29:31 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1835721F850B for ; Sat, 25 Aug 2012 13:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.554 X-Spam-Level: X-Spam-Status: No, score=-17.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 7yM2ZUJWuu04 for ; Sat, 25 Aug 2012 13:29:29 -0700 (PDT) Received: from nm8.bullet.mail.sp2.yahoo.com (nm8.bullet.mail.sp2.yahoo.com [98.139.91.78]) by ietfa.amsl.com (Postfix) with SMTP id CDBB121F8508 for ; Sat, 25 Aug 2012 13:29:29 -0700 (PDT) Received: from [98.139.91.61] by nm8.bullet.mail.sp2.yahoo.com with NNFMP; 25 Aug 2012 20:29:24 -0000 Received: from [98.139.91.19] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 25 Aug 2012 20:29:24 -0000 Received: from [127.0.0.1] by omp1019.mail.sp2.yahoo.com with NNFMP; 25 Aug 2012 20:29:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 602875.45942.bm@omp1019.mail.sp2.yahoo.com Received: (qmail 54693 invoked by uid 60001); 25 Aug 2012 20:29:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1345926563; bh=lWpE7SaACA4wGRlmHnKhMaFMzf8jb4Cu8yxVMlQ3VN0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Rg23nbpPfMwOyPVz8NmjUXOEv43qyOA16wENlSr4b5GzhFAV7lwdXdghMx2uT3TzfK0+cyCpl1jL+OaxPQLZm82pms7KcVWmlytk4OQIiW1EG/OwgwQXyGLiaV+N39B2Vl0Rcgugrd6Qf8jDRM/WDjD7ix6C2tR0ff6RYF8Eq8M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dR7LlRAwaRLRadUtbWe7Y4svr/PG5TM6cjmQnpLwzccTL1gWF+InXCIpELTqLjjXqNpgGuT7PVtzPaVp0JX8s6CT7+j+LY8AlB9C4e9caTVZvPtdmI+ViJD/7OOwvisVHHNPbT86/ncr6bH+cp5s837XIvSKfPfL9hFW7mPHvW8=; X-YMail-OSG: KTktzk0VM1mC6.ZrQc6FNxaK8yjkg_9IBKu7XrgdiKg0KQY LFNNTi7HWRd5C.PJ40hIxezOM5DjLpto_yMYDdaQt1YeSZLHn1E6Je7KKaZg FVNrj1stCfVoDfG0f5zbsfdfQV9Eir.CeRtCIJyhatPwC9XD9.Ibg6VZfwz2 kwTcJJGmfHQCUdegmlZTr0u2soWXpONyGjMs2pmPuKL7Eh7o_XHEOIQWNVpD dwgW6KalxkhT.vvwtgV0Sz0BmvevWIhO21Sm.u6zXLlvYQoF97aftHAKCCCA CdFP8pt_CVweJFCOVeatIyHKOVuwRIWAqGZpjbup2LuHUPujzzI2Cg_ZZ1hx 389IhvL7We6P70umPCwEBSfbytIHURv3MpBCC92HzI2cBMy5pxJF3OlDl0cN DtW85qKnh5bjTpveqPPqlXcgTiBGekA3m6FwSLIxtnUVNfXBU45LJEV.Zh1Q wyiEdnNFQDUkon9GAXtTghyLdJqoVccgr5H5W8y0Lkp1gRSGMjZhV23.7ofF RkuH0Hm_BV573M6ssSJKxuZauk4KNJ98- Received: from [99.31.212.42] by web31805.mail.mud.yahoo.com via HTTP; Sat, 25 Aug 2012 13:29:23 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <87fw7cah2o.fsf@latte.josefsson.org> <1345829385.29688.YahooMailNeo@web31805.mail.mud.yahoo.com> <2AE97230-B6AD-415C-B54D-A99C4FAED802@padl.com> Message-ID: <1345926563.70286.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Sat, 25 Aug 2012 13:29:23 -0700 (PDT) From: William Mills To: Luke Howard In-Reply-To: <2AE97230-B6AD-415C-B54D-A99C4FAED802@padl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-639144105-1345926563=:70286" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] OAuth SASL draft -04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 20:29:31 -0000 ---551393103-639144105-1345926563=:70286 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OK, thank you.=A0 Corrected.=0A=0A=0A=0A=0A=0A>____________________________= ____=0A> From: Luke Howard =0A>To: William Mills =0A>Cc: Simon Josefsson ; Hannes Tschofen= ig ; "kitten@ietf.org" =0A>Sen= t: Saturday, August 25, 2012 1:19 AM=0A>Subject: Re: [kitten] OAuth SASL dr= aft -04=0A> =0A>=0A>You shouldn't need a different OID for the -PLUS varian= t, this is handled at the SASL layer.=0A>=0A>=0A>-- Luke=0A>=0A>=0A>On 25/0= 8/2012, at 3:29 AM, William Mills wrote:=0A>=0A>Upda= ted to 3 OID's required, thank you.=A0 Is there a specific registry process= , or does the RFC editor take care of that?=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>= =0A>>>________________________________=0A>>> From: Simon Josefsson =0A>>>To: Hannes Tschofenig =0A>>>= Cc: kitten@ietf.org =0A>>>Sent: Friday, August 24, 2012 12:23 AM=0A>>>Subje= ct: Re: [kitten] OAuth SASL draft -04=0A>>> =0A>>>I have a mild preference = for trying this approach too.=A0 However, doesn't=0A>>>this suggest that th= ere should be a separate OID for the GSS-API=0A>>>mechanism side of each SA= SL mechanism?=A0 I think so.=0A>>>=0A>>>Further, the -05 document just spec= ify OAUTHBEARER, OAUTH10A, and=0A>>>OAUTH10A-PLUS right now.=0A>>>=0A>>>/Si= mon=0A>>>=0A>>>Hannes Tschofenig writes:=0A>>>= =0A>>>> I think it is useful to have this list (CB and non-CB-based variant= s) to=0A>>>> avoid the trial-and-error approach.=0A>>>>=0A>>>> On 8/23/12 7= :38 PM, "ext Ryan Troll" wrote:=0A>>>>=0A>>>>> No, I = was alluding to a channel-binding enabled version of each previous=0A>>>>> = token. =A0For example "OAUTH2MAC", "OAUTH2MAC-PLUS", "OAUTH2BEARER", and=0A= >>>>> "OAUTH2BEARER-PLUS", as draft -05 outlines.=0A>>>>> =0A>>>>> -R=0A>>>= >> =0A>>>>> On Thu, Aug 23, 2012 at 2:20 AM, Alexey Melnikov =0A>>>>> wrote:=0A>>>>>>=A0 =A0 =0A>>>>>>=A0 =0A>>>>>> On 22/0= 8/2012 17:23, Ryan Troll wrote:=0A>>>>>>=A0 =0A>>>>>>=A0 =0A>>>>>>> I vote = for having separate mechanisms for OAUTH2MAC, OAUTH2BEARER,=0A>>>>>>> chann= el-binding versions, etc.=0A>>>>>>=A0 Just to clarify: I hope you are not r= ecommending to have a separate OAUTH=0A>>>>>> SASL mechanism for each chann= el binding type. That would make the list=0A of=0A>>>>>> SASL mechanisms un= manageable.=0A>>>>>>=A0 (Having separate mechanisms for MAC and BEARER seem= to make sense, IMHO. But=0A>>>>>> no strong preferences.)=0A>>>>>> =0A>>>>= >>=A0 =0A>>>>>>>=A0 =0A>>>>>>> Negotiations within a SASL mechanism, which = this is leading towards, doesn't=0A>>>>>>> sound good. =A0By letting client= s know exactly which tokens are supported=0A>>>>>>> up-front, clients are a= ble to better choose, and understand the implications=0A>>>>>>> of those ch= oices.=0A>>>>>>>=A0 =0A>>>>>>> =0A>>>>>>>=A0 =0A>>>>>>>=A0 =0A>>>>>>> This = should also allow us to remove the error-message-in-server-challenge=0A>>>>= >>> and subsequent empty-client-challenge-response upon failure.=0A>>>>>>>= =A0 =0A>>>>>>> =0A>>>>>>>=A0 =0A>>>>>>>=A0 =0A>>>>>>> -R=0A>>>>>>>=A0 =0A>>= >>>>> =0A>>>>>>>=A0 =0A>>>>>>>=A0 =0A>>>>>>> =0A>>>>>>>=A0 =0A>>>>>>>=A0 On= Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott wrote:=0A>>= >>>>>=A0 =0A>>>>>>>>=A0 =0A>>>>>>>> On 8/22/12 3:52 AM, "Hannes Tschofenig"= wrote:=0A>>>>>>>>=A0 =0A>>>>>>>>>=A0 >That's i= nline with my thinking as well.=0A>>>>>>>>>=A0 >=0A>>>>>>>>>=A0 >And: I had= also noticed the terminology issue; there is room for wording=0A>>>>>>>>>= =A0 >changes here and there.=0A>>>>>>>>=A0 =0A>>>>>>>>=A0 =0A>>>>>>>>=A0 Th= ere is, naturally, a similar issue in SAML-EC with the subject=0A>>>>>>>>= =A0 confirmation being the determinant. I did build in some degree of=0A>>>= >>>>>=A0 negotiation already, because some of it is inherited from the HTTP= use=0A>>>>>>>>=A0 case on which the message exchange is inherited, but it = does have the=0A>>>>>>>>=A0 problem that you have to dig into the exchange = to know which one is=0A>>>>>>>>=A0 involved.=0A>>>>>>>>=A0 =0A>>>>>>>>=A0 -= - Scott=0A>>>>>>>>=A0 =0A>>>>>>>>=A0 =0A>>>>>>>> =0A>>>>>>>>=A0 ___________= ____________________________________=0A>>>>>>>>=A0 Kitten mailing list=0A>>= >>>>>>=A0 Kitten@ietf.org=0A>>>>>>>>=A0 https://www.ietf.org/mailman/listin= fo/kitten=0A>>>>>>>>=A0 =0A>>>>>>>>=A0 =0A>>>>>>>>=A0 =0A>>>>>>>=A0 =0A>>>>= >>>=A0 =0A>>>>>>>=A0 =0A>>>>>>>=A0 =0A>>>>>>>=A0 =0A>>>>>>>=A0 =0A>>>>>>> _= ______________________________________________=0A>>>>>>> Kitten mailing lis= t=0A>>>>>>> Kitten@ietf.org=0A>>>>>>> https://www.ietf.org/mailman/listinfo= /kitten=0A>>>>>>>=A0 =0A>>>>>>=A0 =0A>>>>>>=A0 =0A>>>>>>=A0 =0A>>>>>> =0A>>= >>>>=0A _______________________________________________=0A>>>>>> Kitten mai= ling list=0A>>>>>> Kitten@ietf.org=0A>>>>>> https://www.ietf.org/mailman/li= stinfo/kitten=0A>>>>>> =0A>>>>> =0A>>>>> =0A>>>>> =0A>>>>> ________________= _______________________________=0A>>>>> Kitten mailing list=0A>>>>> Kitten@= ietf.org=0A>>>>> https://www.ietf.org/mailman/listinfo/kitten=0A>>>>=0A>>>>= _______________________________________________=0A>>>> Kitten mailing list= =0A>>>> Kitten@ietf.org=0A>>>> https://www.ietf.org/mailman/listinfo/kitten= =0A>>>_______________________________________________=0A>>>Kitten mailing l= ist=0A>>>Kitten@ietf.org=0A>>>https://www.ietf.org/mailman/listinfo/kitten= =0A>>>=0A>>>=0A>>>_______________________________________________=0A>>Kitte= n mailing list=0A>>Kitten@ietf.org=0A>>https://www.ietf.org/mailman/listinf= o/kitten=0A>>=0A>=0A>--=0A>Luke Howard /=A0lukeh@padl.com=0A>www.padl.com /= www.lukehoward.com =0A>=0A>=0A> ---551393103-639144105-1345926563=:70286 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OK, thank= you.  Corrected.

From: Luke Howard <lukeh@padl.com>
= To: William Mills <wmil= ls@yahoo-inc.com>
Cc: Simon Josefsson <simon@josefsson.org>; Hannes Tschofenig <Hanne= s.Tschofenig@nsn.com>; "kitten@ietf.org" <kitten@ietf.org>
Sent: Saturday, August 25, 2012 1:= 19 AM
Subject: Re: [ki= tten] OAuth SASL draft -04

=
You shouldn't need a different OID for the -PLUS variant, this is hand= led at the SASL layer.

-- Luke

O= n 25/08/2012, at 3:29 AM, William Mills <wmills@yahoo-inc.com> wrote:

Updated to 3 OID's required, thank= you.  Is there a specific registry process, or does the RFC editor ta= ke care of that?


<= font face=3D"Arial" size=3D"2">
From: Simon Josefsson <simon@josefsson.org>
To: Hannes Tschofenig <Hannes.Tschofenig@nsn.com>
Cc: kitten@ietf.o= rg
Sent: Friday, August 24, 2012 12:23= AM
Subject: Re: [kitte= n] OAuth SASL draft -04

I have a mild preference for= trying this approach too.  However, doesn't
this suggest that ther= e should be a separate OID for the GSS-API
mechanism side of each SASL m= echanism?  I think so.

Further, the -05 document just specify O= AUTHBEARER, OAUTH10A, and
OAUTH10A-PLUS right now.

/Simon

= Hannes Tschofenig <Han= nes.Tschofenig@nsn.com> writes:

> I think it is useful to = have this list (CB and non-CB-based variants) to
> avoid the trial-an= d-error approach.
>
> On 8/23/12 7:38 PM, "ext Ryan Troll" <= rtroll@googlers.com>=0A wrote:<= br>>
>> No, I was alluding to a channel-binding enabled version= of each previous
>> token.  For example "OAUTH2MAC", "OAUTH2= MAC-PLUS", "OAUTH2BEARER", and
>> "OAUTH2BEARER-PLUS", as draft -0= 5 outlines.
>>
>> -R
>>
>> On Thu, Au= g 23, 2012 at 2:20 AM, Alexey Melnikov <alexey.melnikov@isode.com>
>> wrote:
&= gt;>>   
>>> 
>>> On 22/08/= 2012 17:23, Ryan Troll wrote:
>>> 
>>>  =
>>>> I vote for having separate mechanisms for OAUTH2MAC, O= AUTH2BEARER,
>>>> channel-binding versions, etc.
>>= >  Just to clarify: I hope you are not recommending to have a separ= ate OAUTH
>>> SASL mechanism for each channel binding type. That would make the list=0A of
>>> SASL mechanisms unman= ageable.
>>>  (Having separate mechanisms for MAC and BEAR= ER seem to make sense, IMHO. But
>>> no strong preferences.)>>>
>>> 
>>>> 
>>= ;>> Negotiations within a SASL mechanism, which this is leading towar= ds, doesn't
>>>> sound good.  By letting clients know e= xactly which tokens are supported
>>>> up-front, clients are= able to better choose, and understand the implications
>>>>= of those choices.
>>>> 
>>>>
>&= gt;>> 
>>>> 
>>>> This shou= ld also allow us to remove the error-message-in-server-challenge
>>= ;>> and subsequent empty-client-challenge-response upon failure.
&= gt;>>> 
>>>>
>>>> 
&= gt;>>> =0A
>>>> -R
>>>>  =
>>>>
>>>> 
>>>>  =
>>>>
>>>> 
>>>>  = On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott <cantor.2@osu.edu> wrote:
>>>> 
>&= gt;>>> 
>>>>> On 8/22/12 3:52 AM, "Hannes = Tschofenig" <hannes.ts= chofenig@gmx.net> wrote:
>>>>> 
>>&= gt;>>>  >That's inline with my thinking as well.
>&g= t;>>>>  >
>>>>>>  >And: I = had also noticed the terminology issue; there is room for wording
>&g= t;>>>>  >changes here and there.
>>>>> =0A
>>&= gt;>> 
>>>>>  There is, naturally, a sim= ilar issue in SAML-EC with the subject
>>>>>  confir= mation being the determinant. I did build in some degree of
>>>= >>  negotiation already, because some of it is inherited from th= e HTTP use
>>>>>  case on which the message exchange= is inherited, but it does have the
>>>>>  problem t= hat you have to dig into the exchange to know which one is
>>>&= gt;>  involved.
>>>>> 
>>>>&= gt;  -- Scott
>>>>> 
>>>>>&= nbsp;
>>>>>
>>>>>  _____________= __________________________________
>>>>>  Kitten mai= ling list
>>>>>  Kitten@ietf.org
>>>>>= ;  https://www.ietf.org/mailman/listinfo/kitten>>>>> 
>>>>> 
>>>= ;>> 
>>>> 
>>>> 
&= gt;>>> 
>>>> 
>>>> =
>>>> 
>>>> _________________________= ______________________
>>>> Kitten mailing list
>>&= gt;> Kitten@ietf.org
>>>&g= t; https://www.ietf.org/mailman/listinfo/kitten
>= ;>>> 
>>> 
>>> 
>&= gt;> 
>>>
>>>=0A _____________________________________= __________
>>> Kitten mailing list
>>> Kitten@ietf.org
>>> http= s://www.ietf.org/mailman/listinfo/kitten
>>>
>> <= br>>>
>>
>> _____________________________________= __________
>> Kitten mailing list
>> Kitten@ietf.org
>> https://www.ietf= .org/mailman/listinfo/kitten
>
> __________________________= _____________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
____________________= ___________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mail= man/listinfo/kitten


_______________________________________________
Kitten mailing = list
Kitten@ietf.org
https://www.ie= tf.org/mailman/listinfo/kitten

=0A


---551393103-639144105-1345926563=:70286-- From simon@josefsson.org Sun Aug 26 09:33:00 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C63221F851B for ; Sun, 26 Aug 2012 09:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.843 X-Spam-Level: X-Spam-Status: No, score=-99.843 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 QhZMFSHJOdGv for ; Sun, 26 Aug 2012 09:33:00 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 951F121F84F1 for ; Sun, 26 Aug 2012 09:32:58 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7QGWq8g005157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Aug 2012 18:32:53 +0200 From: Simon Josefsson To: William Mills References: <87fw7cah2o.fsf@latte.josefsson.org> <1345829385.29688.YahooMailNeo@web31805.mail.mud.yahoo.com> <1345830537.36750.YahooMailNeo__11890.3699367822$1345830549$gmane$org@web31805.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120826:wmills@yahoo-inc.com::US8sLGA+pwecHRk1:01mk X-Hashcash: 1:22:120826:kitten@ietf.org::/coUM4+mPPXpcPyI:OfBs Date: Sun, 26 Aug 2012 18:32:51 +0200 In-Reply-To: <1345830537.36750.YahooMailNeo__11890.3699367822$1345830549$gmane$org@web31805.mail.mud.yahoo.com> (William Mills's message of "Fri, 24 Aug 2012 10:48:57 -0700 (PDT)") Message-ID: <87bohxliks.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 16:33:00 -0000 William Mills writes: > A new question in play, should the kv separator be converted from %x01 > to "," which makes it more compatible with the GS2 parsers out there? > > I am not in favor of this, because one of the data elements to be > carried is the HTTP authentication header payload in which comma might > apprear, but control characters are not allowed.  I picked a control > character specifically for this reason. If using "," would make a large percentage of typical exchanges contain an escaped "," (i.e., "=2C") then I share your concern with ",". However, if it is just occasional that the payload contains "," I think using "," is simpler -- remember that you need to implement the "," escaping stuff anyway due to the gs2-header. So you will have the code present in your application anyway. /Simon From simon@josefsson.org Sun Aug 26 09:38:58 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAE921F84FA for ; Sun, 26 Aug 2012 09:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.845 X-Spam-Level: X-Spam-Status: No, score=-99.845 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 mWtl4Zqnn3tA for ; Sun, 26 Aug 2012 09:38:58 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id AF4F121F84A2 for ; Sun, 26 Aug 2012 09:38:57 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7QGcjDl005386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Aug 2012 18:38:47 +0200 From: Simon Josefsson To: Nico Williams References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> <2F30A7A7-F364-44C3-893E-6590F9C63F6D@gmx.net> <50322FE7.6050803@secure-endpoints.com> <3EC8A837-C13B-46AD-A349-DBF6774D494C@gmx.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120826:hannes.tschofenig@gmx.net::o1KEYPZKzyj0WYTX:3YDj X-Hashcash: 1:22:120826:kitten@ietf.org::PPY0MMqxCHRxn7Kw:OKML X-Hashcash: 1:22:120826:nico@cryptonector.com::QFHIt9l1bGZ4COVR:NSUj Date: Sun, 26 Aug 2012 18:38:45 +0200 In-Reply-To: (Nico Williams's message of "Fri, 24 Aug 2012 16:54:13 -0500") Message-ID: <877gslliay.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 16:38:58 -0000 Nico Williams writes: > On Mon, Aug 20, 2012 at 8:58 AM, Hannes Tschofenig > wrote: >> Interesting interpretation of TLS with respect to the parties. >> >> But I agree nevertheless that we agree on the channel binding >> issue. I have no problems with channel bindings for non-HTTP-based >> protocols. > > The whole point of channel binding to TLS in any protocol that uses > TLS (including HTTPS) is to allow us to leverage whatever > authentication of the server to the client might be provided by the > authentication mechanism. This then makes up for weakness in the TLS > server PKI (if it even gets used). However, doesn't it works both ways? If the TLS server PKI happens to work, but the authentication mechanism is weak or prone to certain attacks, having a channel binding might strengthen the solution. Of course, it depends on whether the authentication mechanism would detect a channel binding mismatch. /Simon From wmills@yahoo-inc.com Sun Aug 26 10:31:44 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D3421F84F3 for ; Sun, 26 Aug 2012 10:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.56 X-Spam-Level: X-Spam-Status: No, score=-17.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 HiiSH7+NjZer for ; Sun, 26 Aug 2012 10:31:44 -0700 (PDT) Received: from nm32-vm4.bullet.mail.ne1.yahoo.com (nm32-vm4.bullet.mail.ne1.yahoo.com [98.138.229.52]) by ietfa.amsl.com (Postfix) with SMTP id 09B3121F84A2 for ; Sun, 26 Aug 2012 10:31:43 -0700 (PDT) Received: from [98.138.90.55] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 26 Aug 2012 17:31:39 -0000 Received: from [98.138.89.234] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 26 Aug 2012 17:31:39 -0000 Received: from [127.0.0.1] by omp1049.mail.ne1.yahoo.com with NNFMP; 26 Aug 2012 17:31:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 995113.23746.bm@omp1049.mail.ne1.yahoo.com Received: (qmail 61450 invoked by uid 60001); 26 Aug 2012 17:31:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346002298; bh=8HZppk+jOCIKwq3hH2KwFtinzY6SAqXRaWf264uxT98=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=m6n6bCkXLm643ruKd7OhJbdsCjx2Xnrhs2cpi7fFk2IpNGy98sODM1waQ6gIPyfwQQ4w5uRWtVJ9yaUYQHJ/nE/hKuO3WT2RbjEhw1PwOkZAxpl5CtKioS31W5ZueVr6yhCyHg+wfztTKj/V7iJwj8v/DdgOroIZyPpH3L+la2g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=n5Zj4zurldJI/oQyvk5obVtJKkLIirTarYy54HbS4mjaSzuHmOpkUu9u+z6zlkqZ5QyUvqWmRCXTmSi0uiau33pd1J/zIErK7/OR/tBiMCnfcix0CyJ10yX9lttIQlJO3o1W3TuStW1AzHexICtM7svSFFeIZnwfyQqSIn701S4=; X-YMail-OSG: tOAccZwVM1mQC8I_yFTeUzsFdR4Z7pB.O9Wzg4k0FNy.ZWn H75GQ8NemUctI0B.uXpqlxRa_PaAyYzlmFm1EW124q0OcWBWaXIyGCyNgJxH Y15BqR_tndWQ0OcJTVyp2c82rhtw8_V8OMNGaCRoou._HUXg_vKBekrk.O_o AMQRO7telytRkTrSauruaU3IOzmEZUo3bJ.Z0hfn38uckg7CzS_Jf2sbUvHo HSitdCnUDgTuboL7U8NgEAdi3b3OnEH2hGsPIgQbzjwgBSTowO9bcOrb2l3n H2umW7WZQ8dh7j6GZbxtwjb_TqdjNO_op7Wt_RTk3LE5F9CtbLSSF6pxdxf2 NQag5vc0r5koKjwpWYGsD2WBANfCyyDfUqc12DXBcGkhe8TOXXFJXEj6AwjW mhjHcHmu2hs0vJWdTaKXAJFUyKrPQEaCuUbmhiHKRgWEjHWSBkrzrdLWmOfe 8SIwiKQ-- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Sun, 26 Aug 2012 10:31:38 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <87fw7cah2o.fsf@latte.josefsson.org> <1345829385.29688.YahooMailNeo@web31805.mail.mud.yahoo.com> <1345830537.36750.YahooMailNeo__11890.3699367822$1345830549$gmane$org@web31805.mail.mud.yahoo.com> <87bohxliks.fsf@latte.josefsson.org> Message-ID: <1346002298.36826.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Sun, 26 Aug 2012 10:31:38 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87bohxliks.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-202942069-1346002298=:36826" Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 17:31:45 -0000 --767760015-202942069-1346002298=:36826 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The way it is now I don't think we need comma escaping unless it's actually= GS2 enabled and you're in the gs2-header.=A0 I can scan past the gs2-heade= r looking for the first %x01 and I'm off to the SASL processing.=A0 If I ha= ve to define comma escaping that is a significant change.=0A=0A=0A=0A=0A>__= ______________________________=0A> From: Simon Josefsson =0A>To: William Mills =0A>Cc: "kitten@ietf.org" <= kitten@ietf.org> =0A>Sent: Sunday, August 26, 2012 9:32 AM=0A>Subject: Re: = Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>William Mills writes:=0A>=0A>> A new question in play, should the kv separato= r be converted from %x01=0A>> to "," which makes it more compatible with th= e GS2 parsers out there?=0A>>=0A>> I am not in favor of this, because one o= f the data elements to be=0A>> carried is the HTTP authentication header pa= yload in which comma might=0A>> apprear, but control characters are not all= owed.=A0 I picked a control=0A>> character specifically for this reason.=0A= >=0A>If using "," would make a large percentage of typical exchanges contai= n=0A>an escaped "," (i.e., "=3D2C") then I share your concern with ",".=0A>= =0A>However, if it is just occasional that the payload contains "," I think= =0A>using "," is simpler -- remember that you need to implement the ","=0A>= escaping stuff anyway due to the gs2-header.=A0 So you will have the code= =0A>present in your application anyway.=0A>=0A>/Simon=0A>=0A>=0A> --767760015-202942069-1346002298=:36826 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The way it is now I don't think we need comma escaping un= less it's actually GS2 enabled and you're in the gs2-header.  I can sc= an past the gs2-header looking for the first %x01 and I'm off to the SASL p= rocessing.  If I have to define comma escaping that is a significant c= hange.

=
From: Simon Josefsson <simon@josefsson.org>
To: William Mills <wmills@yahoo-inc.com&g= t;
Cc: "kitten@ietf.or= g" <kitten@ietf.org>
Sent:= Sunday, August 26, 2012 9:32 AM
Subject: Re: Comma vs. %x01 Re: OAuth SASL draft -0= 5

William Mills <wmills@yahoo-inc.com>= ; writes:

> A new question in play, should the kv separator be co= nverted from %x01
> to "," which makes it more compatible with the GS= 2 parsers out there?
>
> I am not in favor of this, because one= of the data elements to be
> carried is the HTTP authentication head= er payload in which comma might
> apprear, but control characters are not allow= ed.  I picked a control
> character specifically for this reason= .

If using "," would make a large percentage of typical exchanges co= ntain
an escaped "," (i.e., "=3D2C") then I share your concern with ",".=

However, if it is just occasional that the payload contains "," I t= hink
using "," is simpler -- remember that you need to implement the ","=
escaping stuff anyway due to the gs2-header.  So you will have the= code
present in your application anyway.

/Simon


--767760015-202942069-1346002298=:36826-- From simon@josefsson.org Sun Aug 26 14:40:13 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD33321F8595 for ; Sun, 26 Aug 2012 14:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.847 X-Spam-Level: X-Spam-Status: No, score=-99.847 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 LsA9pTlCkXYu for ; Sun, 26 Aug 2012 14:40:13 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id F001921F8594 for ; Sun, 26 Aug 2012 14:40:12 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7QLe5fE018801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Aug 2012 23:40:06 +0200 From: Simon Josefsson To: William Mills References: <87fw7cah2o.fsf@latte.josefsson.org> <1345829385.29688.YahooMailNeo@web31805.mail.mud.yahoo.com> <1345830537.36750.YahooMailNeo__11890.3699367822$1345830549$gmane$org@web31805.mail.mud.yahoo.com> <87bohxliks.fsf@latte.josefsson.org> <1346002298.36826.YahooMailNeo__27246.2187720977$1346002314$gmane$org@web31813.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120826:kitten@ietf.org::66EVoh9c1FmQx0WF:7Xe0 X-Hashcash: 1:22:120826:wmills@yahoo-inc.com::NcwDPxJUhLXNWza9:eKdK Date: Sun, 26 Aug 2012 23:40:05 +0200 In-Reply-To: <1346002298.36826.YahooMailNeo__27246.2187720977$1346002314$gmane$org@web31813.mail.mud.yahoo.com> (William Mills's message of "Sun, 26 Aug 2012 10:31:38 -0700 (PDT)") Message-ID: <873939l4cq.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 21:40:14 -0000 William Mills writes: > The way it is now I don't think we need comma escaping unless it's > actually GS2 enabled and you're in the gs2-header. The SASL mechanism side should always be "GS2 enabled" (if you mean use the gs2-header). >   I can scan past the gs2-header looking for the first %x01 and I'm > off to the SASL processing.  If I have to define comma escaping that > is a significant change. You need to parse the gs2-header to find the channel binding type and authorization identity, so I believe a gs2-header parser is needed if you want compatibility with GS2 and a GSS-API mechanism. I don't believe it is difficult to implement. There is plenty of code around that you can look at and use. /Simon > > > > >>________________________________ >> From: Simon Josefsson >>To: William Mills >>Cc: "kitten@ietf.org" >>Sent: Sunday, August 26, 2012 9:32 AM >>Subject: Re: Comma vs. %x01 Re: OAuth SASL draft -05 >> >>William Mills writes: >> >>> A new question in play, should the kv separator be converted from %x01 >>> to "," which makes it more compatible with the GS2 parsers out there? >>> >>> I am not in favor of this, because one of the data elements to be >>> carried is the HTTP authentication header payload in which comma might >>> apprear, but control characters are not allowed.  I picked a control >>> character specifically for this reason. >> >>If using "," would make a large percentage of typical exchanges contain >>an escaped "," (i.e., "=2C") then I share your concern with ",". >> >>However, if it is just occasional that the payload contains "," I think >>using "," is simpler -- remember that you need to implement the "," >>escaping stuff anyway due to the gs2-header.  So you will have the code >>present in your application anyway. >> >>/Simon >> >> >> > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nico@cryptonector.com Sun Aug 26 15:21:41 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F02F21F857D for ; Sun, 26 Aug 2012 15:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.037 X-Spam-Level: X-Spam-Status: No, score=-3.037 tagged_above=-999 required=5 tests=[AWL=-1.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 qKDJd94WwFQO for ; Sun, 26 Aug 2012 15:21:41 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0D90721F84FB for ; Sun, 26 Aug 2012 15:21:41 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id CF3F8428079 for ; Sun, 26 Aug 2012 15:21:40 -0700 (PDT) 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; s=cryptonector.com; bh=0uqqCwJFwdtF5On/0c3Q dPEnhbc=; b=Rq54UGXbMhgr+qWCztdV49lWPQZFy5DaU7SYVYN7+veRldxRb4RP olLN6/Vw+jZMhx1mOV9jetOwG6zkPNz7lPuQnIZ78jIca7Jf7tzWp6HpU1rs3Yxi zsPAgVUauYwhyOq62mvqskaBh6m7eQRZ8Kwei+1QrZxPAyx7qeDxDC8= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id B62D5428076 for ; Sun, 26 Aug 2012 15:21:40 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so6243606pbb.31 for ; Sun, 26 Aug 2012 15:21:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.87.227 with SMTP id bb3mr26167384pab.3.1346019700201; Sun, 26 Aug 2012 15:21:40 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Sun, 26 Aug 2012 15:21:40 -0700 (PDT) In-Reply-To: <877gslliay.fsf@latte.josefsson.org> References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> <2F30A7A7-F364-44C3-893E-6590F9C63F6D@gmx.net> <50322FE7.6050803@secure-endpoints.com> <3EC8A837-C13B-46AD-A349-DBF6774D494C@gmx.net> <877gslliay.fsf@latte.josefsson.org> Date: Sun, 26 Aug 2012 17:21:40 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 22:21:41 -0000 On Sun, Aug 26, 2012 at 11:38 AM, Simon Josefsson wrote: > Nico Williams writes: >> The whole point of channel binding to TLS in any protocol that uses >> TLS (including HTTPS) is to allow us to leverage whatever >> authentication of the server to the client might be provided by the >> authentication mechanism. This then makes up for weakness in the TLS >> server PKI (if it even gets used). > > However, doesn't it works both ways? If the TLS server PKI happens to > work, but the authentication mechanism is weak or prone to certain > attacks, having a channel binding might strengthen the solution. Of > course, it depends on whether the authentication mechanism would detect > a channel binding mismatch. Kurt Zeilenga proposed a SCRAM-like mechanism that depends on the use of tls-unique CB, using the CB data as the challenge, thereby shaving a round trip. So, yes, it's definitely possible to use CB to strengthen a mechanism, but note that if server authentication in TLS is weak or non-existent (e.g., because an anon DH cipher suite was used) then the mechanism is not strengthened vis-a-vis active attacks. So the benefit of CB isn't entirely symmetric, no. Nico -- From wmills@yahoo-inc.com Sun Aug 26 16:03:09 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DEF21F847A for ; Sun, 26 Aug 2012 16:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.561 X-Spam-Level: X-Spam-Status: No, score=-17.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 U741vMsNSpuY for ; Sun, 26 Aug 2012 16:03:08 -0700 (PDT) Received: from nm5.bullet.mail.ac4.yahoo.com (nm5.bullet.mail.ac4.yahoo.com [98.139.52.202]) by ietfa.amsl.com (Postfix) with SMTP id 2EBCB21F8468 for ; Sun, 26 Aug 2012 16:03:08 -0700 (PDT) Received: from [98.139.52.192] by nm5.bullet.mail.ac4.yahoo.com with NNFMP; 26 Aug 2012 23:03:03 -0000 Received: from [98.139.52.175] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 26 Aug 2012 23:03:03 -0000 Received: from [127.0.0.1] by omp1058.mail.ac4.yahoo.com with NNFMP; 26 Aug 2012 23:03:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 547782.50533.bm@omp1058.mail.ac4.yahoo.com Received: (qmail 98914 invoked by uid 60001); 26 Aug 2012 23:03:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346022183; bh=oPD8HdtPmaFyuGJPjIa4HwrB/GUv9yH1IeXMtKD8rMA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qAPEs4kz8+15v1pkAHZi7tMBiDHW9lmkxiIpG35s9eG99YJIjiunHgiX1jpF4/RA2stzFiWVsybHgqIFKMerPpdfwHgMQyKsB3/hoIGshCOsWCMM5srOXBH1eBCGD1rD+vXem+epq6PvnkOlERYuzXcRfEpYxDJcq5xJ4qgQ528= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GzhksTY9KykhAvuuutPvni3sV/T7hgmlN+4JLwTS5ePX2ktz1N1E1aPG1qs0RrIPPQOwbeYT1eUcvtI6jSIA0Fyyr7Tld4Q2It1W3otmlWTn0icGZsVcvVej+DgpHn5IsBelEUdP8qxely7O8VCXR3jCE3w0oVGmjIE9fRlYvTI=; X-YMail-OSG: bwwEqFwVM1mG9Rh0_qT_kSI_OFr_r5y9.M6gnI4EoVqXPIY iKoYx3uZaw0EHrisuoHdC1oGMc0g8yLySGduxCyLrRTViVixfyRHjJKct4y2 VYDqhinJHNhJvtYBvTL0RwqfbiDZaxxtIwbuhNTrq_UOfireVHaiFykIEZmW db3KxUI0iIec8XLYCQfWiRCU8_unGSuKxToSXIl9q.Q1k._5GcRUelDTvAFt 7Q_Gnchy3lgShkgLlv8VnFPxxg9I0uTAyun7vnkFEe0TBxz90UB5KhQ0YNuo yVlGxBdvPMJuanwPqbiS0GxnmPKlV1JCVZxwwsDUrA4jyXqG77DKAVVUbbnt WP1sFXUW.F3nrBU2LddmKnJZH8MJoV_l6rfaRr8eJ9eE8np0PWOsGVcxQEku 7_YRIoJn5p759Wk1YwQ2Xad0w2kcJcnu_AEy0vfFVVh7p4YZDun55J5yXHC_ w04347Q-- Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Sun, 26 Aug 2012 16:03:02 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <87fw7cah2o.fsf@latte.josefsson.org> <1345829385.29688.YahooMailNeo@web31805.mail.mud.yahoo.com> <1345830537.36750.YahooMailNeo__11890.3699367822$1345830549$gmane$org@web31805.mail.mud.yahoo.com> <87bohxliks.fsf@latte.josefsson.org> <1346002298.36826.YahooMailNeo__27246.2187720977$1346002314$gmane$org@web31813.mail.mud.yahoo.com> <873939l4cq.fsf@latte.josefsson.org> Message-ID: <1346022182.88688.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Sun, 26 Aug 2012 16:03:02 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <873939l4cq.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1935884094-692412316-1346022182=:88688" Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 23:03:09 -0000 --1935884094-692412316-1346022182=:88688 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Why should I implement a gs2 syntax and parser for the rest of the message = when the parser and grammar as it stands is extremely simple?=A0 I much pre= fer not to have to deal with an escaping mechanism.=A0 Sure there are extan= t ones, but why use one whne a simpler model is available?=0A=0AAt the mome= nt the way this is set up you only need the channel binding flag, the ident= ity in the gs2-header appears to be extraneous.=0A=0A=0A=0A=0A=0A>_________= _______________________=0A> From: Simon Josefsson =0A>= To: William Mills =0A>Cc: "kitten@ietf.org" =0A>Sent: Sunday, August 26, 2012 2:40 PM=0A>Subject: Re: Comma v= s. %x01 Re: OAuth SASL draft -05=0A> =0A>William Mills writes:=0A>=0A>> The way it is now I don't think we need comma escapin= g unless it's=0A>> actually GS2 enabled and you're in the gs2-header.=0A>= =0A>The SASL mechanism side should always be "GS2 enabled" (if you mean use= =0A>the gs2-header).=0A>=0A>> =A0 I can scan past the gs2-header looking fo= r the first %x01 and I'm=0A>> off to the SASL processing.=A0 If I have to d= efine comma escaping that=0A>> is a significant change.=0A>=0A>You need to = parse the gs2-header to find the channel binding type and=0A>authorization = identity, so I believe a gs2-header parser is needed if=0A>you want compati= bility with GS2 and a GSS-API mechanism.=A0 I don't=0A>believe it is diffic= ult to implement.=A0 There is plenty of code around=0A>that you can look at= and use.=0A>=0A>/Simon=0A>=0A>>=0A>>=0A>>=0A>>=0A>>>______________________= __________=0A>>> From: Simon Josefsson =0A>>>To: Willi= am Mills =0A>>>Cc: "kitten@ietf.org" =0A>>>Sent: Sunday, August 26, 2012 9:32 AM=0A>>>Subject: Re: Comma vs. = %x01=A0 Re:=A0 OAuth SASL draft -05=0A>>> =0A>>>William Mills writes:=0A>>>=0A>>>> A new question in play, should the kv separa= tor be converted from %x01=0A>>>> to "," which makes it more compatible wit= h the GS2 parsers out there?=0A>>>>=0A>>>> I am not in favor of this, becau= se one of the data elements to be=0A>>>> carried is the HTTP authentication= header payload in which comma might=0A>>>> apprear, but control characters= are not allowed.=A0 I picked a control=0A>>>> character specifically for t= his reason.=0A>>>=0A>>>If using "," would make a large percentage of typica= l exchanges contain=0A>>>an escaped "," (i.e., "=3D2C") then I share your c= oncern with ",".=0A>>>=0A>>>However, if it is just occasional that the payl= oad contains "," I think=0A>>>using "," is simpler -- remember that you nee= d to implement the ","=0A>>>escaping stuff anyway due to the gs2-header.=A0= So you will have the code=0A>>>present in your application anyway.=0A>>>= =0A>>>/Simon=0A>>>=0A>>>=0A>>>=0A>> _______________________________________= ________=0A>> Kitten mailing list=0A>> Kitten@ietf.org=0A>> https://www.iet= f.org/mailman/listinfo/kitten=0A>=0A>=0A> --1935884094-692412316-1346022182=:88688 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Why shoul= d I implement a gs2 syntax and parser for the rest of the message when the = parser and grammar as it stands is extremely simple?  I much prefer no= t to have to deal with an escaping mechanism.  Sure there are extant o= nes, but why use one whne a simpler model is available?

At the momen= t the way this is set up you only need the channel binding flag, the identi= ty in the gs2-header appears to be extraneous.


=20 From: Simon Josefsson <= simon@josefsson.org>
To: William Mills <wmills@yahoo-inc.com>
Cc: "kitten@ietf.org" <kitten@ietf.org> Sent: Sunday, August 26= , 2012 2:40 PM
Subject: Re: Comma vs. %x01 Re: OAuth SASL draft -05

Will= iam Mills <wmills@yahoo-inc.com> writes:

> The way= it is now I don't think we need comma escaping unless it's
> actuall= y GS2 enabled and you're in the gs2-header.

The SASL mechanism side = should always be "GS2 enabled" (if you mean use
the gs2-header).

= >   I can scan past the gs2-header looking for the first %x01 and I'm
> off to the SASL processing.  If I have to define comma es= caping that
> is a significant change.

You need to parse the g= s2-header to find the channel binding type and
authorization identity, s= o I believe a gs2-header parser is needed if
you want compatibility with= GS2 and a GSS-API mechanism.  I don't
believe it is difficult to i= mplement.  There is plenty of code around
that you can look at and = use.

/Simon

>
>
>
>
>>_________= _______________________
>> From: Simon Josefsson <simon@jose= fsson.org>
>>To: William Mills <wmills@yahoo-inc.co= m>
>>Cc: "kitten@ietf.org" <kitten@= ietf.org>
>>Sent: Sunday, August 26, 2012 9:32 AM
>&= gt;Subject: Re: Comma vs. %x01  Re:  OAuth SASL draft -05
>= >
>>William Mills <wmills@yahoo-inc.com> writes= :
>>
>>> A new question in play, should the kv separat= or be converted from %x01
>>> to "," which makes it more compat= ible with the GS2 parsers out there?
>>>
>>> I am n= ot in favor of this, because one of the data elements to be
>>>= carried is the HTTP authentication header payload in which comma might
= >>> apprear, but control characters are not allowed.  I picke= d a control
>>> character specifically for this reason.
>= >
>>If using "," would make a large percentage of typical exchanges contain
>>an escaped "," (i.e., "=3D2C") then I share y= our concern with ",".
>>
>>However, if it is just occasio= nal that the payload contains "," I think
>>using "," is simpler -= - remember that you need to implement the ","
>>escaping stuff any= way due to the gs2-header.  So you will have the code
>>prese= nt in your application anyway.
>>
>>/Simon
>>>>
>>
> _____________________________________________= __
> Kitten mailing list
> Kitten@ietf.org
> https://www.i= etf.org/mailman/listinfo/kitten


=
--1935884094-692412316-1346022182=:88688-- From hannes.tschofenig@gmx.net Sun Aug 26 23:28:36 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2C021F8472 for ; Sun, 26 Aug 2012 23:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 WKKrzi4GBHrh for ; Sun, 26 Aug 2012 23:28:36 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id EB4F821F846F for ; Sun, 26 Aug 2012 23:28:35 -0700 (PDT) Received: (qmail invoked by alias); 27 Aug 2012 06:28:34 -0000 Received: from unknown (EHLO [10.255.132.191]) [194.251.119.201] by mail.gmx.net (mp035) with SMTP; 27 Aug 2012 08:28:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19yAaFgGTZyUf+Jq5QL9EhK0pfxSWn+4EmOJz7S2X swIXZ9fZPh4Ftj Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Mon, 27 Aug 2012 09:28:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2C1BD367-B1A3-4C3A-8E28-95B4F02268F5@gmx.net> References: <9CAEB9BA-480D-4F5E-A341-BBF58997233E@gmx.net> <1345134011.76328.YahooMailNeo@web31811.mail.mud.yahoo.com> <2F30A7A7-F364-44C3-893E-6590F9C63F6D@gmx.net> <50322FE7.6050803@secure-endpoints.com> <3EC8A837-C13B-46AD-A349-DBF6774D494C@gmx.net> <877gslliay.fsf@latte.josefsson.org> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: kitten@ietf.org, Simon Josefsson Subject: Re: [kitten] SASL OAuth - My Conclusion So Far X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 06:28:37 -0000 > Kurt Zeilenga proposed a SCRAM-like mechanism that depends on the use > of tls-unique CB, using the CB data as the challenge, thereby shaving > a round trip. So, yes, it's definitely possible to use CB to > strengthen a mechanism, but note that if server authentication in TLS > is weak or non-existent (e.g., because an anon DH cipher suite was > used) then the mechanism is not strengthened vis-a-vis active attacks. > So the benefit of CB isn't entirely symmetric, no. >=20 The Bearer Token spec does not permit TLS without server-side = authentication.=20 So, the anonymous DH cipher suite is not an option. From simon@josefsson.org Mon Aug 27 00:53:31 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE0321F8487 for ; Mon, 27 Aug 2012 00:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.849 X-Spam-Level: X-Spam-Status: No, score=-99.849 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 0Se5hdWP06Og for ; Mon, 27 Aug 2012 00:53:31 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4BA21F846C for ; Mon, 27 Aug 2012 00:53:30 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7R7rNhM014102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Aug 2012 09:53:25 +0200 From: Simon Josefsson To: William Mills References: <87fw7cah2o.fsf@latte.josefsson.org> <1345829385.29688.YahooMailNeo@web31805.mail.mud.yahoo.com> <1345830537.36750.YahooMailNeo__11890.3699367822$1345830549$gmane$org@web31805.mail.mud.yahoo.com> <87bohxliks.fsf@latte.josefsson.org> <1346002298.36826.YahooMailNeo__27246.2187720977$1346002314$gmane$org@web31813.mail.mud.yahoo.com> <873939l4cq.fsf@latte.josefsson.org> <1346022182.88688.YahooMailNeo__42435.5442323305$1346022197$gmane$org@web31810.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120827:kitten@ietf.org::A310KjPEof77Pmbv:0AUl X-Hashcash: 1:22:120827:wmills@yahoo-inc.com::1KX95JrUbO90aw4p:F07V Date: Mon, 27 Aug 2012 09:53:23 +0200 In-Reply-To: <1346022182.88688.YahooMailNeo__42435.5442323305$1346022197$gmane$org@web31810.mail.mud.yahoo.com> (William Mills's message of "Sun, 26 Aug 2012 16:03:02 -0700 (PDT)") Message-ID: <87lih0kbyk.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 07:53:32 -0000 William Mills writes: > Why should I implement a gs2 syntax and parser for the rest of the > message when the parser and grammar as it stands is extremely simple?  > I much prefer not to have to deal with an escaping mechanism.  Sure > there are extant ones, but why use one whne a simpler model is > available? > > At the moment the way this is set up you only need the channel binding > flag, the identity in the gs2-header appears to be extraneous. I believe you need a parser for the gs2-header syntax if you want the GSS-API OAuth mechanism to be wire compatible with the SASL OAuth mechanism via GS2. The gs2 header carries the authorization header which presumably servers will need. Of course, if your implementation never looks at the authorization identity, you don't need to parse it, however users may be surprised to request authorization as "joe" but find themselves logged in as "eve". The mechanism should allow a SASL authorization identity, see RFC 4422. Hopefully support for the channel binding variant will be common, and then you need to implement the parsing and channel binding logic too. /Simon From lukeh@padl.com Mon Aug 27 01:02:27 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1266221F8532 for ; Mon, 27 Aug 2012 01:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 MFp1639CEAGH for ; Mon, 27 Aug 2012 01:02:26 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1F521F84CE for ; Mon, 27 Aug 2012 01:02:26 -0700 (PDT) Received: by us.padl.com with ESMTP id q7R81vjH001131; Mon, 27 Aug 2012 04:02:00 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_A6EEAF0F-EAD3-4633-97B1-89D711B68DF8" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: <87lih0kbyk.fsf@latte.josefsson.org> Date: Mon, 27 Aug 2012 18:02:12 +1000 Message-Id: References: <87fw7cah2o.fsf@latte.josefsson.org> <1345829385.29688.YahooMailNeo@web31805.mail.mud.yahoo.com> <1345830537.36750.YahooMailNeo__11890.3699367822$1345830549$gmane$org@web31805.mail.mud.yahoo.com> <87bohxliks.fsf@latte.josefsson.org> <1346002298.36826.YahooMailNeo__27246.2187720977$1346002314$gmane$org@web31813.mail.mud.yahoo.com> <873939l4cq.fsf@latte.josefsson.org> <1346022182.88688.YahooMailNeo__42435.5442323305$1346022197$gmane$org@web31810.mail.mud.yahoo.com> <87lih0kbyk.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 08:02:27 -0000 --Apple-Mail=_A6EEAF0F-EAD3-4633-97B1-89D711B68DF8 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On 27/08/2012, at 5:53 PM, Simon Josefsson wrote: > I believe you need a parser for the gs2-header syntax if you want the > GSS-API OAuth mechanism to be wire compatible with the SASL OAuth > mechanism via GS2. And, please, I can't imagine why one would want this to be not the case. :-) -- Luke --Apple-Mail=_A6EEAF0F-EAD3-4633-97B1-89D711B68DF8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 27/08/2012, at 5:53 PM, Simon Josefsson <simon@josefsson.org> wrote:

I believe you need a parser for the gs2-header syntax if you want the
GSS-API OAuth mechanism to be wire compatible with the SASL OAuth
mechanism via GS2.

And, please, I can't imagine why one would want this to be not the case. :-)

-- Luke
--Apple-Mail=_A6EEAF0F-EAD3-4633-97B1-89D711B68DF8-- From wmills@yahoo-inc.com Mon Aug 27 08:50:31 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0B021F8535 for ; Mon, 27 Aug 2012 08:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.558 X-Spam-Level: X-Spam-Status: No, score=-17.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 OdjME+kPPIBx for ; Mon, 27 Aug 2012 08:50:30 -0700 (PDT) Received: from nm27.bullet.mail.sp2.yahoo.com (nm27.bullet.mail.sp2.yahoo.com [98.139.91.97]) by ietfa.amsl.com (Postfix) with SMTP id D0FB521F84CF for ; Mon, 27 Aug 2012 08:50:29 -0700 (PDT) Received: from [98.139.91.65] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 27 Aug 2012 15:50:12 -0000 Received: from [72.30.22.203] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 27 Aug 2012 15:50:12 -0000 Received: from [127.0.0.1] by omp1065.mail.sp2.yahoo.com with NNFMP; 27 Aug 2012 15:50:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 610432.963.bm@omp1065.mail.sp2.yahoo.com Received: (qmail 50032 invoked by uid 60001); 27 Aug 2012 15:50:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346082612; bh=UJXfD0Y17KTqhV5lcxPyG0anoed9s4Ff36hD3bupOLY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ajLsj7fAjh1OpyjkpTca8TA9hGTDnra3w3csKeeP6MK4uNOX5hPzMRO4cMPk/+HXuTVTuPwKEaQCLTWa8xc69YT1g9Jvn/YB4V9bD58kERFNLWXt9au+eN96+phfqssDjYUQ2odtUu7UFwB39jOavIWMzyKVl/+prq8e0wsTxAE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IDxFIDjNEHYb0zuAyh9vYcd3H1DdYrOR+LbrcnTZikGYhlgmBmOLaC7DZZmJxGaMaBomVWZ9KicARfIdH2+aQfRI4ITadhZ/HTp4CmgcjHsHds2OSDT+0GnYTUPGItyICLB2T2AvtPaWcrvV+pfJ3kzAT/ygd3Xw9xQYTW6JL3A=; X-YMail-OSG: GYPvhVsVM1lzzuPfx4EFYiZxgfX4jvCom68G0VA1FcjNbN_ Vrlc3rF2aBFhDkrntW5MKQPk1tfiyhgtj7Wqlpn6rdpJ5Y0Wsqz5o9hHe4Wr uJDT54ZGBYSTEavrFhzaFNh1YsZmYlwR4I0pmZLr0yEhdhwSNQp_NklrgjhT Vo3Yn5iTEsNuc8zpLc460A2iX.JRuutE2Rr6znZo1kSPCfIFUiZ14Ohunhm2 CACykWrFtu0cBqgujSiMV_UAoyZufFDYwbgUJNQe6YPPqx9.9RRGr49VOWyg C9xpArk.F7wzUYMUqj5nrgiYys8l26r32HCHqCTQa4cYt8X0WzFVdT0RSqif Oynzx2qJbvLJsLavo.SvRdiod3GeS41jZH5IOuSoupB6D_.sVk9lz9yU0uvA 1RxPeXd_wmemAKWGDrZuNu8v8sVIG6R3YbYzf0QBArBA- Received: from [99.31.212.42] by web31816.mail.mud.yahoo.com via HTTP; Mon, 27 Aug 2012 08:50:11 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <87fw7cah2o.fsf@latte.josefsson.org> <1345829385.29688.YahooMailNeo@web31805.mail.mud.yahoo.com> <1345830537.36750.YahooMailNeo__11890.3699367822$1345830549$gmane$org@web31805.mail.mud.yahoo.com> <87bohxliks.fsf@latte.josefsson.org> <1346002298.36826.YahooMailNeo__27246.2187720977$1346002314$gmane$org@web31813.mail.mud.yahoo.com> <873939l4cq.fsf@latte.josefsson.org> <1346022182.88688.YahooMailNeo__42435.5442323305$1346022197$gmane$org@web31810.mail.mud.yahoo.com> <87lih0kbyk.fsf@latte.josefsson.org> Message-ID: <1346082611.48028.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Mon, 27 Aug 2012 08:50:11 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87lih0kbyk.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-832563831-1346082611=:48028" Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:50:31 -0000 ---1238014912-832563831-1346082611=:48028 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable See section 3.2.1 for the definition of how SASL authorization and authenti= cation indentities are mapped.=A0 The "user" field and value in the gs2-hea= der are not authoritative in this spec, the values used must be derived fro= m the OAuth exchange and credentials.=0A=0A=0A=0A=0A>______________________= __________=0A> From: Simon Josefsson =0A>To: William M= ills =0A>Cc: "kitten@ietf.org" =0A= >Sent: Monday, August 27, 2012 12:53 AM=0A>Subject: Re: Comma vs. %x01 Re:= OAuth SASL draft -05=0A> =0A>William Mills writes:= =0A>=0A>> Why should I implement a gs2 syntax and parser for the rest of th= e=0A>> message when the parser and grammar as it stands is extremely simple= ?=A0=0A>> I much prefer not to have to deal with an escaping mechanism.=A0 = Sure=0A>> there are extant ones, but why use one whne a simpler model is=0A= >> available?=0A>>=0A>> At the moment the way this is set up you only need = the channel binding=0A>> flag, the identity in the gs2-header appears to be= extraneous.=0A>=0A>I believe you need a parser for the gs2-header syntax i= f you want the=0A>GSS-API OAuth mechanism to be wire compatible with the SA= SL OAuth=0A>mechanism via GS2.=0A>=0A>The gs2 header carries the authorizat= ion header which presumably servers=0A>will need.=A0 Of course, if your imp= lementation never looks at the=0A>authorization identity, you don't need to= parse it, however users may be=0A>surprised to request authorization as "j= oe" but find themselves logged=0A>in as "eve".=A0 The mechanism should allo= w a SASL authorization identity,=0A>see RFC 4422.=0A>=0A>Hopefully support = for the channel binding variant will be common, and=0A>then you need to imp= lement the parsing and channel binding logic too.=0A>=0A>/Simon=0A>=0A>=0A> ---1238014912-832563831-1346082611=:48028 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
See section 3.2.1 for the definition of how SASL authorization and authen= tication indentities are mapped.  The "user" field and value in the gs= 2-header are not authoritative in this spec, the values used must be derive= d from the OAuth exchange and credentials.

From: Simon Josefsson <simon@josefsso= n.org>
To: William = Mills <wmills@yahoo-inc.com>
Cc:= "kitten@ietf.org" <kitten@ietf.org>
Sent: Monday, August 27, 2012 12:53 AM Subject: Re: Comma vs. = %x01 Re: OAuth SASL draft -05

William Mills <wmills@yahoo-inc.com> writes:

> Why should I implement = a gs2 syntax and parser for the rest of the
> message when the parser= and grammar as it stands is extremely simple? 
> I much prefer = not to have to deal with an escaping mechanism.  Sure
> there ar= e extant ones, but why use one whne a simpler model is
> available?>
> At the moment the way this is set up you only need the chann= el binding
> flag, the identity in the gs2-header appears to be extraneous.

I believe you need a parser for the gs2-header syntax i= f you want the
GSS-API OAuth mechanism to be wire compatible with the SA= SL OAuth
mechanism via GS2.

The gs2 header carries the authorizat= ion header which presumably servers
will need.  Of course, if your = implementation never looks at the
authorization identity, you don't need= to parse it, however users may be
surprised to request authorization as= "joe" but find themselves logged
in as "eve".  The mechanism shoul= d allow a SASL authorization identity,
see RFC 4422.

Hopefully su= pport for the channel binding variant will be common, and
then you need = to implement the parsing and channel binding logic too.

/Simon

---1238014912-832563831-1346082611=:48028-- From wmills@yahoo-inc.com Mon Aug 27 08:52:42 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5487721F8453 for ; Mon, 27 Aug 2012 08:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.561 X-Spam-Level: X-Spam-Status: No, score=-17.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 Zw16y5FzjvQx for ; Mon, 27 Aug 2012 08:52:39 -0700 (PDT) Received: from nm33-vm3.bullet.mail.bf1.yahoo.com (nm33-vm3.bullet.mail.bf1.yahoo.com [72.30.239.203]) by ietfa.amsl.com (Postfix) with SMTP id 9403821F8447 for ; Mon, 27 Aug 2012 08:52:39 -0700 (PDT) Received: from [98.139.215.140] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2012 15:52:38 -0000 Received: from [98.139.212.238] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2012 15:52:38 -0000 Received: from [127.0.0.1] by omp1047.mail.bf1.yahoo.com with NNFMP; 27 Aug 2012 15:52:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 860291.12019.bm@omp1047.mail.bf1.yahoo.com Received: (qmail 53576 invoked by uid 60001); 27 Aug 2012 15:52:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346082758; bh=tbPXWd5qTZ1ihGV6McwMMQy8HQV6FAqYEDL7td5CVUw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mHSF9Payyg/PLmPFHJu7YGo6cUSEbvB5/F/rV7jLf8CQIPOSvc3Gy1oXOUfJtPOfb0JOzk3o0W0RWkaqXJXpwp1KNF7kusPFyl7pThOm7nsGWpsfWLBZZ6bQUdqD+Tyb48QacfOXJQ4RoTf/muKFafIWE2LTC6bbBw3AFhSiCGU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=a9ZqtTHOdnksqwB9z+qxgQ/8otJLBP4abKejniSR3VA8ft7g3yUXy6aFkwIm5TxROCqh4fMVhxj8UtE2EN+5NcOh+mK9wie7BPqjPbeIEffKvX1U9FtYwNA6GEgWt4sbwCgjxEEaK/bCh45N/KTp5MBh6ZT4sydlYCeMQpIL3zE=; X-YMail-OSG: zNMClfUVM1k3Fak8k6nehjihDgkdVD0mg10tdhHGZoAetHC LM_1m59oycEfhNKY6nu41p6ptXZwl7qVDJJXAwNdPc07or3Ox3Mpr7ktyoM_ 2eHYIs4PDcV.lVq4Ibgb7L0mF4pvnOOqBtFt1Nri4GYXkwnBBFxe3sKlyPsn bcC42oYtiPooc6jBvBwzCrXqt2k.o5kViVhaCG20TKRJfq7sTiyMIbag6om0 gs54y7kqg5ByGel_4t1WRCRGA5_La0i.tMM4POPjYxUZE1R8Dt3TqVXqCavP TubM496yl5.pSDIw6S_TbowGj9vW3mDM9O_mO.htqjhN1lDf_c9mxGJswGAH rIfdM2lLLOhyPkexn2_MnRC.hL5IxBX3emn.MOb7oxxSKYYjeYG3dlZTzxGn KF57Act84tH6t9iUjq.._60Fj9mNdL.rShrFGxuZd8tc- Received: from [99.31.212.42] by web31808.mail.mud.yahoo.com via HTTP; Mon, 27 Aug 2012 08:52:37 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <87fw7cah2o.fsf@latte.josefsson.org> <1345829385.29688.YahooMailNeo@web31805.mail.mud.yahoo.com> <1345830537.36750.YahooMailNeo__11890.3699367822$1345830549$gmane$org@web31805.mail.mud.yahoo.com> <87bohxliks.fsf@latte.josefsson.org> <1346002298.36826.YahooMailNeo__27246.2187720977$1346002314$gmane$org@web31813.mail.mud.yahoo.com> <873939l4cq.fsf@latte.josefsson.org> <1346022182.88688.YahooMailNeo__42435.5442323305$1346022197$gmane$org@web31810.mail.mud.yahoo.com> <87lih0kbyk.fsf@latte.josefsson.org> Message-ID: <1346082757.11323.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Mon, 27 Aug 2012 08:52:37 -0700 (PDT) From: William Mills To: Luke Howard , Simon Josefsson In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-842685398-1346082757=:11323" Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:52:42 -0000 --258328648-842685398-1346082757=:11323 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Answered in a different message, the only value needed from the gs2-header = is the channel binding flag.=0A=0A=0A=0A=0A=0A>____________________________= ____=0A> From: Luke Howard =0A>To: Simon Josefsson =0A>Cc: William Mills ; "kitten@ietf.or= g" =0A>Sent: Monday, August 27, 2012 1:02 AM=0A>Subject: = Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>=0A>=0A>On 2= 7/08/2012, at 5:53 PM, Simon Josefsson=A0 wrote:=0A>= =0A>=0A>I believe you need a parser for the gs2-header syntax if you want= =A0the=0A>>GSS-API OAuth mechanism to be wire compatible with the=A0SASL OA= uth=0A>>mechanism via GS2.=0A>>=0A>=0A>And, please, I can't imagine why one= would want this to be not=A0the case. :-)=0A>=0A>=0A>-- Luke=0A>=0A> --258328648-842685398-1346082757=:11323 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Answered = in a different message, the only value needed from the gs2-header is the ch= annel binding flag.


From: Luke Howard <lukeh@padl.com><= br> To: Simon Josefsson &l= t;simon@josefsson.org>
Cc: William Mills <wmills@yahoo-inc.com>; "kitten@ietf.org" <k= itten@ietf.org>
Sent: Monday, August= 27, 2012 1:02 AM
Subject:= Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05

On 27/08/2012, at 5:53 PM, Simon = Josefsson <simon@josefsson.or= g> wrote:

I believe you need a pars= er for the gs2-header syntax if you want the
GSS-API OAuth mechanis= m to be wire compatible with the SASL OAuth
mechanism via GS2.
<= /blockquote>
And, please, I can't imagine why one would want this t= o be not the case. :-)

-- Luke


--258328648-842685398-1346082757=:11323-- From cantor.2@osu.edu Mon Aug 27 08:58:09 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8782221F8518 for ; Mon, 27 Aug 2012 08:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ceRTzL3yVzX8 for ; Mon, 27 Aug 2012 08:58:08 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8744A21F84E1 for ; Mon, 27 Aug 2012 08:58:08 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7RFvsML004269; Mon, 27 Aug 2012 11:58:01 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.02.0309.002; Mon, 27 Aug 2012 11:54:23 -0400 From: "Cantor, Scott" To: William Mills Thread-Topic: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNhGuyPPnDfIQILk6pd6AQN0mLIJdtz5iA Date: Mon, 27 Aug 2012 15:54:22 +0000 Message-ID: In-Reply-To: <1346082611.48028.YahooMailNeo@web31816.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.60] Content-Type: text/plain; charset="us-ascii" Content-ID: <3299CE7DBB34C84C847A81B1C85BE2D9@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:58:09 -0000 On 8/27/12 11:50 AM, "William Mills" wrote: >See section 3.2.1 for the definition of how SASL authorization and >authentication indentities are mapped. The "user" field and value in the >gs2-header are not authoritative in this spec, the values used must be >derived from the OAuth exchange and > credentials. I don't think a federated system can dictate local identifiers based on non-local ones, which sounds like what you're claiming here. -- Scott From wmills@yahoo-inc.com Mon Aug 27 09:21:08 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6162E21F8495 for ; Mon, 27 Aug 2012 09:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.565 X-Spam-Level: X-Spam-Status: No, score=-17.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 OaeU-PujCPYG for ; Mon, 27 Aug 2012 09:21:07 -0700 (PDT) Received: from nm13-vm0.bullet.mail.sp2.yahoo.com (nm13-vm0.bullet.mail.sp2.yahoo.com [98.139.91.244]) by ietfa.amsl.com (Postfix) with SMTP id B4B4421F846B for ; Mon, 27 Aug 2012 09:21:07 -0700 (PDT) Received: from [72.30.22.77] by nm13.bullet.mail.sp2.yahoo.com with NNFMP; 27 Aug 2012 16:21:07 -0000 Received: from [98.139.91.23] by tm11.bullet.mail.sp2.yahoo.com with NNFMP; 27 Aug 2012 16:21:07 -0000 Received: from [127.0.0.1] by omp1023.mail.sp2.yahoo.com with NNFMP; 27 Aug 2012 16:21:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 561133.44387.bm@omp1023.mail.sp2.yahoo.com Received: (qmail 66780 invoked by uid 60001); 27 Aug 2012 16:21:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346084466; bh=Q059X673RYLlyDbWJc4OevdwzMEMGQdpEcIRvd9vD40=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=F9r6VtbAcW7oB/SChnmpvTgKyZwx2r5nGTioWNvPBccUZjswH95BH5Ad65plRt4TRQVR5bsSRZ5iGhmrBnwHJFOgucLf/rbilotxyamBw6Gdss8o0jGMGjZ2ljorcuAN0gOGer2FeHHB+nRC2w15VWaGmv3F9sZA1gWHhXN6zBo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Cmoxul7jcXpL/MW8MbkO9LevB4qhZy5sWqqi0cXcfXED9F151OhmRt83RWPwslxCTTLRRhb6yhsk5jK974X7WCpG6uhHLE08k6oXLm3bFYMyHa2lLxBetiGJ2xWH5IcWm40dqotVvhZZXnTVx4TCoKhoQC4EqMRUdhBzZLj/Ryg=; X-YMail-OSG: 4fYMnYAVM1lf2Ph1PjFFOIoTcHOOaTaKqM.TsM0qfP5XiwG m6ShkQQuLYZDai6ojKE7HZacjMRYLllzBv.tbjYfx22Ctq33ukZkdQ0GF2BR .Nf9IaD1PP8Pg0RfmnYXFkYCqPHLHeTxjDCy6XwCmyx1ZJkqBAlJS4PkkvzF GTKgWUsjOKBa4o7qddmN4_dSpQ9ZHADAwyJBJRxW_Gj0L9CEWBZisDMR7pr7 SX9lYCDkNwEDdbNEhscajVWH.q8JWKXRY4Xg3qLXWqjZijlhU2LDkpdd4tsI vo7D.hMgvQUL3NVJtWrx71ZXWC6kSZYdAzXEtb0fDtNTuAAGM_QjA_JF_LKb yLiGQ27IrdWUjDBCa0fsCWjEgQOr4uT2R5F_O3O98d_IXT1qwnpA2yGYVoQZ JEbn9.xIMRvPpkTlgJh9vzLGL4OemsSiiB_TKDn2arfE- Received: from [99.31.212.42] by web31806.mail.mud.yahoo.com via HTTP; Mon, 27 Aug 2012 09:21:06 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346082611.48028.YahooMailNeo@web31816.mail.mud.yahoo.com> Message-ID: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Mon, 27 Aug 2012 09:21:06 -0700 (PDT) From: William Mills To: "Cantor, Scott" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-721499395-1346084466=:40894" Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 16:21:08 -0000 ---1055047407-721499395-1346084466=:40894 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The value has to be derived from the credential.=A0 If the local system has= a mapping that's fine it can map to an internal ID, but that's not asserte= d by the client it's asserted by the credential (and the authorization serv= er).=0A=0A=0A=0A=0A>________________________________=0A> From: "Cantor, Sco= tt" =0A>To: William Mills =0A>Cc: = "kitten@ietf.org" =0A>Sent: Monday, August 27, 2012 8:54 = AM=0A>Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05=0A> = =0A>On 8/27/12 11:50 AM, "William Mills" wrote:=0A>= =0A>>See section 3.2.1 for the definition of how SASL authorization and=0A>= >authentication indentities are mapped.=A0 The "user" field and value in th= e=0A>>gs2-header are not authoritative in this spec, the values used must b= e=0A>>derived from the OAuth exchange and=0A>> credentials.=0A>=0A>I don't = think a federated system can dictate local identifiers based on=0A>non-loca= l ones, which sounds like what you're claiming here.=0A>=0A>-- Scott=0A>=0A= >=0A>=0A> ---1055047407-721499395-1346084466=:40894 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The value= has to be derived from the credential.  If the local system has a map= ping that's fine it can map to an internal ID, but that's not asserted by t= he client it's asserted by the credential (and the authorization server).

From: "Cantor, Sco= tt" <cantor.2@osu.edu>
To:<= /span> William Mills <wmills@yahoo-inc.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Monday, August 27, 2012 8= :54 AM
Subject: Re: [k= itten] Comma vs. %x01 Re: OAuth SASL draft -05

On = 8/27/12 11:50 AM, "William Mills" <wmills@yahoo-inc.com> wro= te:

>See section 3.2.1 for the definition of how SASL authorizati= on and
>authentication indentities are mapped.  The "user" field= and value in the
>gs2-header are not authoritative in this spec, the= values used must be
>derived from the OAuth exchange and
> cre= dentials.

I don't think a federated system can dictate local identif= iers based on
non-local ones, which sounds like what you're claiming her= e.

-- Scott



=20
---1055047407-721499395-1346084466=:40894-- From cantor.2@osu.edu Mon Aug 27 09:33:27 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF87221F8516 for ; Mon, 27 Aug 2012 09:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 WfiYxRtkFdli for ; Mon, 27 Aug 2012 09:33:26 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id B857321F8514 for ; Mon, 27 Aug 2012 09:33:26 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7RGXIHV014258; Mon, 27 Aug 2012 12:33:25 -0400 Received: from CIO-TNC-HT07.osuad.osu.edu (164.107.81.174) by CIO-KRC-HT02.osuad.osu.edu (164.107.81.40) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 27 Aug 2012 12:29:58 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.02.0309.002; Mon, 27 Aug 2012 12:29:57 -0400 From: "Cantor, Scott" To: William Mills Thread-Topic: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNhGuyPPnDfIQILk6pd6AQN0mLIJdtz5iAgABKiQD//79lAA== Date: Mon, 27 Aug 2012 16:29:56 +0000 Message-ID: In-Reply-To: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.60] Content-Type: text/plain; charset="us-ascii" Content-ID: <10E377159DF9874091CB5631F8AB0B99@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 16:33:27 -0000 On 8/27/12 12:21 PM, "William Mills" wrote: > >The value has to be derived from the credential. *A* value does, yes, not *the* value necessarily. >If the local system has a mapping that's fine it can map to an internal >ID, but that's not asserted by the client it's asserted by the credential >(and the authorization server). The credential is asserting its own notion of identity. I disagree that the client does not (or at least cannot) assert one. Then there's an evaluation as to whether the locally-asserted value is appropriate given the federated credential. You sound as though you want to dictate how the application works or how SASL works, when all you're doing is defining a mechanism. I think the mechanism needs to accept the model its plugging into. If I've misunderstood that model, I'll need to adjust some things myself. -- Scott From wmills@yahoo-inc.com Mon Aug 27 10:17:21 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9965E21F8545 for ; Mon, 27 Aug 2012 10:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.567 X-Spam-Level: X-Spam-Status: No, score=-17.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 L0DBhdTwjt1I for ; Mon, 27 Aug 2012 10:17:20 -0700 (PDT) Received: from nm21.bullet.mail.sp2.yahoo.com (nm21.bullet.mail.sp2.yahoo.com [98.139.91.91]) by ietfa.amsl.com (Postfix) with SMTP id BB33921F8535 for ; Mon, 27 Aug 2012 10:17:19 -0700 (PDT) Received: from [72.30.22.79] by nm21.bullet.mail.sp2.yahoo.com with NNFMP; 27 Aug 2012 17:17:15 -0000 Received: from [98.139.91.7] by tm13.bullet.mail.sp2.yahoo.com with NNFMP; 27 Aug 2012 17:17:15 -0000 Received: from [127.0.0.1] by omp1007.mail.sp2.yahoo.com with NNFMP; 27 Aug 2012 17:17:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 171136.34596.bm@omp1007.mail.sp2.yahoo.com Received: (qmail 93705 invoked by uid 60001); 27 Aug 2012 17:17:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346087834; bh=9jplt9hFdvDZgY7ckj4q8FanuvL481FiIJBTHxgstBE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mjEtuNXOjkdfXeDIZ9HJkxGObNVA0Gb6dfZuF7uBE0Oo39lz7Om/TWKyAwA95yKfRjV8lXRedHLQZ+RgDbUqB3KsViZu+hX2Tl4K4kOpBXq+/mETc2rXcoxsqxBY1gg707DegyCX1UXnrHL+iCvcMTqPSBirEArLjm2pMEZTx4o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=evyWlF8LOPotgvwyU0Hr7Xp/R4YlFzPFGAudhq9SWO5BqYpv3zu58nw/pxUUU7feHADOkjd/DAkyhlJdsEsOVuHBOOIDBQa7lijn2xUKMNTfdahKFUYYk3dTPQoK0/giK6DhA8qZtMN1uDsUc2WN3zME/Ve6yntBzmUNDDCyfYM=; X-YMail-OSG: cdQN3LAVM1m7kSGBXfz9_QjBRuzCKEqI.0ox4NgmvGyGtoa TQkZ.9.Y0TBwKW5ORsLsnjno97VUyTS6mfPqH3rLQcxKrSRZB8lwiIoomF4F v.5rzs2PzUFk67Ib.OtySugybtD8J1kNqmQ7PfOllCN83XxHFBjVoJZx9l7b tX5jIOQZntrZGcFKw39up7f3Rz90f6q9slsLI9BSnSlCqe79ZFL5VSWx2dCF QlUASacODNMh5bikEbGlXu7mw1mfwRcx0aHkyktOMOBRQjLSi7ln5JITwvBy Ba3A8tiVxpfYsnDLhETGgqsiradgrUqFlep5QcCZHVtL81k0dWpAoIPTNA1l JyiTN.PygaPIYXCS_LQh2SVVi2YjGFrCmSuQRagaaonqcKS6HuZvWW2VI_ZY ehF58OuTif5jnmsTQTXY_5vmCtA8yscpeDmAsJqgR_D4- Received: from [99.31.212.42] by web31805.mail.mud.yahoo.com via HTTP; Mon, 27 Aug 2012 10:17:14 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: <1346087834.15646.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Mon, 27 Aug 2012 10:17:14 -0700 (PDT) From: William Mills To: "Cantor, Scott" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-2043097724-1346087834=:15646" Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 17:17:21 -0000 ---551393103-2043097724-1346087834=:15646 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I think what you are arguing for is a model that supports a credential that= allows access to N mailboxes in the IMAP case and the ID sent by the clien= t selects the mailbox to access.=A0=A0 The problem I think is we don't have= a way in OAuth to deal with understanding that the same credential can be = used with N different identities.=A0 Custom clients certainly could do this= , an example from work life would be Yahoo Small Businees where a single ac= count is the master for N Small Business setups, but we don't have a genera= l case I think.=0A=0A=0AIf it's a single identity per credential then trust= ing the client is wrong, you have to trust the credential.=A0 You could tie= the authentication to an extra piece of information, but that kind of brea= ks OAuth.=0A=0AOAuth can be tied to a specific URI, and it could work that = way, but that would require defining a URI for every type of endpoint which= we don't have.=0A=0A=0A=0A=0A=0A>________________________________=0A> From= : "Cantor, Scott" =0A>To: William Mills =0A>Cc: "kitten@ietf.org" =0A>Sent: Monday, August = 27, 2012 9:29 AM=0A>Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL d= raft -05=0A> =0A>On 8/27/12 12:21 PM, "William Mills" wrote:=0A>>=0A>>The value has to be derived from the credential.=0A>=0A>*= A* value does, yes, not *the* value necessarily.=0A>=0A>>If the local syste= m has a mapping that's fine it can map to an internal=0A>>ID, but that's no= t asserted by the client it's asserted by the credential=0A>>(and the autho= rization server).=0A>=0A>The credential is asserting its own notion of iden= tity. I disagree that=0A>the client does not (or at least cannot) assert on= e. Then there's an=0A>evaluation as to whether the locally-asserted value i= s appropriate given=0A>the federated credential.=0A>=0A>You sound as though= you want to dictate how the application works or how=0A>SASL works, when a= ll you're doing is defining a mechanism. I think the=0A>mechanism needs to = accept the model its plugging into.=0A>=0A>If I've misunderstood that model= , I'll need to adjust some things myself.=0A>=0A>-- Scott=0A>=0A>=0A>=0A> ---551393103-2043097724-1346087834=:15646 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I think w= hat you are arguing for is a model that supports a credential that allows a= ccess to N mailboxes in the IMAP case and the ID sent by the client selects= the mailbox to access.   The problem I think is we don't have a = way in OAuth to deal with understanding that the same credential can be use= d with N different identities.  Custom clients certainly could do this= , an example from work life would be Yahoo Small Businees where a single ac= count is the master for N Small Business setups, but we don't have a genera= l case I think.

If it's= a single identity per credential then trusting the client is wrong, you have to trust the credential.  You could tie the authentication to an= extra piece of information, but that kind of breaks OAuth.

OAuth can be tied to a specific U= RI, and it could work that way, but that would require defining a URI for e= very type of endpoint which we don't have.


From: "Cantor, Scott" <cantor.2@osu.edu>
= To: William Mills <wmi= lls@yahoo-inc.com>
Cc:<= /b> "kitten@ietf.org" <kitten@ietf.org>
Sent: Monday, August 27, 2012 9:29 AM
Subject: Re: [kitten] Comma vs. %x= 01 Re: OAuth SASL draft -05

On 8/27/12 12:21 PM, "= William Mills" <wmills@yahoo-inc.com> wrote:
>
>= The value has to be derived from the credential.

*A* value does, yes, not *the* value n= ecessarily.

>If the local system has a mapping that's fine it can= map to an internal
>ID, but that's not asserted by the client it's a= sserted by the credential
>(and the authorization server).

The= credential is asserting its own notion of identity. I disagree that
the= client does not (or at least cannot) assert one. Then there's an
evalua= tion as to whether the locally-asserted value is appropriate given
the f= ederated credential.

You sound as though you want to dictate how the= application works or how
SASL works, when all you're doing is defining = a mechanism. I think the
mechanism needs to accept the model its pluggin= g into.

If I've misunderstood that model, I'll need to adjust some t= hings myself.

-- Scott



---551393103-2043097724-1346087834=:15646-- From wmills@yahoo-inc.com Mon Aug 27 10:21:24 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BBC21F8574 for ; Mon, 27 Aug 2012 10:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.569 X-Spam-Level: X-Spam-Status: No, score=-17.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 WYpmmk5DuX5M for ; Mon, 27 Aug 2012 10:21:21 -0700 (PDT) Received: from nm9-vm0.bullet.mail.ac4.yahoo.com (nm9-vm0.bullet.mail.ac4.yahoo.com [98.139.53.192]) by ietfa.amsl.com (Postfix) with SMTP id 8570C21F8535 for ; Mon, 27 Aug 2012 10:21:21 -0700 (PDT) Received: from [98.139.52.190] by nm9.bullet.mail.ac4.yahoo.com with NNFMP; 27 Aug 2012 17:21:17 -0000 Received: from [98.139.52.130] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 27 Aug 2012 17:21:17 -0000 Received: from [127.0.0.1] by omp1013.mail.ac4.yahoo.com with NNFMP; 27 Aug 2012 17:21:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 56314.42541.bm@omp1013.mail.ac4.yahoo.com Received: (qmail 35588 invoked by uid 60001); 27 Aug 2012 17:21:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346088076; bh=ETsxvvJmqIYAqix+m3ECY64ARTp2XGUfBDscES4FGkY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GNLxMg2boE7UhRC5NfZW8DbqIIwUJfyoRwob0DUv28FVihSI/R6qao2zDUnLBUkqUpyKry4hoLcAX6i7olpo3RAdIy3W7MYGqLjt/5rzTsLLVbSBO/Ewz54N7sGUVz4Qo2G54HnEJgG7RfyWMute/e3QniGAfjEiVmX+EL7hL28= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NEAPaNU2WHJtQ04Y821naqpYNHQvvRiyf6Ku6trhXTrnTYoSMTmTetuEA3LzILMjFNGSduKFTxZZgSJs+AVCVby3g1Z1D0Q1AdRuLP7ZIEVQqxqnE21AC9K/AP1xFfGGz58aaufxALgnvcyuR3xuUP23rK2MWcvyDLLSecxf/yc=; X-YMail-OSG: 3CsSMSYVM1lWlFQqHzZhYNyL47aiBDH84yn6X5yQSzsy7lu mBgjkUMbIpmOPgaV57YV8pwSLtphANl6m_TzeXVI7EAIe7HQ2bcI5MAsgFkX htXl.BVwziiOyUvA_eohAPlNrnZq6qmH_G2j6y73_cRSoFqDzgfRt1SMPrQd Rinm7jw3okejDyaXBDXxlCtl2PJPxDxGGx1hUMnvQke5Rz5u7C9uXIQvWdjP 3XftFjBYSM9pqNZUzqeuOXT7rMLpCBpVQT4PXA62CjocCvf7jsdV935KFM7f bh0CSvrUBA4OCGmrgns6p3HQfaLMVZXMIG7N05jZ245Xt1t2Eg3_KKH5YY6o AWOPm0J.o.8wLH2k2wppkvuyLYdhhrjvQT_BNAI4Y98oeQpLOA_ssAcJljy. Mm1eWQcJWybNDySWNhRFL.HvmSJx5Bf3xkOuJvs8R1civ Received: from [99.31.212.42] by web31802.mail.mud.yahoo.com via HTTP; Mon, 27 Aug 2012 10:21:16 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo@web31805.mail.mud.yahoo.com> Message-ID: <1346088076.28255.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Mon, 27 Aug 2012 10:21:16 -0700 (PDT) From: William Mills To: William Mills , "Cantor, Scott" In-Reply-To: <1346087834.15646.YahooMailNeo@web31805.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-209237152-1346088076=:28255" Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 17:21:24 -0000 ---1036955950-209237152-1346088076=:28255 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Actually, the "user" field selecting a value from a list in the credential = would be valid under the current language.=A0 The assertion of identity sti= ll is carried in the credential.=0A=0A=0A=0A=0A=0A>________________________= ________=0A> From: William Mills =0A>To: "Cantor, Sco= tt" =0A>Cc: "kitten@ietf.org" =0A>Sent= : Monday, August 27, 2012 10:17 AM=0A>Subject: Re: [kitten] Comma vs. %x01 = Re: OAuth SASL draft -05=0A> =0A>=0A>I think what you are arguing for is = a model that supports a credential that allows access to N mailboxes in the= IMAP case and the ID sent by the client selects the mailbox to access.=A0= =A0 The problem I think is we don't have a way in OAuth to deal with unders= tanding that the same credential can be used with N different identities.= =A0 Custom clients certainly could do this, an example from work life would= be Yahoo Small Businees where a single account is the master for N Small B= usiness setups, but we don't have a general case I think.=0A>=0A>=0A>=0A>If= it's a single identity per credential then trusting the client is wrong, y= ou have to trust the credential.=A0 You could tie the authentication to an = extra piece of information, but that kind of breaks OAuth.=0A>=0A>=0A>OAuth= can be tied to a specific URI, and it could work that way, but that would = require defining a URI for every type of endpoint which we don't have.=0A>= =0A>=0A>=0A>=0A>=0A>=0A>>________________________________=0A>> From: "Canto= r, Scott" =0A>>To: William Mills = =0A>>Cc: "kitten@ietf.org" =0A>>Sent: Monday, August 27, = 2012 9:29 AM=0A>>Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draf= t -05=0A>> =0A>>On 8/27/12 12:21 PM, "William Mills" = wrote:=0A>>>=0A>>>The value has to be=0A derived from the credential.=0A>>= =0A>>*A* value does, yes, not *the* value necessarily.=0A>>=0A>>>If the loc= al system has a mapping that's fine it can map to an internal=0A>>>ID, but = that's not asserted by the client it's asserted by the credential=0A>>>(and= the authorization server).=0A>>=0A>>The credential is asserting its own no= tion of identity. I disagree that=0A>>the client does not (or at least cann= ot) assert one. Then there's an=0A>>evaluation as to whether the locally-as= serted value is appropriate given=0A>>the federated credential.=0A>>=0A>>Yo= u sound as though you want to dictate how the application works or how=0A>>= SASL works, when all you're doing is defining a mechanism. I think the=0A>>= mechanism needs to accept the model its plugging into.=0A>>=0A>>If I've mis= understood that model, I'll need to adjust some things myself.=0A>>=0A>>-- = Scott=0A>>=0A>>=0A>>=0A>>=0A>______________________________________________= _=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman= /listinfo/kitten=0A>=0A>=0A> ---1036955950-209237152-1346088076=:28255 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Actually,= the "user" field selecting a value from a list in the credential would be = valid under the current language.  The assertion of identity still is = carried in the credential.


From: William Mills <wmills@yahoo-= inc.com>
To: "Canto= r, Scott" <cantor.2@osu.edu>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Monday, August 27, 2012 1= 0:17 AM
Subject: Re: [= kitten] Comma vs. %x01 Re: OAuth SASL draft -05

I think what you are arguing for is a model that supports a credentia= l that allows access to N mailboxes in the IMAP case and the ID sent by the= client selects the mailbox to access.   The problem I think is w= e don't have a way in OAuth to deal with understanding that the same creden= tial can be used with N different identities.  Custom clients certainl= y could do this, an example from work life would be Yahoo Small Businees wh= ere a single account is the master for N Small Business setups, but we don'= t have a general case I think.


OAuth can be tied to a specific UR= I, and it could work that way, but that would require defining a URI for ev= ery type of endpoint which we don't have.


=
From: "C= antor, Scott" <cantor.2@osu.edu>
To: William Mills <wmills@yahoo-inc.com>
Cc: "kitten@ietf.org" <kitten@ie= tf.org>
Sent: Monda= y, August 27, 2012 9:29 AM
Subject= : Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05

On 8/27/12 12:21 PM, "William Mills" <wmills@yahoo-inc.com> wrote:
>
>Th= e value has to be=0A derived from the credential.

*A* value does, ye= s, not *the* value necessarily.

>If the local system has a mappin= g that's fine it can map to an internal
>ID, but that's not asserted = by the client it's asserted by the credential
>(and the authorization= server).

The credential is asserting its own notion of identity. I = disagree that
the client does not (or at least cannot) assert one. Then = there's an
evaluation as to whether the locally-asserted value is approp= riate given
the federated credential.

You sound as though you wan= t to dictate how the application works or how
SASL works, when all you'r= e doing is defining a mechanism. I think the
mechanism needs to accept t= he model its plugging into.

If I've misunderstood that model, I'll n= eed to adjust some things myself.

-- Scott



=20

_______________________________________________
K= itten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listin= fo/kitten


= ---1036955950-209237152-1346088076=:28255-- From cantor.2@osu.edu Mon Aug 27 10:41:43 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E069021F84B2 for ; Mon, 27 Aug 2012 10:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 4-oAeLe14IbD for ; Mon, 27 Aug 2012 10:41:42 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4D03221F84A1 for ; Mon, 27 Aug 2012 10:41:40 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7RHfXGa010913; Mon, 27 Aug 2012 13:41:38 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.02.0309.002; Mon, 27 Aug 2012 13:41:26 -0400 From: "Cantor, Scott" To: William Mills Thread-Topic: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNhGuyPPnDfIQILk6pd6AQN0mLIJdtz5iAgABKiQD//79lAIAAUEoA///DsAA= Date: Mon, 27 Aug 2012 17:41:27 +0000 Message-ID: In-Reply-To: <1346087834.15646.YahooMailNeo@web31805.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.60] Content-Type: text/plain; charset="us-ascii" Content-ID: <957E3E192CA1F84882D765BEDB3FAD38@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 17:41:43 -0000 On 8/27/12 1:17 PM, "William Mills" wrote: > >I think what you are arguing for is a model that supports a credential >that allows access to N mailboxes in the IMAP case and the ID sent by the >client selects the mailbox to access. No, I'm arguing only that federated systems cannot dictate local identification based on remote identification. That linkage is often local to the app. > The problem I think is we don't have a way in OAuth to deal with >understanding > that the same credential can be used with N different identities. >Custom clients certainly could do this, an example from work life would >be Yahoo Small Businees where a single account is the master for N Small >Business setups, but we don't have a general > case I think. It's not up to OAuth or the client, it's up to the service/app. >If it's a single identity per credential then trusting the client is >wrong, you have to trust the credential. You could tie the >authentication to an extra piece of information, but that kind of breaks >OAuth. I'm not saying you trust the client, I'm saying that the question of local identification based on the credential is a local (to an app) matter. This is so intrinsic to federation that I have to wonder if this is a terminology problem. -- Scott From wmills@yahoo-inc.com Mon Aug 27 11:52:03 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F09721F851A for ; Mon, 27 Aug 2012 11:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.561 X-Spam-Level: X-Spam-Status: No, score=-17.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 Izjp-rrqM9Bx for ; Mon, 27 Aug 2012 11:52:02 -0700 (PDT) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) by ietfa.amsl.com (Postfix) with SMTP id E759A21F852A for ; Mon, 27 Aug 2012 11:52:01 -0700 (PDT) Received: from [98.139.212.151] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2012 18:52:01 -0000 Received: from [98.139.212.235] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2012 18:52:01 -0000 Received: from [127.0.0.1] by omp1044.mail.bf1.yahoo.com with NNFMP; 27 Aug 2012 18:52:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 278732.33105.bm@omp1044.mail.bf1.yahoo.com Received: (qmail 75251 invoked by uid 60001); 27 Aug 2012 18:52:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346093520; bh=CkwcxLulrCb6lqeg335qxr8RZM8CidHdFbR/MSaR4dg=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MaFe2snJa4FNEx08q3NWyip3o24/qA1pLLcizbRbtjW/8gZvlFE7Cp0F8WVtfOtBytY8BtmDKjAaG6xER7j3EXUUrsv7HWf0gq6SprC94SsBDBleu8bcfkPZvcpKKyZ269may0kxfCinV37BXqzFsI9BfsDubKENMd+8ixpBSuY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=T7c98CkRNadyvonbXmij3eCu+8DSk4ab87T+ZysHFb9eS3yrXPNdPXNGP3dwM6IRiMWsXp2DGwBcjIgI5wDtaFrKw5fdC1UhTAxpxhZ004U2k0CzrVn/3/Ia11o4S224DgVVbyRuw/La2HY1/cKYSn3FFgCUjKFh+Q5xqpI3Cs0=; X-YMail-OSG: MRfTPrcVM1lLUvmuUTENpegPT8vAB3Ekdu4713e8A9cj13C WVKpX3Ctg0YcJJ7XOXPSMhsh.01cBhO7JRXCT78y9JsFk2q2bDzXu996fB0s Ru1tJjQT30li07rRucXkpv1SjRxVbX_rmSxxb.UA8gyEwTGmhcLYyoROaCdz ELavwMzyZ0LdBmVRn3VhlypQsNlaqQvqGuCjjMQNpdPh.KVwk98.rgjoQmSv Hi9mjYILCj.ECu6t1_0OPcImvfkpFolgiYP1JO_JYD355teHd1007LJdfbvG zKU6Yhv9mPqmx0wje_iuunWiL8KVWK4F4u3FAYWQJjzHv21eNIAkHXRxQ3TT 1Jd_5gc8k6NvMEiEzdHc.zz8enYZjfua1JXTjRH2cauraHdlzkrALF39kksj OMbZ0N1_W_PYq8WCvSL0zGODjdHhEGjdOz0.hJZUdXtkcOzZNVeml0ggQj6r vc4A..w-- Received: from [209.131.62.113] by web31812.mail.mud.yahoo.com via HTTP; Mon, 27 Aug 2012 11:52:00 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346087834.15646.YahooMailNeo@web31805.mail.mud.yahoo.com> Message-ID: <1346093520.70912.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Mon, 27 Aug 2012 11:52:00 -0700 (PDT) From: William Mills To: "Cantor, Scott" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-235507735-1346093520=:70912" Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 18:52:03 -0000 --1458549034-235507735-1346093520=:70912 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > This is so intrinsic to federation that I have to wonder if this is a=0A>= terminology problem.=0A=0A=0AI think so, yes.=A0 The members of the federa= tion have to already have agreed how to map identities.=0A=0A=0A=0A=0A>____= ____________________________=0A> From: "Cantor, Scott" = =0A>To: William Mills =0A>Cc: "kitten@ietf.org" =0A>Sent: Monday, August 27, 2012 10:41 AM=0A>Subject: Re: [k= itten] Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>On 8/27/12 1:17 PM= , "William Mills" wrote:=0A>>=0A>>I think what you a= re arguing for is a model that supports a credential=0A>>that allows access= to N mailboxes in the IMAP case and the ID sent by the=0A>>client selects = the mailbox to access.=0A>=0A>No, I'm arguing only that federated systems c= annot dictate local=0A>identification based on remote identification. That = linkage is often local=0A>to the app.=0A>=0A>>=A0 The problem I think is w= e don't have a way in OAuth to deal with=0A>>understanding=0A>> that the sa= me credential can be used with N different identities.=0A>>Custom clients c= ertainly could do this, an example from work life would=0A>>be Yahoo Small = Businees where a single account is the master for N Small=0A>>Business setu= ps, but we don't have a general=0A>> case I think.=0A>=0A>It's not up to OA= uth or the client, it's up to the service/app.=0A>=0A>>If it's a single ide= ntity per credential then trusting the client is=0A>>wrong, you have to tru= st the credential.=A0 You could tie the=0A>>authentication to an extra piec= e of information, but that kind of breaks=0A>>OAuth.=0A>=0A>I'm not saying = you trust the client, I'm saying that the question of local=0A>identificati= on based on the credential is a local (to an app) matter.=0A>=0A>This is so= intrinsic to federation that I have to wonder if this is a=0A>terminology = problem.=0A>=0A>-- Scott=0A>=0A>=0A>=0A> --1458549034-235507735-1346093520=:70912 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
> This is so intrinsic to federation that I have to wonder i= f this is a
> terminology problem.

=
I think so, yes.  The me= mbers of the federation have to already have agreed how to map identities.<= /span>

From: "C= antor, Scott" <cantor.2@osu.edu>
To: William Mills <wmills@yahoo-inc.com>
Cc: "kitten@ietf.org" <kitten@= ietf.org>
Sent: Mo= nday, August 27, 2012 10:41 AM
Su= bject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05

On 8/27/12 1:17 PM, "William Mills" <wmills@ya= hoo-inc.com> wrote:
>
>I think what you are arguing for is a model that sup= ports a credential
>that allows access to N mailboxes in the IMAP cas= e and the ID sent by the
>client selects the mailbox to access.
No, I'm arguing only that federated systems cannot dictate local
ident= ification based on remote identification. That linkage is often local
to= the app.

>  The problem I think is we don't have a way in = OAuth to deal with
>understanding
> that the same credential ca= n be used with N different identities.
>Custom clients certainly coul= d do this, an example from work life would
>be Yahoo Small Businees w= here a single account is the master for N Small
>Business setups, but= we don't have a general
> case I think.

It's not up to OAuth = or the client, it's up to the service/app.

>If it's a single iden= tity per credential then trusting the client is
>wrong, you have to trust the credential.  You could tie the
>authenticatio= n to an extra piece of information, but that kind of breaks
>OAuth.
I'm not saying you trust the client, I'm saying that the question of = local
identification based on the credential is a local (to an app) matt= er.

This is so intrinsic to federation that I have to wonder if this= is a
terminology problem.

-- Scott



=
--1458549034-235507735-1346093520=:70912-- From cantor.2@osu.edu Mon Aug 27 12:01:28 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC5021F84F2 for ; Mon, 27 Aug 2012 12:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 4j0w+9SAahGC for ; Mon, 27 Aug 2012 12:01:28 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id D6C3421F854F for ; Mon, 27 Aug 2012 12:01:26 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7RJ1DcD014933; Mon, 27 Aug 2012 15:01:22 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.02.0309.002; Mon, 27 Aug 2012 15:00:59 -0400 From: "Cantor, Scott" To: William Mills Thread-Topic: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNhGuyPPnDfIQILk6pd6AQN0mLIJdtz5iAgABKiQD//79lAIAAUEoA///DsACAAFbLAP//v22A Date: Mon, 27 Aug 2012 19:00:59 +0000 Message-ID: In-Reply-To: <1346093520.70912.YahooMailNeo@web31812.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.207.107] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5BB329D04333514E9BD2A3C2DA3822E4@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:01:29 -0000 On 8/27/12 2:52 PM, "William Mills" wrote: > >I think so, yes. The members of the federation have to already have >agreed how to map identities. Map, yes. Your mapping seems to be an identity mapping, and that=B9s not sufficient. Neither can you assume that the IdP end has done the mapping and is providing the locally correct value. That may be your deployment model, but it's not the general one. -- Scott From wmills@yahoo-inc.com Mon Aug 27 12:16:09 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DB521F844B for ; Mon, 27 Aug 2012 12:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.262 X-Spam-Level: X-Spam-Status: No, score=-17.262 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, USER_IN_DEF_WHITELIST=-15] 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 JBuIPUBTW1DS for ; Mon, 27 Aug 2012 12:16:08 -0700 (PDT) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) by ietfa.amsl.com (Postfix) with SMTP id 2B68E21F8447 for ; Mon, 27 Aug 2012 12:16:08 -0700 (PDT) Received: from [98.139.212.153] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2012 19:16:07 -0000 Received: from [98.139.215.251] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 27 Aug 2012 19:16:07 -0000 Received: from [127.0.0.1] by omp1064.mail.bf1.yahoo.com with NNFMP; 27 Aug 2012 19:16:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 459326.30518.bm@omp1064.mail.bf1.yahoo.com Received: (qmail 88878 invoked by uid 60001); 27 Aug 2012 19:16:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346094966; bh=HneuZ2BB2ll69z3VXI6sGZSJAZfyoy9Z8ZqFa2P9LXo=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kDtCzG17CmH57/eFIdNcCjK2rcumihF+961TxFEWx9wg6j8C7tfagzSy+h93JMV23dZkZaymF6LxkphmF0OstUSraytFARdVHStsxxauoMKytru34eU4KXuEfbFnt5f5XK5aIN2AUL9ypb9KYDWbSMCjQQINo+8nZkBhCoGAY1I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ABIlUsnqcG/WtSqYHd6uDd+f4GgCsPxKxHUs554g7arzlxxY1eMwui/x2J9YitW7ubnD8FnO8XdO/SpPdPvt5AVQKvOX6GKp/kdrOE4fJEmmRuvvA6EUCiu9N6suLUw8asrunPlDbRpWFSs+S8gyeZaycLPUQKq/0w4VitZSJ2U=; X-YMail-OSG: 6abxd5wVM1kHACxb76WUKcpdHet1k3PO8fp24aimEL6BIOq 79_acjkbb9QlB5yUQTcUWGVyc5UQDsJhqhVZOO.dmPeVbyfKU.E.RjUrchTW F0oZxH_Bl0706Sd0azGHZ0YalFjAKjWr2CglV1fxz9lNW9CLooUU6q3Gwqnl jblNDPkogEM1C1fBsXhMj9YpOkYq3L8wb4VLiIqloynTrmVe_d7_nLIGpemr mHiL5Pic3xutI52mfUcD_hrfLzTQe87PcJDYzi.1Unzxfw2t4oHQyBYk6DXm EowLNAb6lYOAF74hryPG9hHPoxjkxdRbhON3fEB5PmOrRUbujo4Xpzzm09BC jtmHWMgWFhoB3LsDgIZINC5YW.fOWGp_iUVjbOcl.PubSpuSAKxlgD254HUS ncmZzsyaULkt2ApGPDmeXNM4QvnMFM92q1icZQw8Ey4g.ke0wb0A7JnipZhz _bjxXgsc- Received: from [209.131.62.113] by web31812.mail.mud.yahoo.com via HTTP; Mon, 27 Aug 2012 12:16:06 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346093520.70912.YahooMailNeo@web31812.mail.mud.yahoo.com> Message-ID: <1346094966.20031.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Mon, 27 Aug 2012 12:16:06 -0700 (PDT) From: William Mills To: "Cantor, Scott" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-993165489-1346094966=:20031" Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:16:09 -0000 --1458549034-993165489-1346094966=:20031 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable No, I'm not assuming the IDP has the mapping, I'm assuming the local server= knows how to map from an asserted federati0on ID to a local one.=0A=0A=0A= =0A=0A=0A>________________________________=0A> From: "Cantor, Scott" =0A>To: William Mills =0A>Cc: "kitten@ie= tf.org" =0A>Sent: Monday, August 27, 2012 12:00 PM=0A>Sub= ject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>On 8/2= 7/12 2:52 PM, "William Mills" wrote:=0A>>=0A>>I thin= k so, yes.=A0 The members of the federation have to already have=0A>>agreed= how to map identities.=0A>=0A>Map, yes. Your mapping seems to be an identi= ty mapping, and that=B9s not=0A>sufficient. Neither can you assume that the= IdP end has done the mapping=0A>and is providing the locally correct value= .=0A>=0A>That may be your deployment model, but it's not the general one.= =0A>=0A>-- Scott=0A>=0A>=0A>=0A> --1458549034-993165489-1346094966=:20031 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
No, I'm n= ot assuming the IDP has the mapping, I'm assuming the local server knows ho= w to map from an asserted federati0on ID to a local one.

=
--1458549034-993165489-1346094966=:20031-- From cantor.2@osu.edu Mon Aug 27 12:42:33 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904EA21F8510 for ; Mon, 27 Aug 2012 12:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_82=0.6] 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 ZSZUDzwnbQve for ; Mon, 27 Aug 2012 12:42:33 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0251C21F84FA for ; Mon, 27 Aug 2012 12:42:32 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7RJgUtu024557; Mon, 27 Aug 2012 15:42:30 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.02.0309.002; Mon, 27 Aug 2012 15:42:30 -0400 From: "Cantor, Scott" To: William Mills Thread-Topic: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNhGuyPPnDfIQILk6pd6AQN0mLIJdtz5iAgABKiQD//79lAIAAUEoA///DsACAAFbLAP//v22AAAjp3AD//8RTgA== Date: Mon, 27 Aug 2012 19:42:30 +0000 Message-ID: In-Reply-To: <1346094966.20031.YahooMailNeo@web31812.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.207.107] Content-Type: text/plain; charset="us-ascii" Content-ID: <30F27FC5D4A15444B80488B7A7471BCD@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:42:33 -0000 On 8/27/12 3:16 PM, "William Mills" wrote: >No, I'm not assuming the IDP has the mapping, I'm assuming the local >server knows how to map from an asserted federati0on ID to a local one. The point, though, is that (if I'm not misunderstanding), existing SASL servers do this in part via the authz id. Your mechanism is inside that code as a plugin, it's not meant to be driving the application-level behavior. I'm sure I'll be corrected if I'm wrong. -- Scott From wmills@yahoo-inc.com Mon Aug 27 13:38:43 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305B721F849A for ; Mon, 27 Aug 2012 13:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.258 X-Spam-Level: X-Spam-Status: No, score=-17.258 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, USER_IN_DEF_WHITELIST=-15] 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 ZnD3q+WyK+Ia for ; Mon, 27 Aug 2012 13:38:42 -0700 (PDT) Received: from nm2-vm0.bullet.mail.ac4.yahoo.com (nm2-vm0.bullet.mail.ac4.yahoo.com [98.139.52.66]) by ietfa.amsl.com (Postfix) with SMTP id 773E821F8499 for ; Mon, 27 Aug 2012 13:38:41 -0700 (PDT) Received: from [98.139.52.191] by nm2.bullet.mail.ac4.yahoo.com with NNFMP; 27 Aug 2012 20:38:36 -0000 Received: from [98.139.52.149] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 27 Aug 2012 20:38:36 -0000 Received: from [127.0.0.1] by omp1032.mail.ac4.yahoo.com with NNFMP; 27 Aug 2012 20:38:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 32122.78192.bm@omp1032.mail.ac4.yahoo.com Received: (qmail 57174 invoked by uid 60001); 27 Aug 2012 20:38:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346099915; bh=Nqs1Xk+bJjzWpuHSmvIz+ef/W4aFM534WNQUnlj2fTY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=brVzreLXcAP1z1B82tYZAU0JWJk17EWMLJ9AqVGQOCxuiyL5KdJsT60Pq8IvyduCOXgyd1qs71mMk6J4LvcLSukChopYSSAOd1SLTRzo6EaXVnzORgMQ6L+dvxSRiZT6reiU/4jXjl3beUfsJ/33iQ5vcQ4VhF9vhmuq/2IKPUM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dJHI/Qnx6woB4O4uz1dvu2/C0dBmGeItjW3CkIm9ZgEAaT93KVvvXLrbXFDkAvfUygidLreCI4R+sYKtNuUbQovEQq5ozt2JToYkqCt761+pT4XZg8HpFF3O3bkgctm9His8uGR/AL7iOJfK9rMpNYxvkVo3yRJAMwvHUaBEflI=; X-YMail-OSG: Ozmot_8VM1nC_Yb.kAfTxwr3y9rlhTpTSi4FuG7txlRm.yN _DC554y9ZkBxpXykyCbLALcSRlK5l8c2LGMGOUGacEvcstnEE_v2MCHizeHf AKrDKQC1Hvu6hsoHAz4NPV7ynIOBTW6Wx4lNy5PRJRfaxfgErVPp_iZ19wND NtYxvSNx5f3ykHC1WrF1fJi3MT.AjRzdRUjFJI4ELgWHAmHMOVYikJ0DvN5i NaKszH800dXL3ZdU9_r0J_YHJq9QvnldsVLuW5FYTQ6Y.TFiwIlUtO7pRO9y D0H41rsV7VDI572K2g5_56nkzgBlaMX7Wk6IFkzzh10_Eeb4d5xGoAO0ODZw XUrXFQ7q8iIAps6FZR9qFO3ZO.Ewao7af2Ih6k._aONLUfNqp0dXXcAlN6LT 49WsO4Ag_tnk.T9qloasJJRSVtX6rqIsudIRrvoHQDZqxFNsv6H.cE.IbKW4 sjd5CKA-- Received: from [209.131.62.113] by web31810.mail.mud.yahoo.com via HTTP; Mon, 27 Aug 2012 13:38:35 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346094966.20031.YahooMailNeo@web31812.mail.mud.yahoo.com> Message-ID: <1346099915.51290.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Mon, 27 Aug 2012 13:38:35 -0700 (PDT) From: William Mills To: "Cantor, Scott" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1935884094-900357729-1346099915=:51290" Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 20:38:43 -0000 --1935884094-900357729-1346099915=:51290 Content-Type: text/plain; charset=us-ascii In my own implementation of this the mechanism asserts the authz and authn IDs, it's not changing that behavior. >________________________________ > From: "Cantor, Scott" >To: William Mills >Cc: "kitten@ietf.org" >Sent: Monday, August 27, 2012 12:42 PM >Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 > >On 8/27/12 3:16 PM, "William Mills" wrote: > >>No, I'm not assuming the IDP has the mapping, I'm assuming the local >>server knows how to map from an asserted federati0on ID to a local one. > >The point, though, is that (if I'm not misunderstanding), existing SASL >servers do this in part via the authz id. Your mechanism is inside that >code as a plugin, it's not meant to be driving the application-level >behavior. > >I'm sure I'll be corrected if I'm wrong. > >-- Scott > > > > --1935884094-900357729-1346099915=:51290 Content-Type: text/html; charset=us-ascii
In my own implementation of this the mechanism asserts the authz and authn IDs, it's not changing that behavior.


From: "Cantor, Scott" <cantor.2@osu.edu>
To: William Mills <wmills@yahoo-inc.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Monday, August 27, 2012 12:42 PM
Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05

On 8/27/12 3:16 PM, "William Mills" <wmills@yahoo-inc.com> wrote:

>No, I'm not assuming the IDP has the mapping, I'm assuming the local
>server knows how to map from an asserted federati0on ID to a local one.

The point, though, is that (if I'm not misunderstanding), existing SASL
servers do this in part via the authz id. Your mechanism is inside that
code as a plugin, it's not meant to be driving the application-level
behavior.

I'm sure I'll be corrected if I'm wrong.

-- Scott



--1935884094-900357729-1346099915=:51290-- From nico@cryptonector.com Mon Aug 27 22:08:07 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC2711E809C for ; Mon, 27 Aug 2012 22:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 F2D8WNzD2Qgt for ; Mon, 27 Aug 2012 22:08:06 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 7066811E808E for ; Mon, 27 Aug 2012 22:08:06 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id C4F4F1E05C for ; Mon, 27 Aug 2012 22:08:05 -0700 (PDT) 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; s=cryptonector.com; bh=sFAeVjs9KFbvdH1/TeJ8 6RJPs8M=; b=fE/XtRz1oqi+GpuTyz8IUR4XLkdF/2MYfE5ePl8xp3n98H7JR0C/ 4Bqml2IyMOCpduY+Y68wcdRiH0aOBtVWJ+pXjv0nUKaQTti+nFZEFVmvY18s1aKy O7PkMfjt48VBnnhOn6XIHPWyATBcoL5UjIxK0AwFVWmn4dANFiTRi/I= Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 946C11E059 for ; Mon, 27 Aug 2012 22:08:05 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5908933vbb.31 for ; Mon, 27 Aug 2012 22:08:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.92.4 with SMTP id ci4mr1810247veb.42.1346130484800; Mon, 27 Aug 2012 22:08:04 -0700 (PDT) Received: by 10.220.228.8 with HTTP; Mon, 27 Aug 2012 22:08:04 -0700 (PDT) Received: by 10.220.228.8 with HTTP; Mon, 27 Aug 2012 22:08:04 -0700 (PDT) In-Reply-To: <1346099915.51290.YahooMailNeo@web31810.mail.mud.yahoo.com> References: <1346094966.20031.YahooMailNeo@web31812.mail.mud.yahoo.com> <1346099915.51290.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Tue, 28 Aug 2012 00:08:04 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: multipart/alternative; boundary=047d7b5d34d65e2df604c84c6dca Cc: kitten@ietf.org Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 05:08:07 -0000 --047d7b5d34d65e2df604c84c6dca Content-Type: text/plain; charset=UTF-8 On Aug 27, 2012 3:38 PM, "William Mills" wrote: > > In my own implementation of this the mechanism asserts the authz and authn IDs, it's not changing that behavior. That's fine. Provided that the server/acceptor can substitute a different authz ID(s), which, of course, it must be free to do anyways given that what the server chooses to do is a local matter. Nico -- --047d7b5d34d65e2df604c84c6dca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Aug 27, 2012 3:38 PM, "William Mills" <wmills@yahoo-inc.com> wrote:
>
> In my own implementation of this the mechanism asserts the authz and a= uthn IDs, it's not changing that behavior.

That's fine.=C2=A0 Provided that the server/acceptor can substitute = a different authz ID(s), which, of course, it must be free to do anyways gi= ven that what the server chooses to do is a local matter.

Nico
--

--047d7b5d34d65e2df604c84c6dca-- From simon@josefsson.org Tue Aug 28 06:17:14 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4AC21E8034 for ; Tue, 28 Aug 2012 06:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 ueWU0gOb4-fh for ; Tue, 28 Aug 2012 06:17:13 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id E707311E809C for ; Tue, 28 Aug 2012 06:17:11 -0700 (PDT) Received: from latte (46.182.205.36.c.fiberdirekt.net [46.182.205.36]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7SDGxGw008917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Aug 2012 15:17:01 +0200 From: Simon Josefsson To: William Mills References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120828:cantor.2@osu.edu::tvTTfF0ejISpxzJc:FXQv X-Hashcash: 1:22:120828:kitten@ietf.org::QtOnQqcNgmJGeTAg:UJXn X-Hashcash: 1:22:120828:wmills@yahoo-inc.com::ioAdCKE6FHokV8k9:bGEj Date: Tue, 28 Aug 2012 15:16:51 +0200 In-Reply-To: <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> (William Mills's message of "Mon, 27 Aug 2012 10:17:14 -0700 (PDT)") Message-ID: <87txvn88cc.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 13:17:14 -0000 William Mills writes: > I think what you are arguing for is a model that supports a credential > that allows access to N mailboxes in the IMAP case and the ID sent by > the client selects the mailbox to access. Not quite -- the credential doesn't have to support the model. It is the authentication mechanism that should support the model, by being able to transfer the authorization identity. > The problem I think is we > don't have a way in OAuth to deal with understanding that the same > credential can be used with N different identities. It is the same for Kerberos and other mechanisms. That is why SASL provide for an authorization identity that is transfered from the client to the server by the mechanism. > If it's a single identity per credential then trusting the client is > wrong, you have to trust the credential.  You could tie the > authentication to an extra piece of information, but that kind of > breaks OAuth. > > OAuth can be tied to a specific URI, and it could work that way, but > that would require defining a URI for every type of endpoint which we > don't have. I don't see how OAuth is different from say Kerberos here. A Kerberos credential is used to perform the security negotiation, and the SASL authorization identity is used by the server to map to user to login as. OAuth would be similar. It may be that 90% of all implementations will reject a claimed authorization identity, but the protocol should still permit it. /Simon From wmills@yahoo-inc.com Tue Aug 28 07:31:27 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9C821F84F3 for ; Tue, 28 Aug 2012 07:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.556 X-Spam-Level: X-Spam-Status: No, score=-17.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 ceSjkM9tEaLe for ; Tue, 28 Aug 2012 07:31:26 -0700 (PDT) Received: from nm28.bullet.mail.ac4.yahoo.com (nm28.bullet.mail.ac4.yahoo.com [98.139.52.225]) by ietfa.amsl.com (Postfix) with SMTP id 9FA9421F84F2 for ; Tue, 28 Aug 2012 07:31:26 -0700 (PDT) Received: from [98.139.52.197] by nm28.bullet.mail.ac4.yahoo.com with NNFMP; 28 Aug 2012 14:31:23 -0000 Received: from [98.139.52.175] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 28 Aug 2012 14:31:23 -0000 Received: from [127.0.0.1] by omp1058.mail.ac4.yahoo.com with NNFMP; 28 Aug 2012 14:31:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 457323.91644.bm@omp1058.mail.ac4.yahoo.com Received: (qmail 32861 invoked by uid 60001); 28 Aug 2012 14:31:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346164282; bh=xfbYxxswUUZqSLUWSGhR+VKoJPXHoOyNVG7RIXBq3/Q=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Y2sKclNJ9Kimkww+0/88R63Qn+KA9XYpJnGz57rB3qBNYUx5mMeotxIvITg2d3oy+Yq3HrywIppJ6Db9SeFrERyeXD06eZGZUdEqXcqwab0XBRMjkWFAg+Fbnm45JTQ6zY19p72O1kY3AE6TJvVHm3cRbwucHuwINRJxXv05VXU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RiZ0nqOfq28WUh/gncHPNbhmsEnAGeFTJzdS++7Y3XmwvIb7njaI/wTPtuoioLWe+3Pp2I+0D3ZjhlWmwxPlAja2paNmF2YeRaAXItSjD+bKLz1kOalWPBJRLlxqhmLf+ObuyyUpPP/KJQsNBU3B5C3vSPMH0FXOzVwdBZ41AUE=; X-YMail-OSG: x6UfjXMVM1nYF91K_bXn1Q8YBSRB4wVAgw0q2HUpgCFPcyr ndc2LIRvpAnwXKXMuZcLxXlBp20BSIEkL9XIm12GJo7Mx7Y2sviwVbOtDVKE RMs8R5s283jLzj6flFEkbn55KsnBhTy.QdtnOHq0Thqq.RGQB.sbpIZvMYTT tMkUNYy_5gQUfpFEfZedej15VHTUmOh1BYereqYVJvbr2Z_hUJWq2YKfY_Bf F0JfduLH1u2xEJ5zBm91ulqUlQ_OYNJrWpaSSyl52mvzkhltJxV5n2zL0Iym OluvS1WRZYrADwpIiSmYar8WQ_WSUi0R.2aF4VKwsuZuDkEyjcYdT3EUdGnq 62z8RUmj.xMSUVf_xeDxFIzrAqPVOQAvl.dEqug3fnwLsvFUV2qwtti.vOOG n80hKLLtEonT.rKZtMqLQd255eJUGkQK_bx462cfheENlY0itFcs6rDLHotD HVvVIJQ-- Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Tue, 28 Aug 2012 07:31:22 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> Message-ID: <1346164282.32511.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Tue, 28 Aug 2012 07:31:22 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87txvn88cc.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 14:31:27 -0000 =0A=0AYou're asking for something that is exactly what is there already unl= ess I've written it completely wrong.=A0 That's what section 3.2.1 is all a= bout.=0A=0A3.2.1.=A0Mapping to SASL Identities=0A=0ASome OAuth mechanisms c= an provide both an authorization identity and an authentication identity. A= n example of this is OAuth 1.0a=A0[RFC5849]=A0where the consumer key (oauth= _consumer_key) identifies the entity using the token which equates to the S= ASL authentication identity, and is authenticated using the shared secret. = The authorization identity in the OAuth 1.0a case is carried in the token (= per the requirement above), which SHOULD be validated independently. The se= rver MAY use a consumer key, a value derived from it, or other comparable i= dentity in the OAuth authorization scheme as the SASL authentication identi= ty. If an appropriate authentication identity is not available the server M= UST use the authorization identity as the authentication identity.=0A=0A=0A= This does exactly what you want.=0A=0A=0A=0A=0A>___________________________= _____=0A> From: Simon Josefsson =0A>To: William Mills = =0A>Cc: "Cantor, Scott" ; "kitten@= ietf.org" =0A>Sent: Tuesday, August 28, 2012 6:16 AM=0A>S= ubject: Re: Comma vs. %x01=A0=A0Re:=A0=A0OAuth SASL draft -05=0A> =0A>Willi= am Mills writes:=0A>=0A>> I think what you are argui= ng for is a model that supports a credential=0A>> that allows access to N m= ailboxes in the IMAP case and the ID sent by=0A>> the client selects the ma= ilbox to access.=0A>=0A>Not quite -- the credential doesn't have to support= the model.=A0 It is=0A>the authentication mechanism that should support th= e model, by being=0A>able to transfer the authorization identity.=0A>=0A>> = The problem I think is we=0A>> don't have a way in OAuth to deal with under= standing that the same=0A>> credential can be used with N different identit= ies.=0A>=0A>It is the same for Kerberos and other mechanisms.=A0 That is wh= y SASL=0A>provide for an authorization identity that is transfered from the= client=0A>to the server by the mechanism.=0A>=0A>> If it's a single identi= ty per credential then trusting the client is=0A>> wrong, you have to trust= the credential.=A0 You could tie the=0A>> authentication to an extra piece= of information, but that kind of=0A>> breaks OAuth.=0A>>=0A>> OAuth can be= tied to a specific URI, and it could work that way, but=0A>> that would re= quire defining a URI for every type of endpoint which we=0A>> don't have.= =0A>=0A>I don't see how OAuth is different from say Kerberos here.=A0 A Ker= beros=0A>credential is used to perform the security negotiation, and the SA= SL=0A>authorization identity is used by the server to map to user to login = as.=0A>OAuth would be similar.=A0 It may be that 90% of all implementations= will=0A>reject a claimed authorization identity, but the protocol should s= till=0A>permit it.=0A>=0A>/Simon=0A>=0A>=0A> From simon@josefsson.org Tue Aug 28 16:02:43 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3186F21F8467 for ; Tue, 28 Aug 2012 16:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.851 X-Spam-Level: X-Spam-Status: No, score=-99.851 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 4yj4Zokz1V1o for ; Tue, 28 Aug 2012 16:02:39 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF9F11E8109 for ; Tue, 28 Aug 2012 16:02:34 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7SN2Swj005756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Aug 2012 01:02:29 +0200 From: Simon Josefsson To: William Mills References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120828:wmills@yahoo-inc.com::UtFAWkGxC6iIIx2X:5gZ7 X-Hashcash: 1:22:120828:kitten@ietf.org::Cj3gKFlYn2rnEQeR:I325 Date: Wed, 29 Aug 2012 01:02:27 +0200 In-Reply-To: <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> (William Mills's message of "Tue, 28 Aug 2012 07:31:22 -0700 (PDT)") Message-ID: <87a9xe62nw.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 23:02:43 -0000 I would prefer a model where the OAuth SASL mechanism can transfer a SASL authorization identity in addition to the OAuth credential. The authzid, if present and authorized by server policy, would override any authorization identity implied from the OAuth credential. What is the disadvantage with that approach? I believe this is the SASL model, compare RFC 4422: The client provides its credentials (which include or imply an authentication identity) and, optionally, a character string representing the requested authorization identity as part of the SASL exchange. When this character string is omitted or empty, the client is requesting to act as the identity associated with the credentials (e.g., the user is requesting to act as the authentication identity). I don't believe what I'm asking for is covered by the document now. Your section below is still relevant and required: it explains how a server derives the authorization identity when the SASL authorization identity is not present. This is the typical and normal situation. If you chose another path, I believe some discussion about the lack of support for a normal SASL authorization identity is needed. You could say that this mechanism does not support transferring a SASL authorization identity as described in RFC 4422, and that if the gs2-header contains an authzid, that MUST lead to authentication failure. /Simon William Mills writes: > You're asking for something that is exactly what is there already > unless I've written it completely wrong.  That's what section 3.2.1 is > all about. > > 3.2.1. Mapping to SASL Identities > > Some OAuth mechanisms can provide both an authorization identity and > an authentication identity. An example of this is OAuth > 1.0a [RFC5849] where the consumer key (oauth_consumer_key) identifies > the entity using the token which equates to the SASL authentication > identity, and is authenticated using the shared secret. The > authorization identity in the OAuth 1.0a case is carried in the token > (per the requirement above), which SHOULD be validated > independently. The server MAY use a consumer key, a value derived from > it, or other comparable identity in the OAuth authorization scheme as > the SASL authentication identity. If an appropriate authentication > identity is not available the server MUST use the authorization > identity as the authentication identity. > > > This does exactly what you want. > > > > >>________________________________ >> From: Simon Josefsson >>To: William Mills >>Cc: "Cantor, Scott" ; "kitten@ietf.org" >>Sent: Tuesday, August 28, 2012 6:16 AM >>Subject: Re: Comma vs. %x01  Re:  OAuth SASL draft -05 >> >>William Mills writes: >> >>> I think what you are arguing for is a model that supports a credential >>> that allows access to N mailboxes in the IMAP case and the ID sent by >>> the client selects the mailbox to access. >> >>Not quite -- the credential doesn't have to support the model.  It is >>the authentication mechanism that should support the model, by being >>able to transfer the authorization identity. >> >>> The problem I think is we >>> don't have a way in OAuth to deal with understanding that the same >>> credential can be used with N different identities. >> >>It is the same for Kerberos and other mechanisms.  That is why SASL >>provide for an authorization identity that is transfered from the client >>to the server by the mechanism. >> >>> If it's a single identity per credential then trusting the client is >>> wrong, you have to trust the credential.  You could tie the >>> authentication to an extra piece of information, but that kind of >>> breaks OAuth. >>> >>> OAuth can be tied to a specific URI, and it could work that way, but >>> that would require defining a URI for every type of endpoint which we >>> don't have. >> >>I don't see how OAuth is different from say Kerberos here.  A Kerberos >>credential is used to perform the security negotiation, and the SASL >>authorization identity is used by the server to map to user to login as. >>OAuth would be similar.  It may be that 90% of all implementations will >>reject a claimed authorization identity, but the protocol should still >>permit it. >> >>/Simon >> >> >> From cantor.2@osu.edu Tue Aug 28 16:08:47 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFC711E8109 for ; Tue, 28 Aug 2012 16:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] 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 LBo7rQc2XDfo for ; Tue, 28 Aug 2012 16:08:46 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 641D411E80FF for ; Tue, 28 Aug 2012 16:08:46 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q7SN8itk027558; Tue, 28 Aug 2012 19:08:45 -0400 Received: from CIO-KRC-HT03.osuad.osu.edu (2002:a46b:512b::a46b:512b) by CIO-KRC-HT01.osuad.osu.edu (2002:a46b:5125::a46b:5125) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 28 Aug 2012 19:08:44 -0400 Received: from CIO-TNC-D1MBX09.osuad.osu.edu ([fe80::1c1e:740:88e5:3701]) by CIO-KRC-HT03.osuad.osu.edu ([fe80::2572:c08d:8186:46a4%12]) with mapi id 14.02.0309.002; Tue, 28 Aug 2012 19:08:44 -0400 From: "Cantor, Scott" To: Simon Josefsson , William Mills Thread-Topic: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNhXExPPnDfIQILk6pd6AQN0mLIJdv2UOA Date: Tue, 28 Aug 2012 23:08:43 +0000 Message-ID: In-Reply-To: <87a9xe62nw.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.59] Content-Type: text/plain; charset="us-ascii" Content-ID: <8F043B5FA26E8E408871A8902168B107@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 23:08:47 -0000 On 8/28/12 7:02 PM, "Simon Josefsson" wrote: > >If you chose another path, I believe some discussion about the lack of >support for a normal SASL authorization identity is needed. You could >say that this mechanism does not support transferring a SASL >authorization identity as described in RFC 4422, and that if the >gs2-header contains an authzid, that MUST lead to authentication >failure. My concern was whether that was actually allowable and would work with existing GS2 code. I was concerned that imposing a constraint like that would actually break things. If that's not the case, then I'd say I'm of the opinion that it's suboptimal to be different for essentially no reason, but at least it's not fatal. -- Scott From lukeh@padl.com Tue Aug 28 16:14:54 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EDE11E80F9 for ; Tue, 28 Aug 2012 16:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599] 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 xOKCjBlQiCl2 for ; Tue, 28 Aug 2012 16:14:54 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE4511E80E7 for ; Tue, 28 Aug 2012 16:14:54 -0700 (PDT) Received: by us.padl.com with ESMTP id q7SNEmCi001481; Tue, 28 Aug 2012 19:14:51 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: Date: Wed, 29 Aug 2012 09:14:46 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Cantor, Scott" X-Mailer: Apple Mail (2.1485) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 23:14:55 -0000 > My concern was whether that was actually allowable and would work with > existing GS2 code. I was concerned that imposing a constraint like = that > would actually break things. If that's not the case, then I'd say I'm = of > the opinion that it's suboptimal to be different for essentially no > reason, but at least it's not fatal. A GS2 bridge such as the one included with Cyrus SASL, which knows = nothing about the underlying GSS mechanism, would not know that the = presence of an authorisation identity in the GS2 header should lead to = authentication failure. -- Luke= From simon@josefsson.org Tue Aug 28 16:25:21 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1663111E80F9 for ; Tue, 28 Aug 2012 16:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.853 X-Spam-Level: X-Spam-Status: No, score=-99.853 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 FEZzUcGVZMcb for ; Tue, 28 Aug 2012 16:25:20 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD2311E80E7 for ; Tue, 28 Aug 2012 16:25:19 -0700 (PDT) Received: from [192.168.1.42] (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7SNPDP0007039 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 29 Aug 2012 01:25:14 +0200 Message-ID: <1346196313.5073.3.camel@latte> From: Simon Josefsson To: Luke Howard Date: Wed, 29 Aug 2012 01:25:13 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 23:25:21 -0000 ons 2012-08-29 klockan 09:14 +1000 skrev Luke Howard: > > My concern was whether that was actually allowable and would work with > > existing GS2 code. I was concerned that imposing a constraint like that > > would actually break things. If that's not the case, then I'd say I'm of > > the opinion that it's suboptimal to be different for essentially no > > reason, but at least it's not fatal. > > > A GS2 bridge such as the one included with Cyrus SASL, which knows nothing about the underlying GSS mechanism, would not know that the presence of an authorisation identity in the GS2 header should lead to authentication failure. Exactly. If this mechanism doesn't follow the usual SASL/GSSAPI mechanism design pattern, it will have limitations which can cause problems. Not following usual design patterns is fine if there is a reason for it, but I haven't seen one so far. I hope and believe this is a misunderstanding that can be resolved with more discussion, and not some fundamental disagreement. /Simon From nico@cryptonector.com Tue Aug 28 20:43:32 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A0611E808A for ; Tue, 28 Aug 2012 20:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.018 X-Spam-Level: X-Spam-Status: No, score=-3.018 tagged_above=-999 required=5 tests=[AWL=-1.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Q3HDHt7mzJLU for ; Tue, 28 Aug 2012 20:43:32 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id F1A5511E8097 for ; Tue, 28 Aug 2012 20:43:31 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 57CDA2C2057 for ; Tue, 28 Aug 2012 20:43:31 -0700 (PDT) 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; s=cryptonector.com; bh=0EXRMIzIDKKGku5VpHu9 rE1uTwU=; b=n0QNOxurjeEVYht5epqkD/P1sn54W0AePBAiGVQbafvHmXukjwWC 75wSOa0bJpIau4Cn5St4MNlpQPnLlcjaP5ijIkIM1qAnlgajVT4HoPK3C6CLfXZ5 CJztjrC7UXkOxNQRMHy2IaLckE6MlEBBgO/vu3OU3gM9zaJL1EWUq5o= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 3D8462C2056 for ; Tue, 28 Aug 2012 20:43:31 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so343052pbb.31 for ; Tue, 28 Aug 2012 20:43:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.87.227 with SMTP id bb3mr612386pab.3.1346211810877; Tue, 28 Aug 2012 20:43:30 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 28 Aug 2012 20:43:30 -0700 (PDT) In-Reply-To: <87a9xe62nw.fsf@latte.josefsson.org> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> Date: Tue, 28 Aug 2012 22:43:30 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 03:43:32 -0000 On Tue, Aug 28, 2012 at 6:02 PM, Simon Josefsson wrote: > I would prefer a model where the OAuth SASL mechanism can transfer a > SASL authorization identity in addition to the OAuth credential. The > authzid, if present and authorized by server policy, would override any > authorization identity implied from the OAuth credential. What is the > disadvantage with that approach? I believe this is the SASL model, > compare RFC 4422: I'm confused. As a SASL/GS2 mechanism this would be definition carry an [optional] authz-id: it's in the gs2-header. So, of course the OAuth SASL/GS2 mechanism supports an authz-id assertion. It must. Nico -- From wmills@yahoo-inc.com Tue Aug 28 20:49:24 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B9A11E8097 for ; Tue, 28 Aug 2012 20:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.57 X-Spam-Level: X-Spam-Status: No, score=-17.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 hmmmRD1wXx4n for ; Tue, 28 Aug 2012 20:49:23 -0700 (PDT) Received: from nm11-vm0.bullet.mail.ac4.yahoo.com (nm11-vm0.bullet.mail.ac4.yahoo.com [98.139.53.196]) by ietfa.amsl.com (Postfix) with SMTP id 3873721F8514 for ; Tue, 28 Aug 2012 20:49:23 -0700 (PDT) Received: from [98.139.52.192] by nm11.bullet.mail.ac4.yahoo.com with NNFMP; 29 Aug 2012 03:49:20 -0000 Received: from [98.139.52.165] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 29 Aug 2012 03:49:19 -0000 Received: from [127.0.0.1] by omp1048.mail.ac4.yahoo.com with NNFMP; 29 Aug 2012 03:49:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 935725.88335.bm@omp1048.mail.ac4.yahoo.com Received: (qmail 28182 invoked by uid 60001); 29 Aug 2012 03:49:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346212159; bh=jdICQgfYghZkm/d2xSMDNY+FYYxwOUDJ2JKAS+xtX04=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ivSaCFyVZmEc1gUpX867UVBwQZoe6hYGNxcU7k2bKnDOPzFiN9eqd8yw03aXnXDZi2ArtdnPZV9LhRLZlncFQE/UUyLWzLlSgdt5YP33h901V2b27OhCqxhh5lE06d5x/Qt3KiroDpYo+LgZUSZsCFbcbc8FqT8wNMUEgG8fapc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=j/jO2AIFIcvzPQ3fXib0InhpidjJQQINNGiXLq7jrBwwMBF0BkbQd7qai9MJI9fsoVgnACazSoDFHo9D6IgginDI21OyIO5drFJ0DDts+E/w0nmVjPaq7Q6nviq/5YmkK2DZFhd7hdv7RoV0fqdu6dxRRWCcyXmcxn26rDIsT+c=; X-YMail-OSG: k3L5qaEVM1n5pKNE1gdsOWLwpXUu5aSlitcT0eHStVC4Iwy uIpM6ymSPfkT0M2HcgFH.dC6oxwigNJ2pHG97pXzmGWoNSmIVBIFMKmRmB9U sk.eGM884gaJosKccuvdNTEdz216fJDDzG1TmFiJEbkfZXxC8QvNlDdF5f41 GFylIDZuopfsNqgKTRfDKdxZwlCVfrgHl6Zh_ibM9zGl8rSOhjJmq3melSX7 aeHDRkvjxmQulB9hVb1ITBD6tuHng3EH7Ce12Gfobq0YdTPaQtssK50grGXD HttsZ6PORjZFrkThuEGqdS2iFGY3K2dtfDSEUYvGwhy2Tp_A8qFSUTf61cc1 UaukEkavoSL.5AoFnRZj1gFmhj6SKtyNwbrBNgpTeN2CFX0zVYjN6PoRalHK S6Oxxdmehp8.wb_OjXc5_JAFkcNG9IkXaj.s8d0bTjzk- Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Tue, 28 Aug 2012 20:49:18 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <1346087834.15646.YahooMailNeo__18475.4856549718$1346087853$gmane$org@web31805.mail.mud.yahoo.com> <87txvn88cc.fsf@latte.josefsson.org> <1346164282.32511.YahooMailNeo__29601.462573237$1346164300$gmane$org@web31807.mail.mud.yahoo.com> <87a9xe62nw.fsf@latte.josefsson.org> Message-ID: <1346212158.26772.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Tue, 28 Aug 2012 20:49:18 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87a9xe62nw.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-97885750-1346212158=:26772" Cc: "kitten@ietf.org" Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 03:49:24 -0000 --764183289-97885750-1346212158=:26772 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yes, what you are asking for is something I explicitly avoided and think we= should continue to avoid, because for things like OAuth 1.0a you have to d= efine a URI that can be signed which includes the name, and deciding the co= rrect URI format for an arbitrary resource to be authenticate with SASL isn= 't solved.=0A=0A=0AIt also would require is to be able to present those URI= s to an OAuth authorization endpoint to be explicitly approved.=0A=0AI'm av= oiding having to try to define a URI for POP, IMAP, and SMTP-send-mail like= the plague.=0A=0A=0A=0A=0A>________________________________=0A> From: Simo= n Josefsson =0A>To: William Mills =0A>Cc: "kitten@ietf.org" =0A>Sent: Tuesday, August 28= , 2012 4:02 PM=0A>Subject: Re: Comma vs. %x01 Re: OAuth SASL draft -05=0A= > =0A>I would prefer a model where the OAuth SASL mechanism can transfer a= =0A>SASL authorization identity in addition to the OAuth credential.=A0 The= =0A>authzid, if present and authorized by server policy, would override any= =0A>authorization identity implied from the OAuth credential.=A0 What is th= e=0A>disadvantage with that approach?=A0 I believe this is the SASL model,= =0A>compare RFC 4422:=0A>=0A>=A0 The client provides its credentials (whic= h include or imply an=0A>=A0 authentication identity) and, optionally, a c= haracter string=0A>=A0 representing the requested authorization identity a= s part of the SASL=0A>=A0 exchange.=A0 When this character string is omitt= ed or empty, the client=0A>=A0 is requesting to act as the identity associ= ated with the credentials=0A>=A0 (e.g., the user is requesting to act as t= he authentication identity).=0A>=0A>I don't believe what I'm asking for is = covered by the document now.=0A>=0A>Your section below is still relevant an= d required: it explains how a=0A>server derives the authorization identity = when the SASL authorization=0A>identity is not present.=A0 This is the typi= cal and normal situation.=0A>=0A>If you chose another path, I believe some = discussion about the lack of=0A>support for a normal SASL authorization ide= ntity is needed.=A0 You could=0A>say that this mechanism does not support t= ransferring a SASL=0A>authorization identity as described in RFC 4422, and = that if the=0A>gs2-header contains an authzid, that MUST lead to authentica= tion=0A>failure.=0A>=0A>/Simon=0A>=0A>William Mills = writes:=0A>=0A>> You're asking for something that is exactly what is there = already=0A>> unless I've written it completely wrong.=A0 That's what sectio= n 3.2.1 is=0A>> all about.=0A>>=0A>> 3.2.1.=A0Mapping to SASL Identities=0A= >>=0A>> Some OAuth mechanisms can provide both an authorization identity an= d=0A>> an authentication identity. An example of this is OAuth=0A>> 1.0a=A0= [RFC5849]=A0where the consumer key (oauth_consumer_key) identifies=0A>> the= entity using the token which equates to the SASL authentication=0A>> ident= ity, and is authenticated using the shared secret. The=0A>> authorization i= dentity in the OAuth 1.0a case is carried in the token=0A>> (per the requir= ement above), which SHOULD be validated=0A>> independently. The server MAY = use a consumer key, a value derived from=0A>> it, or other comparable ident= ity in the OAuth authorization scheme as=0A>> the SASL authentication ident= ity. If an appropriate authentication=0A>> identity is not available the se= rver MUST use the authorization=0A>> identity as the authentication identit= y.=0A>>=0A>>=0A>> This does exactly what you want.=0A>>=0A>>=0A>>=0A>>=0A>>= >________________________________=0A>>> From: Simon Josefsson =0A>>>To: William Mills =0A>>>Cc: "Cantor, S= cott" ; "kitten@ietf.org" =0A>>>Sent: T= uesday, August 28, 2012 6:16 AM=0A>>>Subject: Re: Comma vs. %x01=A0=A0Re:= =A0=A0OAuth SASL draft -05=0A>>> =0A>>>William Mills = writes:=0A>>>=0A>>>> I think what you are arguing for is a model that supp= orts a credential=0A>>>> that allows access to N mailboxes in the IMAP case= and the ID sent by=0A>>>> the client selects the mailbox to access.=0A>>>= =0A>>>Not quite -- the credential doesn't have to support the model.=A0 It = is=0A>>>the authentication mechanism that should support the model, by bein= g=0A>>>able to transfer the authorization identity.=0A>>>=0A>>>> The proble= m I think is we=0A>>>> don't have a way in OAuth to deal with understanding= that the same=0A>>>> credential can be used with N different identities.= =0A>>>=0A>>>It is the same for Kerberos and other mechanisms.=A0 That is wh= y SASL=0A>>>provide for an authorization identity that is transfered from t= he client=0A>>>to the server by the mechanism.=0A>>>=0A>>>> If it's a singl= e identity per credential then trusting the client is=0A>>>> wrong, you hav= e to trust the credential.=A0 You could tie the=0A>>>> authentication to an= extra piece of information, but that kind of=0A>>>> breaks OAuth.=0A>>>>= =0A>>>> OAuth can be tied to a specific URI, and it could work that way, bu= t=0A>>>> that would require defining a URI for every type of endpoint which= we=0A>>>> don't have.=0A>>>=0A>>>I don't see how OAuth is different from s= ay Kerberos here.=A0 A Kerberos=0A>>>credential is used to perform the secu= rity negotiation, and the SASL=0A>>>authorization identity is used by the s= erver to map to user to login as.=0A>>>OAuth would be similar.=A0 It may be= that 90% of all implementations will=0A>>>reject a claimed authorization i= dentity, but the protocol should still=0A>>>permit it.=0A>>>=0A>>>/Simon=0A= >>>=0A>>>=0A>>>=0A>=0A>=0A> --764183289-97885750-1346212158=:26772 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, what= you are asking for is something I explicitly avoided and think we should c= ontinue to avoid, because for things like OAuth 1.0a you have to define a U= RI that can be signed which includes the name, and deciding the correct URI= format for an arbitrary resource to be authenticate with SASL isn't solved= .

It also would r= equire is to be able to present those URIs to an OAuth authorization endpoi= nt to be explicitly approved.

I'm avoiding ha= ving to try to define a URI for POP, IMAP, and SMTP-send-mail like the plag= ue.

From: Simon Josefsson <simon@josefsson.org>
To: William Mills <wmills@yahoo-inc.com> =
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Tuesday, August 28, 2012 4:02 PM
Subject: Re: Comma vs. %x01 Re: OAuth SASL draft -05=

I would prefer a model where the OAuth SASL mechani= sm can transfer a
SASL authorization identity in addition to the OAuth c= redential.  The
authzid, if present and authorized by server policy= , would override any
authorization identity implied from the OAuth crede= ntial.  What is the
disadvantage with that approach?  I believ= e this is the SASL model,
compare RFC 4422:

  The client pr= ovides its credentials (which include or imply an
  authentication= identity) and, optionally, a character string
  representing the = requested authorization identity as part of the SASL
  exchange.&n= bsp; When this character string is omitted or empty, the client
  is requesting to act as the identity associated with the= credentials
  (e.g., the user is requesting to act as the authent= ication identity).

I don't believe what I'm asking for is covered by= the document now.

Your section below is still relevant and required= : it explains how a
server derives the authorization identity when the S= ASL authorization
identity is not present.  This is the typical and= normal situation.

If you chose another path, I believe some discuss= ion about the lack of
support for a normal SASL authorization identity i= s needed.  You could
say that this mechanism does not support trans= ferring a SASL
authorization identity as described in RFC 4422, and that= if the
gs2-header contains an authzid, that MUST lead to authentication=
failure.

/Simon

William Mills <wmills@yahoo-inc.com> writes:<= br>
> You're asking for something that is exactly what is there alrea= dy
> unless I've written it completely wrong.  That's what secti= on 3.2.1 is
> all about.
>
> 3.2.1. Mapping to SASL = Identities
>
> Some OAuth mechanisms can provide both an author= ization identity and
> an authentication identity. An example of this= is OAuth
> 1.0a [RFC5849] where the consumer key (oauth_co= nsumer_key) identifies
> the entity using the token which equates to = the SASL authentication
> identity, and is authenticated using the sh= ared secret. The
> authorization identity in the OAuth 1.0a case is c= arried in the token
> (per the requirement above), which SHOULD be va= lidated
> independently. The server MAY use a consumer key, a value d= erived from
> it, or other comparable identity in the OAuth authorization scheme as
> the SASL authentication identity. If an ap= propriate authentication
> identity is not available the server MUST = use the authorization
> identity as the authentication identity.
&= gt;
>
> This does exactly what you want.
>
>
>= ;
>
>>________________________________
>> From: Sim= on Josefsson <simon@josefsson.org>
>>To: William Mill= s <wmills@yahoo-inc.com>
>>Cc: "Cantor, Scott" <= ;ca= ntor.2@osu.edu>; "kitten@ietf.org" <kitten@ietf.org>
>>= ;Sent: Tuesday, August 28, 2012 6:16 AM
>>Subject: Re: Comma vs. %x01&nb= sp; Re:  OAuth SASL draft -05
>>
>>Willia= m Mills <wmills@yahoo-inc.com> writes:
>>
>&g= t;> I think what you are arguing for is a model that supports a credenti= al
>>> that allows access to N mailboxes in the IMAP case and t= he ID sent by
>>> the client selects the mailbox to access.
= >>
>>Not quite -- the credential doesn't have to support the= model.  It is
>>the authentication mechanism that should sup= port the model, by being
>>able to transfer the authorization iden= tity.
>>
>>> The problem I think is we
>>>= don't have a way in OAuth to deal with understanding that the same
>= >> credential can be used with N different identities.
>>
>>It is the same for Kerberos and other m= echanisms.  That is why SASL
>>provide for an authorization i= dentity that is transfered from the client
>>to the server by the = mechanism.
>>
>>> If it's a single identity per creden= tial then trusting the client is
>>> wrong, you have to trust t= he credential.  You could tie the
>>> authentication to an= extra piece of information, but that kind of
>>> breaks OAuth.=
>>>
>>> OAuth can be tied to a specific URI, and i= t could work that way, but
>>> that would require defining a UR= I for every type of endpoint which we
>>> don't have.
>&g= t;
>>I don't see how OAuth is different from say Kerberos here.&nb= sp; A Kerberos
>>credential is used to perform the security negoti= ation, and the SASL
>>authorization identity is used by the server to map to user to login as.
>>OAuth would be similar. = ; It may be that 90% of all implementations will
>>reject a claime= d authorization identity, but the protocol should still
>>permit i= t.
>>
>>/Simon
>>
>>
>>