From simon@josefsson.org Mon Sep 3 01: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 E44EC21F84C2 for ; Mon, 3 Sep 2012 01:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.856 X-Spam-Level: X-Spam-Status: No, score=-99.856 tagged_above=-999 required=5 tests=[AWL=0.053, 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 kCjX-CZ22Oea for ; Mon, 3 Sep 2012 01:18: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 7B22F21F8432 for ; Mon, 3 Sep 2012 01:18: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 q838ImLx020327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 3 Sep 2012 10:18:49 +0200 From: Simon Josefsson To: William Mills References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <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> <3008858F-8BF8-487F-B5EB-B3EB0D0BD35F@padl.com> <1346460964.79308.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346476111.52370.YahooMailNeo__8449.33422417871$1346476132$gmane$org@web31811.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120903:kitten@ietf.org::C/ZmB+ASlJT5VHzh:5uJ2 X-Hashcash: 1:22:120903:wmills@yahoo-inc.com::UKNjCPOzikaa9DOk:5iJz X-Hashcash: 1:22:120903:lukeh@padl.com::uPMi3JGa/sAibV0k:kC+c Date: Mon, 03 Sep 2012 10:18:45 +0200 In-Reply-To: <1346476111.52370.YahooMailNeo__8449.33422417871$1346476132$gmane$org@web31811.mail.mud.yahoo.com> (William Mills's message of "Fri, 31 Aug 2012 22:08:31 -0700 (PDT)") Message-ID: <87bohnwmca.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] -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 08:19:00 -0000 William Mills writes: > Draft -06 is posted.  Ir removes the user field, adds canonicalization > language, and once again fixes the examples to be current. Thanks! Below I quote a few sections and give some comments. I may have missed some recent emails in this thread, but here I try to focus on what is in the document rather than what may have been discussed/agreed out-of-band. 3. OAuth SASL Mechanism Specifications ... 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. This exchange is: This is the old text that I suggested a rewrite of in: http://thread.gmane.org/gmane.ietf.sasl/5935 It looks as if you acknowledged that, but the old text remains. I see that you added section 3.2.4, so maybe you could just remove some details here? Further, the example following the text above (and elsewhere in the document) is incorrect when it says "empty" since section 3.2.4 says the message contains %x01. Either make the message purely empty or use a term like "dummy message" instead of "empty message". 3.1. Initial Client Response [...] The client MUST send an authorization ID in the gs2-header. Is this MUST intentional? Normally authorization identities are not asserted in SASL so this would be unusual. I would remove this sentence. 3.1.2 o The "gs2-authzid" carries the authorization identity as specified in [RFC5801]. This MUST agree with the identity asserted in the OAuth credential. This also seems unusual -- why can't the authorization identity be orthogonal to the OAuth identity? I believe it has been suggested several times to say as little as possible about the authorization identity in this document, and I believe that continues to be a good advice. The semantics of SASL authorization identities follow from RFC 4422 and you would only need serious discussion of it when you are not following RFC 4422 recommendations. 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 server MAY use a consumer key, a value derived from it, or other comparable identity in the OAuth authorization scheme to allow SASL an authentication identity different from the authorization identity to be set. The OAuth 1.0a example in the second sentence seems to be missing something: it describes how OAuth 1.0a provide an authentication identity, but it does not describe how OAuth 1.0a provides for an authorization identity as far as I can tell? Adding a sentence after the second, that describe how OAuth 1.0a provides an authorization identity would help, and may help me understand the last sentence which I can't understand the meaning of right now. 5.2. OAuth 1.0a Authorization with Channel Binding ... y,a=user@example.com^A ... This uses a gs2-header cb-type of 'y' -- this seems wrong. If channel bindings are used (which is indicated by clients and servers having the OAUTH10A-PLUS mechanism type available), the cb-type should be 'p' and the cb type identifier should be present. Recall the meaning of "y" from RFC 5801: ;; "y" -> client supports CB, thinks the server ;; does not This only happens when the server does not advertise the *-PLUS mechanism. /Simon From wmills@yahoo-inc.com Mon Sep 3 15: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 30DDE21F858A for ; Mon, 3 Sep 2012 15:08: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.044, 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 DJqASyJknafU for ; Mon, 3 Sep 2012 15:08:32 -0700 (PDT) Received: from nm13.bullet.mail.sp2.yahoo.com (nm13.bullet.mail.sp2.yahoo.com [98.139.91.83]) by ietfa.amsl.com (Postfix) with SMTP id 5F4A821F84B6 for ; Mon, 3 Sep 2012 15:08:32 -0700 (PDT) Received: from [98.139.91.69] by nm13.bullet.mail.sp2.yahoo.com with NNFMP; 03 Sep 2012 22:08:29 -0000 Received: from [72.30.22.187] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 03 Sep 2012 22:08:29 -0000 Received: from [127.0.0.1] by omp1063.mail.sp2.yahoo.com with NNFMP; 03 Sep 2012 22:08:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 595689.43078.bm@omp1063.mail.sp2.yahoo.com Received: (qmail 18083 invoked by uid 60001); 3 Sep 2012 22:08:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346710109; bh=5x/Edfq6q4rpb6QxHyzwjUKbor+mtyH2rpKeMW3HU4E=; 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=XqFB3x6A5bJhF1LEKIwP8HiQSmPSAPNGcSz9gc0l30rGQzQWveAjX1fA6p0OSZN1DsqqRXnoWeEkrKZx4HhFY/twqa19ZPTFXS7oKPkojmVMy2Qa0esVEgrvOTw/MDMzq+lYbXNnTAoA1M3tSqwj8e0zarWNzqEpzYUMwDc+J5k= 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=NoxdG/bEDbDW6duV2cR/NUDEZm70GTvdNqNu4vC2h/A1DRCaQkcAGBVg7sqUVJ/hfpqR5iejZyXxll6QZsextbxz3VYc/ff+ro2ltfYBM82r9whdY9/nbRpGIB3kVo7HRmswpITZKHVddK1X3U8pmDIe8DxJeJGVKirZXCkaQyI=; X-YMail-OSG: TnUMBFUVM1mkGGJopJvPomdYHTMYaJze27saJmw2MxoCqhd vEOp0AMtWYl7DoOMxO5Lu6M9jGPn_UUDAGQ9SvJvSpoG.dX49YQWEW_vD5tf 3_DVAn6HZ_y9YYxYyeqrrN2v9PTeqgHeo256gOfyaCxvgPuTQc1KxLVE9T7D TZ7Tu90DuFLzIB.M75qjpcjv4.a_xhsNd7GWNOqQwSWCB56jhRf__mZxuGd3 90kU9LLBcswIyFcnU5s.tIg3LSjojtFIYmJFrF3n7Hlkkuv7._sJzvOBTzva cA4qsNkqcm9W6v01aH_V72Vty4m1UZK4_tRqn.sgTc9IDdOpFCY6cPhwkKrP kf2EElPY9LcHbLKxrWTa48A1_vUQwKo7mRqiWa25y.tAXnK.DQ2i_z0LtqNV vtmSJqKUhL77heKr4NBJexZIo68WT.yQGZk41IlNmfDTT3n0vvmBQfrDEFPv E6Zg2MluhkLljMBKazTKoyT3mV5MyXbEcdbekoplQ8kp_4HslMGB9mOJguXv QXTXWhZ2OB005VOHU1SLVSPCKglrSpTP6cxPRng-- Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Mon, 03 Sep 2012 15:08:28 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <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> <3008858F-8BF8-487F-B5EB-B3EB0D0BD35F@padl.com> <1346460964.79308.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346476111.52370.YahooMailNeo__8449.33422417871$1346476132$gmane$org@web31811.mail.mud.yahoo.com> <87bohnwmca.fsf@latte.josefsson.org> Message-ID: <1346710108.6729.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Mon, 3 Sep 2012 15:08:28 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87bohnwmca.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] -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: Mon, 03 Sep 2012 22:08:33 -0000 Comments inline below, thanks for the review.=0A=0A=0A>____________________= ____________=0A> From: Simon Josefsson =0A>To: William= Mills =0A>Cc: Luke Howard ; "kitten= @ietf.org" =0A>Sent: Monday, September 3, 2012 1:18 AM=0A= >Subject: Re: -06 posted Re: requirements/context/frustration Re: Comma vs.= %x01 Re: OAuth SASL draft -05=0A> =0A>William Mills = writes:=0A>=0A>> Draft -06 is posted.=A0 Ir removes the user field, adds c= anonicalization=0A>> language, and once again fixes the examples to be curr= ent.=0A>=0A>Thanks!=A0 Below I quote a few sections and give some comments.= =A0 I may=0A>have missed some recent emails in this thread, but here I try = to focus=0A>on what is in the document rather than what may have been=0A>di= scussed/agreed out-of-band.=0A>=0A>3.=A0 OAuth SASL Mechanism Specification= s=0A>...=0A>=A0=A0=A0In the case where authorization fails the server sends= an error=0A>=A0=A0=A0result, then client MUST then send an additional mess= age to the=0A>=A0=A0=A0server in order to allow the server to finish the ex= change.=A0 Some=0A>=A0=A0=A0protocols and common SASL implementations do no= t support both sending=0A>=A0=A0=A0a SASL message and finalizing a SASL neg= otiation, the additional=0A>=A0=A0=A0client message in the error case deals= with this problem.=A0 This=0A>=A0=A0=A0exchange is:=0A>=0A>This is the old= text that I suggested a rewrite of in:=0A>http://thread.gmane.org/gmane.ie= tf.sasl/5935 It looks as if you=0A>acknowledged that, but the old text rema= ins.=A0 I see that you added=0A>section 3.2.4, so maybe you could just remo= ve some details here?=0A>=0A>Further, the example following the text above = (and elsewhere in the=0A>document) is incorrect when it says "empty" since = section 3.2.4 says the=0A>message contains %x01.=A0 Either make the message= purely empty or use a=0A>term like "dummy message" instead of "empty messa= ge".=0A=0A=0AI'll change it to "dummy message".=A0 Works for me.=0A=0A=0A>= =0A>3.1.=A0 Initial Client Response=0A>=0A>=A0=A0=A0[...] The client MUST s= end an authorization ID in the gs2-header.=0A>=0A>Is this MUST intentional?= =A0 Normally authorization identities are not=0A>asserted in SASL so this w= ould be unusual.=A0 I would remove this=0A>sentence.=0A=0AYes, because we w= ant to have the plain text username available.=0A=0A=0A>=0A>3.1.2=0A>=0A>= =A0=A0=A0o=A0 The "gs2-authzid" carries the authorization identity as speci= fied=0A>=A0 =A0 =A0 in [RFC5801].=A0 This MUST agree with the identity asse= rted in the=0A>=A0 =A0 =A0 OAuth credential.=0A>=0A>This also seems unusual= -- why can't the authorization identity be=0A>orthogonal to the OAuth iden= tity?=A0 I believe it has been suggested=0A>several times to say as little = as possible about the authorization=0A>identity in this document, and I bel= ieve that continues to be a good=0A>advice.=A0 The semantics of SASL author= ization identities follow from RFC=0A>4422 and you would only need serious = discussion of it when you are not=0A>following RFC 4422 recommendations.=0A= >=0A>3.2.1.=A0 Mapping to SASL Identities=0A>=0A>=A0=A0=A0Some OAuth mechan= isms can provide both an authorization identity and=0A>=A0=A0=A0an authenti= cation identity.=A0 An example of this is OAuth 1.0a=0A>=A0=A0=A0[RFC5849] = where the consumer key (oauth_consumer_key) identifies the=0A>=A0=A0=A0enti= ty using the token which equates to the SASL authentication=0A>=A0=A0=A0ide= ntity, and is authenticated using the shared secret.=A0 The server=0A>=A0= =A0=A0MAY use a consumer key, a value derived from it, or other comparable= =0A>=A0=A0=A0identity in the OAuth authorization scheme to allow SASL an=0A= >=A0=A0=A0authentication identity different from the authorization identity= to=0A>=A0=A0=A0be set.=0A>=0A>The OAuth 1.0a example in the second sentenc= e seems to be missing=0A>something: it describes how OAuth 1.0a provide an = authentication=0A>identity, but it does not describe how OAuth 1.0a provide= s for an=0A>authorization identity as far as I can tell?=A0 Adding a senten= ce after=0A>the second, that describe how OAuth 1.0a provides an authorizat= ion=0A>identity would help, and may help me understand the last sentence wh= ich=0A>I can't understand the meaning of right now.=0AThe last sentence of = 3.2 above 3.2.1 is "The authorization scheme MUST =0Acarry the user ID to b= e used as the authorization identity (identity to =0Aact as). The server MU= ST use the ID obtained from the credential as the =0Auser being authorized.= "=0A=0AShould that sentence move into 3.2.1?=0A=0A=0A>=0A>5.2.=A0 OAuth 1.0= a Authorization with Channel Binding=0A>...=0A>=A0=A0=A0y,a=3Duser@example.= com^A=0A>...=0A>=0A>This uses a gs2-header cb-type of 'y' -- this seems wro= ng.=A0 If channel=0A>bindings are used (which is indicated by clients and s= ervers having the=0A>OAUTH10A-PLUS mechanism type available), the cb-type s= hould be 'p' and=0A>the cb type identifier should be present.=A0 Recall the= meaning of "y"=0A>from RFC 5801:=0A>=0A=0AI *KNEW* I had to have gotten so= mething wrong in CB.=A0 Will fix that.=0A=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 ;; "y" -> client supports CB, thinks the server=0A>=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ;;=A0 =A0 =A0 =A0 =A0=A0=A0does not=0A>= =0A>This only happens when the server does not advertise the *-PLUS=0A>mech= anism.=0A>=0A>/Simon=0A>=0A>=0A> From nico@cryptonector.com Mon Sep 3 15:32: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 9D95221F8565 for ; Mon, 3 Sep 2012 15:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=-0.832, 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 ZczseaQBZ4R0 for ; Mon, 3 Sep 2012 15:32:11 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 256D621F8551 for ; Mon, 3 Sep 2012 15:32:11 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id DA57867C072 for ; Mon, 3 Sep 2012 15:32: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=sTamUxTixC8coxp3A8OV n3RFsow=; b=qGNo8sMqg8hETKdQY3rQu0UpbJbwBtenGRe0OiFlBl9Gd4sh4Rw/ 58QSpQkR96XM3jTDtEUIDC1DJRPy5J5CBtG4FxeLo0pJgvSQcnji6sxVoSa/ur3M 4a1K+ZjHSsQgd7fBcV2ztZ2wisGUvPse4dklFA9JSC0pfJMcueRCKAM= 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-a74.g.dreamhost.com (Postfix) with ESMTPSA id C00D667C014 for ; Mon, 3 Sep 2012 15:32:10 -0700 (PDT) Received: by dadf8 with SMTP id f8so3716104dad.31 for ; Mon, 03 Sep 2012 15:32:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.85.133 with SMTP id h5mr32058960paz.10.1346711530376; Mon, 03 Sep 2012 15:32:10 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Mon, 3 Sep 2012 15:32:10 -0700 (PDT) In-Reply-To: <1346710108.6729.YahooMailNeo@web31804.mail.mud.yahoo.com> References: <1346084466.40894.YahooMailNeo@web31806.mail.mud.yahoo.com> <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> <3008858F-8BF8-487F-B5EB-B3EB0D0BD35F@padl.com> <1346460964.79308.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346476111.52370.YahooMailNeo__8449.33422417871$1346476132$gmane$org@web31811.mail.mud.yahoo.com> <87bohnwmca.fsf@latte.josefsson.org> <1346710108.6729.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Mon, 3 Sep 2012 17:32:10 -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] -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 22:32:11 -0000 On Mon, Sep 3, 2012 at 5:08 PM, William Mills wrote: >>3.1. Initial Client Response >> >> [...] The client MUST send an authorization ID in the gs2-header. >> >>Is this MUST intentional? Normally authorization identities are not >>asserted in SASL so this would be unusual. I would remove this >>sentence. > > Yes, because we want to have the plain text username available. Ryan wants it, yes, but SASL makes it strictly OPTIONAL, which means that it must be optional here as well. (Ryan has already indicated that he understands that this means that he must reject connections/authentications from clients that a) do not provide an authz-id, and b) from whose authcid his software cannot derive a suitable authz-id.) (There is no subtext here. The semantics of SASL cannot be changed by a SASL mechanism. That's a hard constraint on your mechanism. Note too that this has nothing to do with gs2 -- we're dealing with SASL semantics, not GSS semantics, so RFC4422 applies.) >>3.1.2 >> >> o The "gs2-authzid" carries the authorization identity as specified >> in [RFC5801]. This MUST agree with the identity asserted in the >> OAuth credential. >> >>This also seems unusual -- why can't the authorization identity be >>orthogonal to the OAuth identity? I believe it has been suggested >>several times to say as little as possible about the authorization >>identity in this document, and I believe that continues to be a good >>advice. The semantics of SASL authorization identities follow from RFC >>4422 and you would only need serious discussion of it when you are not >>following RFC 4422 recommendations. Indeed, it is not correct to say that the authz-id must agree the authcid. The two concepts have radically different semantics. William, I *strongly* suggest that you just say *nothing* about what the authz-id must be. Indeed, it's not a suggestion. You must say nothing about the authz-id's form here, for that is not the mechanism's place. The authz-id namespace and meaning is defined by the application protocol, not the mechanism. >>3.2.1. Mapping to SASL Identities You probably mean mapping from authcid to authz-id. This too you cannot say anything about (see above). Nico -- From simon@josefsson.org Tue Sep 4 00: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 AFA4921F84F6 for ; Tue, 4 Sep 2012 00:20:37 -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 Si9zIBP26wXc for ; Tue, 4 Sep 2012 00:20:37 -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 B504621F8470 for ; Tue, 4 Sep 2012 00:20:35 -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 q847KQk3019999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 4 Sep 2012 09:20:28 +0200 From: Simon Josefsson To: William Mills References: <1346084466.40894.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> <3008858F-8BF8-487F-B5EB-B3EB0D0BD35F@padl.com> <1346460964.79308.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346476111.52370.YahooMailNeo__8449.33422417871$1346476132$gmane$org@web31811.mail.mud.yahoo.com> <87bohnwmca.fsf@latte.josefsson.org> <1346710108.6729.YahooMailNeo__16099.967438686$1346710121$gmane$org@web31804.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120904:kitten@ietf.org::YYvlV73Tz/S09Pm4:50BI X-Hashcash: 1:22:120904:wmills@yahoo-inc.com::r0oURDa9sSSFqgJt:qor1 Date: Tue, 04 Sep 2012 09:20:24 +0200 In-Reply-To: <1346710108.6729.YahooMailNeo__16099.967438686$1346710121$gmane$org@web31804.mail.mud.yahoo.com> (William Mills's message of "Mon, 3 Sep 2012 15:08:28 -0700 (PDT)") Message-ID: <87mx16s18n.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] -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 07:20:37 -0000 William Mills writes: >>3.1.  Initial Client Response >> >>   [...] The client MUST send an authorization ID in the gs2-header. >> >>Is this MUST intentional?  Normally authorization identities are not >>asserted in SASL so this would be unusual.  I would remove this >>sentence. > > Yes, because we want to have the plain text username available. The SASL framework doesn't have any concept of usernames, so if you want to transfer a "username" from the client to the server you need a separate field for that in the mechanism. SCRAM does this, so that is an acceptable route. However, I'm not certain you actually mean "username" here. Maybe you really mean authorization identity? Or do you mean the authentication identity? Sometimes usernames and authentication identities are used interchangeable but I'm not certain this is the case here. The SASL framework says the authzid is optional and that it is asserted by the client application. It shouldn't be used for something mechanism internal. I'll see if I can re-read Ryan's motivation for the username field. I'm thinking that perhaps he is really after an authzid field, and if the authzid field is not present, he has to guess which authorization identity is intended (or fail if he cannot guess). I believe this usage would be in line with the SASL model, although would require some user training because users normally doesn't specify an authzid. That's fine though. This approach is consistent with the protocol syntax in -06, but the text describing how the syntax should be used is a bit off currently. So I don't think you actually want a username field, just fix some text. >>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 server >>   MAY use a consumer key, a value derived from it, or other comparable >>   identity in the OAuth authorization scheme to allow SASL an >>   authentication identity different from the authorization identity to >>   be set. >> >>The OAuth 1.0a example in the second sentence seems to be missing >>something: it describes how OAuth 1.0a provide an authentication >>identity, but it does not describe how OAuth 1.0a provides for an >>authorization identity as far as I can tell?  Adding a sentence after >>the second, that describe how OAuth 1.0a provides an authorization >>identity would help, and may help me understand the last sentence which >>I can't understand the meaning of right now. > The last sentence of 3.2 above 3.2.1 is "The authorization scheme MUST > carry the user ID to be used as the authorization identity (identity to > act as). The server MUST use the ID obtained from the credential as the > user being authorized." > > Should that sentence move into 3.2.1? I must admit that the sentence doesn't make sense to me. The (SASL) authorization identity should be transferred from client to server without modification (modulo character set encodings). It is asserted by the client and consumed by the server. Usually it is not related to the credential type at all. Thus, saying that another field in the credential MUST be used as the SASL authorization identity seems quite far from how the SASL framework is designed. I don't see why you would design it this way -- it seems overly complex for no gain that I have understood so far. Hmm. Perhaps at this point it would be more productive if one of us usual GSSAPI/SASL suspects modify your draft into something that makes sense in the GSSAPI/SASL model and then you can check if it works for you in the OAuth world? >>5.2.  OAuth 1.0a Authorization with Channel Binding >>... >>   y,a=user@example.com^A >>... >> >>This uses a gs2-header cb-type of 'y' -- this seems wrong.  If channel >>bindings are used (which is indicated by clients and servers having the >>OAUTH10A-PLUS mechanism type available), the cb-type should be 'p' and >>the cb type identifier should be present.  Recall the meaning of "y" >>from RFC 5801: >> > > I *KNEW* I had to have gotten something wrong in CB.  Will fix that. Great. I suggest to use the 'tls-unique' channel binding type, it is what SCRAM and GS2 prefers, with a fallback to 'tls-server-end-point'. Compare section 6.1 of RFC 5802. You probably need a similar section in this document. /Simon From simon@josefsson.org Tue Sep 4 00:51: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 CF7A221F8512 for ; Tue, 4 Sep 2012 00:51:52 -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 MypLNuOQ82fL for ; Tue, 4 Sep 2012 00:51:52 -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 0748E21F8505 for ; Tue, 4 Sep 2012 00:51:51 -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 q847phFW021281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 4 Sep 2012 09:51:45 +0200 From: Simon Josefsson To: William Mills References: <1346084466.40894.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> <3008858F-8BF8-487F-B5EB-B3EB0D0BD35F@padl.com> <1346460964.79308.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346476111.52370.YahooMailNeo__8449.33422417871$1346476132$gmane$org@web31811.mail.mud.yahoo.com> <87bohnwmca.fsf@latte.josefsson.org> <1346710108.6729.YahooMailNeo__16099.967438686$1346710121$gmane$org@web31804.mail.mud.yahoo.com> <87mx16s18n.fsf__6744.62316460467$1346743249$gmane$org@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120904:wmills@yahoo-inc.com::enFTNH2PysLPnJ5S:3b5K X-Hashcash: 1:22:120904:kitten@ietf.org::MCZ7Z64kCJnxgGcF:HoCK Date: Tue, 04 Sep 2012 09:51:41 +0200 In-Reply-To: <87mx16s18n.fsf__6744.62316460467$1346743249$gmane$org@latte.josefsson.org> (Simon Josefsson's message of "Tue, 04 Sep 2012 09:20:24 +0200") Message-ID: <87ipburzsi.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] -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 07:51:52 -0000 Simon Josefsson writes: > I'll see if I can re-read Ryan's motivation for the username field. Having re-read some emails, I believe Ryan really wants the usual SASL authcid/authzid semantics. It should be similar to how PLAIN or SCRAM works today. Please correct me below if this is wrong. The requirements as I understand them are: 1) The server must know the IMAP/SMTP/etc user. This is the authorization identity, authzid. Normally in SASL the authzid is not present, but implied from the authentication identity. Since authzid's are often absent, it becomes important for the server to know the authcid, because the server has to infer the authzid from the authcid when the authzid is not specified. that creates another requirement: 2) The server must know the identity of the OAuth bearer token owner. This is the authentication identity (authcid). This must be available to the server. It doesn't have to be sent by the mechanism though (see below). Right now I don't believe -06 describes how the server knows the authentication identity and that is the issue. I think there are two design options: 1) The server finds the authcid by using the OAuth bearer token as a key in some table to find out who owns that particular token. This may not be practical in all OAuth implementations. (Of course, it should work for all OAuth schemes not just bearer tokens.) 2) The client must provide the OAuth credential owner in another field, i.e., the infamous "user"-field. The server verifies the bearer token using that user field. The next step is to find the IMAP/SMTP user, which follows the usual SASL pattern. There is complexity in that OAuth credentials can be issued from a user X to someone else Y and that Y can then effectively impersonate X (until revoked by X). However I don't think this complexity matters for the SASL/GSSAPI mechanism. Whether the SASL client endpoint is X or Y is outside the scope of the SASL model, the logical SASL client endpoint from SASL's point of view is X. Arguable, the information about Y can be useful to servers, and maybe GSS-API naming attributes can be used here, however it is not strictly needed as I see it. /Simon From wmills@yahoo-inc.com Tue Sep 4 08:32: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 B416121F864A for ; Tue, 4 Sep 2012 08:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[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 Rqvm3ZNA6kzW for ; Tue, 4 Sep 2012 08:32:07 -0700 (PDT) Received: from nm20-vm0.bullet.mail.ac4.yahoo.com (nm20-vm0.bullet.mail.ac4.yahoo.com [98.139.53.214]) by ietfa.amsl.com (Postfix) with SMTP id 63D3321F863C for ; Tue, 4 Sep 2012 08:32:06 -0700 (PDT) Received: from [98.139.52.196] by nm20.bullet.mail.ac4.yahoo.com with NNFMP; 04 Sep 2012 15:32:02 -0000 Received: from [98.139.52.182] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 04 Sep 2012 15:32:02 -0000 Received: from [127.0.0.1] by omp1065.mail.ac4.yahoo.com with NNFMP; 04 Sep 2012 15:32:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 222497.39950.bm@omp1065.mail.ac4.yahoo.com Received: (qmail 58886 invoked by uid 60001); 4 Sep 2012 15:32:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346772721; bh=JpZ4qFJzJa10znbjeDmqMTbL9iNwo+CqbKsSNrWJD5w=; 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=G9NLt4qjwy92E0OCW3Is8ZZ2PgSou7T+pAxbWQSIJLA804YKUMLpXyVL+1laJTzPqZcr+crHoaLOIKdIDJSy7VeiGpi1LzT7oujlM5/Uvv1DAJw0z+bPGguN/+xKxP1pIwn50ty/P7Uly7ae3asV8EofMnAhrUh6MR/LoU/qjb4= 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=REyt1sYweEOWiOupk8ZhyLrf/3eE7kPwH5cjw0GPyJE+VGJ5PlbTSGPTvKg1qSpjpSkw9dvZu5CXNhJpLuz56zt2j/rvTZNxXg+/TW+UMXU4U3p4cUrjSth6UI/X6MlBAQE09vNrMHcBrrD2XkKwL0wBI90F4ocBpvYwpgXlc3o=; X-YMail-OSG: UgcJKcwVM1knlPYZ789uScfA9O4EJL.Bc7faFRmbog.leZS .Ygo7_2wX2dxFlDmCr1ymZ1O1WiOd6rk4RE6GRC4sMhgMYEmeo9S6EzAbrBj idK4WTyTKbHUrV0bX.tD3Kv7EjzrvEhCibhLlT0MyLYtiPuw9D9s2t17MAUo y0FfJGwL4b.NornQJ1wb46gVDNwbKGZPo1uZPNWCwnw.zGq.K50Rq5uTk7OA vKRD9fU6nCLe3cPyeyFbMn9xw662DWJxWDn6I7aMrz7rRj6QjmmdobZkDMux T.7h89TYtgbtcJlYhkx6rZXid8T380DA782073LURF1ZxJGhXjF4AT7ZYVd9 Jk7Eb5WjOR.SHnzme_k7_PkDYIStTPjy_bNUDpS4pDNbx0cDjH2t14FjnKOa yhd6y2GjSG89pO3datVjhWw1oH4Xof6Nle3K1PWE6D83G Received: from [99.31.212.42] by web31808.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 08:32:01 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346084466.40894.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> <3008858F-8BF8- 487F-B5EB-B3EB0D0BD35F@padl.com> <1346460964.79308.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346476111.52370.YahooMailNeo__8449.33422417871$1346476132$gmane$org@web31811.mail.mud.yahoo.com> <87bohnwmca.fsf@latte.josefsson.org> <1346710108.6729.YahooMailNeo__16099.967438686$1346710121$gmane$org@web31804.mail.mud.yahoo.com> <87mx16s18n.fsf__6744.62316460467$1346743249$gmane$org@latte.josefsson.org> <87ipburzsi.fsf@latte.josefsson.org> Message-ID: <1346772721.51675.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 08:32:01 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87ipburzsi.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-205304778-1346772721=:51675" Cc: "kitten@ietf.org" Subject: Re: [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: Tue, 04 Sep 2012 15:32:08 -0000 --258328648-205304778-1346772721=:51675 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I've been having a side conversation with Nico.=A0 The MUST that used to be= there on authzid is removed.=A0 Servers like Ryan's use case can put in th= eir service docs that authzid is required, and it will become the de facto = usage standard for things like IMAP even if we don't write that into the do= c.=0A=0AWe're also word-smithing the identity mapping language.=0A=0AThe cu= rrent draft, in the paragraph before 3.2.1, states that the authzid is deri= ved from the auth token.=A0 Is that not clear enough?=A0 3.2.1 is intended = to describe how to get authcid when there is one available.=A0 For all prac= tical purposes a desktop client does not have a useful authcid, it's the eq= uivalent of a user agent string if present.=A0 Authcid can be determined fr= om the token or the client id in 3 party cases.=0A=0A-bill=0A=0A=0A=0A=0A= =0A>________________________________=0A> From: Simon Josefsson =0A>To: William Mills =0A>Cc: "kitten@ietf.= org" =0A>Sent: Tuesday, September 4, 2012 12:51 AM=0A>Sub= ject: Re: -06 posted Re: requirements/context/frustration Re: Comma vs. %x0= 1 Re: OAuth SASL draft -05=0A> =0A>Simon Josefsson wr= ites:=0A>=0A>> I'll see if I can re-read Ryan's motivation for the username= field.=0A>=0A>Having re-read some emails, I believe Ryan really wants the = usual SASL=0A>authcid/authzid semantics.=A0 It should be similar to how PLA= IN or SCRAM=0A>works today.=A0 Please correct me below if this is wrong.=A0= The=0A>requirements as I understand them are:=0A>=0A>1) The server must kn= ow the IMAP/SMTP/etc user.=A0 This is the=0A>authorization identity, authzi= d.=A0 Normally in SASL the authzid is not=0A>present, but implied from the = authentication identity.=A0 Since authzid's=0A>are often absent, it becomes= important for the server to know the=0A>authcid, because the server has to= infer the authzid from the authcid=0A>when the authzid is not specified.= =0A>=0A>that creates another requirement:=0A>=0A>2) The server must know th= e identity of the OAuth bearer token owner.=0A>This is the authentication i= dentity (authcid).=A0 This must be available=0A>to the server.=A0 It doesn'= t have to be sent by the mechanism though (see=0A>below).=0A>=0A>Right now = I don't believe -06 describes how the server knows the=0A>authentication id= entity and that is the issue.=0A>=0A>I think there are two design options:= =0A>=0A>1) The server finds the authcid by using the OAuth bearer token as = a key=0A>in some table to find out who owns that particular token.=A0 This = may not=0A>be practical in all OAuth implementations.=A0 (Of course, it sho= uld work=0A>for all OAuth schemes not just bearer tokens.)=0A>=0A>2) The cl= ient must provide the OAuth credential owner in another field,=0A>i.e., the= infamous "user"-field.=A0 The server verifies the bearer token=0A>using th= at user field.=A0 The next step is to find the IMAP/SMTP user,=0A>which fol= lows the usual SASL pattern.=0A>=0A>There is complexity in that OAuth crede= ntials can be issued from a user=0A>X to someone else Y and that Y can then= effectively impersonate X (until=0A>revoked by X).=A0 However I don't thin= k this complexity matters for the=0A>SASL/GSSAPI mechanism.=A0 Whether the = SASL client endpoint is X or Y is=0A>outside the scope of the SASL model, t= he logical SASL client endpoint=0A>from SASL's point of view is X.=A0 Argua= ble, the information about Y can=0A>be useful to servers, and maybe GSS-API= naming attributes can be used=0A>here, however it is not strictly needed a= s I see it.=0A>=0A>/Simon=0A>=0A>=0A> --258328648-205304778-1346772721=:51675 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I've been= having a side conversation with Nico.  The MUST that used to be there= on authzid is removed.  Servers like Ryan's use case can put in their= service docs that authzid is required, and it will become the de facto usa= ge standard for things like IMAP even if we don't write that into the doc.<= br>
We're also word-smithing the identity mapping language.

The c= urrent draft, in the paragraph before 3.2.1, states that the authzid is der= ived from the auth token.  Is that not clear enough?  3.2.1 is in= tended to describe how to get authcid when there is one available.  Fo= r all practical purposes a desktop client does not have a useful authcid, i= t's the equivalent of a user agent string if present.  Authcid can be = determined from the token or the client id in 3 party cases.

-bill

= From: Simon Josefsson <s= imon@josefsson.org>
To:= William Mills <wmills@yahoo-inc.com>
Cc: "kitten@ietf.org" <kitten@ietf.org> Sent: Tuesday, September= 4, 2012 12:51 AM
Subject: Re: -06 p= osted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SAS= L draft -05

Simon Josefsson <simon@josefsson.o= rg> writes:

> I'll see if I can re-read Ryan's motivation = for the username field.

Having re-read some emails, I believe Ryan r= eally wants the usual SASL
authcid/authzid semantics.  It should be= similar to how PLAIN or SCRAM
works today.  Please correct me belo= w if this is wrong.  The
requirements as I understand them are:
=
1) The server must know the IMAP/SMTP/etc user.  This is the
au= thorization identity, authzid.  Normally in SASL the authzid is notpresent, but implied from the authentication identity.  Since authzid= 's
are often absent, it becomes important for the server to know the
authcid, because the server has to infer the authzid from the authc= id
when the authzid is not specified.

that creates another requir= ement:

2) The server must know the identity of the OAuth bearer toke= n owner.
This is the authentication identity (authcid).  This must = be available
to the server.  It doesn't have to be sent by the mech= anism though (see
below).

Right now I don't believe -06 describes= how the server knows the
authentication identity and that is the issue.=

I think there are two design options:

1) The server finds th= e authcid by using the OAuth bearer token as a key
in some table to find= out who owns that particular token.  This may not
be practical in = all OAuth implementations.  (Of course, it should work
for all OAut= h schemes not just bearer tokens.)

2) The client must provide the OA= uth credential owner in another field,
i.e., the infamous "user"-field.  The server verifies the bearer token
using that use= r field.  The next step is to find the IMAP/SMTP user,
which follow= s the usual SASL pattern.

There is complexity in that OAuth credenti= als can be issued from a user
X to someone else Y and that Y can then ef= fectively impersonate X (until
revoked by X).  However I don't thin= k this complexity matters for the
SASL/GSSAPI mechanism.  Whether t= he SASL client endpoint is X or Y is
outside the scope of the SASL model= , the logical SASL client endpoint
from SASL's point of view is X. = Arguable, the information about Y can
be useful to servers, and maybe G= SS-API naming attributes can be used
here, however it is not strictly ne= eded as I see it.

/Simon


--258328648-205304778-1346772721=:51675-- From cantor.2@osu.edu Tue Sep 4 08:38: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 3F4EC21F8648 for ; Tue, 4 Sep 2012 08:38:50 -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=[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 EQTaNVCTYhDG for ; Tue, 4 Sep 2012 08:38:49 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id A7C5C21F8568 for ; Tue, 4 Sep 2012 08:38:49 -0700 (PDT) Received: from mail208-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 15:38:44 +0000 Received: from mail208-ch1 (localhost [127.0.0.1]) by mail208-ch1-R.bigfish.com (Postfix) with ESMTP id 2E07548017C; Tue, 4 Sep 2012 15:38:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zzbb2dI98dI9371Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1155h1151h) Received-SPF: pass (mail208-ch1: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail208-ch1 (localhost.localdomain [127.0.0.1]) by mail208-ch1 (MessageSwitch) id 1346773122999598_4278; Tue, 4 Sep 2012 15:38:42 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail208-ch1.bigfish.com (Postfix) with ESMTP id F228A4C0051; Tue, 4 Sep 2012 15:38:42 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 15:38:41 +0000 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; Tue, 4 Sep 2012 11:38:38 -0400 From: "Cantor, Scott" To: William Mills , Simon Josefsson Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNirNaDj304+GtZUyptIjTd8k0Mg== Date: Tue, 4 Sep 2012 15:38:39 +0000 Message-ID: In-Reply-To: <1346772721.51675.YahooMailNeo@web31808.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 15:38:50 -0000 On 9/4/12 11:32 AM, "William Mills" wrote: >The current draft, in the paragraph before 3.2.1, states that the authzid >is derived from the auth token. Is that not clear enough? It's wrong. The authzid is evaluated together with the identity information from the mechanism, but it's not "derived from" it. None of this has any connection to the OAuth token's internal notions of delegation of access. That just adds a second layer of indirection that the mechanism will have to accommodate or expose as Simon noted. -- Scott From wmills@yahoo-inc.com Tue Sep 4 08:58: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 2015A11E809A for ; Tue, 4 Sep 2012 08:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[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 JbpkXpKKZXqV for ; Tue, 4 Sep 2012 08:58:24 -0700 (PDT) Received: from nm5.bullet.mail.bf1.yahoo.com (nm5.bullet.mail.bf1.yahoo.com [98.139.212.164]) by ietfa.amsl.com (Postfix) with SMTP id BDFFE11E808A for ; Tue, 4 Sep 2012 08:58:23 -0700 (PDT) Received: from [98.139.214.32] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 15:58:22 -0000 Received: from [98.139.212.206] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 15:58:22 -0000 Received: from [127.0.0.1] by omp1015.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 15:58:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 859460.98355.bm@omp1015.mail.bf1.yahoo.com Received: (qmail 39794 invoked by uid 60001); 4 Sep 2012 15:58:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346774302; bh=ZE1Kqh3nuyOoql0hVkjdNOTIsxo2XazXq1ZJWmUo0Ig=; 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=IhNCokSsIqHBEvM2Y0E/Os41G98fVbtcvHJ0C1oKm0hFdivEAVoGMxAns4a6hLAsmvpKzAMxSZQ9J61vRyXisOVDh+kW8d+7uufZqt4yrAMcITxc9Yx9qx2wKmb6XP7U+zvY3T/evxSKRYEu/RgKMN2vFcS3pYz/3aKymxKlKe8= 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=goO6QH7EehGxiG9P8lTCHETy2vojOXCpNtJ2oxOjU20b4eqzU53tO9e3ZVmwi2tGXijXytv2S2X7/MpMP0ApvyKvxRJQfi2anOG1xLw7wus759dEzht3wHK3uj7c52LFDGgrU4BwLV/cb82cru6wTyu1Q6iNF9u6cfpD6FZRjgY=; X-YMail-OSG: m40OwakVM1mbBA.9GzcTvvdYG7ubjCT.iFR8kcglaFb78jC vaW2zj5IR_gldFwQq2Wjfx4LOKSTtzICMxqfquQrPzugShAvpRAlJJmyeErc Vh03JIXZa4Z2MGxapxrwtYFkujbwnLEcwi5RnHVUJbngXh1PZcjLLqnJO.94 NC9KeoTEI2VCLs4lMEtApZHXiT5XGiXWgFULe7HqFOjYC5r8DTgbPcdKmCam 74Qu0n_Fif9q3Qf8tzvukd7W_iRLR6YmiW.h5y8V26s_RYzlgsI.u2yc.PB9 0P_ZG2IEDJFEljVlcAc8jetnngor.buGlUDypKu7pgOW4LpdBhsor2JnFE2R H8P4GROrOEfzLOfsvfe3_gdcpwy5PuQcbdPs3KAH9VCCFYJJrVWYJYReSKN1 nOczzuac8ncIHRE7ds11wMIqFeraOR6ce6nFufQdXsfBG46twF.Dnxt0KJSZ d_0IRJss- Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 08:58:22 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346772721.51675.YahooMailNeo@web31808.mail.mud.yahoo.com> Message-ID: <1346774302.33793.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 08:58:22 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Simon Josefsson In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-1322788975-1346774302=:33793" Cc: "kitten@ietf.org" Subject: Re: [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: Tue, 04 Sep 2012 15:58:25 -0000 --835683298-1322788975-1346774302=:33793 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Tell me how this works when the client sends no authz-id and is authenticat= ing with a Bearer token.=A0 SASL needs in the end to have a user identity, = where does that come from?=0A=0ABased on the answer above, what language is= correct to say that the identity comes out of the token?=0A=0AThanks,=0A= =0A-bill=0A=0A=0A=0A=0A>________________________________=0A> From: "Cantor,= Scott" =0A>To: William Mills ; Sim= on Josefsson =0A>Cc: "kitten@ietf.org" =0A>Sent: Tuesday, September 4, 2012 8:38 AM=0A>Subject: Re: [kitten] -= 06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth= SASL draft -05=0A> =0A>On 9/4/12 11:32 AM, "William Mills" wrote:=0A>=0A>>The current draft, in the paragraph before 3.2.1, st= ates that the authzid=0A>>is derived from the auth token.=A0 Is that not cl= ear enough?=0A>=0A>It's wrong. The authzid is evaluated together with the i= dentity=0A>information from the mechanism, but it's not "derived from" it.= =0A>=0A>None of this has any connection to the OAuth token's internal notio= ns of=0A>delegation of access. That just adds a second layer of indirection= that=0A>the mechanism will have to accommodate or expose as Simon noted.= =0A>=0A>-- Scott=0A>=0A>=0A>=0A>=0A> --835683298-1322788975-1346774302=:33793 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Tell me h= ow this works when the client sends no authz-id and is authenticating with = a Bearer token.  SASL needs in the end to have a user identity, where = does that come from?

Based on the answer above, what language is cor= rect to say that the identity comes out of the token?

Thanks,
-bill

From: "C= antor, Scott" <cantor.2@osu.edu>
To: William Mills <wmills@yahoo-inc.com>; Simon Jo= sefsson <simon@josefsson.org>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Tuesday, September 4, 2012 8:3= 8 AM
Subject: Re: [kit= ten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re:= OAuth SASL draft -05

On 9/4/12 11:32 AM, "William M= ills" <wmills@yahoo-inc.com> wrote:

>The current d= raft, in the paragraph before 3.2.1, states that the authzid
>is deri= ved from the auth token.  Is that not clear enough?

It's wrong.= The authzid is evaluated together with the identity
information from th= e mechanism, but it's not "derived from" it.

None of this has any connection to the OAuth token's internal notions of
delegation of acces= s. That just adds a second layer of indirection that
the mechanism will = have to accommodate or expose as Simon noted.

-- Scott



--835683298-1322788975-1346774302=:33793-- From rtroll@google.com Tue Sep 4 09:07: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 104B021E8040 for ; Tue, 4 Sep 2012 09:07:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eR7iRLbLiqpC for ; Tue, 4 Sep 2012 09:07:33 -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 01EAD21E803F for ; Tue, 4 Sep 2012 09:07:32 -0700 (PDT) Received: by qadz3 with SMTP id z3so3245300qad.10 for ; Tue, 04 Sep 2012 09:07: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=B/BpPGF5Vd9kXQqfA0hqZ680n7w0zwgtbmpLVtfjPtI=; b=X5IQm9ShL94v+kyP8HCj5fvjTmCt66TjMp2m7LpejFDZ1dfV4Ya4c/nwc97F08Z3Ef bbhBS0e2Gr20UdtuKjveD0APmsIbnKxIctJmf5I5m90/O0W720i0mWRzUUIYu94hqS25 1GloVuX7XSTHt0UYzRDFCw+Ua5XV/UH2DRBS0= 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=B/BpPGF5Vd9kXQqfA0hqZ680n7w0zwgtbmpLVtfjPtI=; b=GB9uj2xrKwnz2jD9FhrDLYycnFvMTL3dLbVrVljIR/HQhQBuPhYw7ebCWCzeoR0iAg GfYn9KCrL+gpi6mWdhAuWh1ioRAxvXDqbykjb28Bs3TjTyUtxpr5VmH5X6LWnrrLAoay DkYiZTtdnCTieYUVWZ0/5ENjT3XZCGGrJz2l33ekOmiRD/Du7hzegSram791d8zfOR50 HN4BTpwtFT+q6rhR6l5mzKFKLGmAWcVTPPO7Ld6rYztOPYNpqZj5oyIc6RLUJ43p+Pn/ sBfLAv34OohKhOS6vBSAqm8SP2PLVV9rQwmkB3w8xHyXJ+p40KouUo+u6mHPWQqRnlko +uzA== Received: by 10.229.136.130 with SMTP id r2mr11298417qct.132.1346774852344; Tue, 04 Sep 2012 09:07:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.136.130 with SMTP id r2mr11298405qct.132.1346774852197; Tue, 04 Sep 2012 09:07:32 -0700 (PDT) Received: by 10.49.132.202 with HTTP; Tue, 4 Sep 2012 09:07:31 -0700 (PDT) In-Reply-To: <1346772721.51675.YahooMailNeo@web31808.mail.mud.yahoo.com> References: <1346084466.40894.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> <1346460964.79308.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346476111.52370.YahooMailNeo__8449.33422417871$1346476132$gmane$org@web31811.mail.mud.yahoo.com> <87bohnwmca.fsf@latte.josefsson.org> <1346710108.6729.YahooMailNeo__16099.967438686$1346710121$gmane$org@web31804.mail.mud.yahoo.com> <87mx16s18n.fsf__6744.62316460467$1346743249$gmane$org@latte.josefsson.org> <87ipburzsi.fsf@latte.josefsson.org> <1346772721.51675.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 09:07:31 -0700 Message-ID: From: Ryan Troll To: William Mills Content-Type: multipart/alternative; boundary=00248c768f92a85cd804c8e27496 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkxZtHkFEiPelX8uiNKlsUhL/5LB/5rWfr4F0WRML8swiLZRiFApeI1Q0ary+vizMj65LdXIDTST9Xk9FA7VHQBRph9F7aHCSrFrQE9ZtYqn+t+X3Qwg+Sbz5Ae/3TsNUjDi1q+W8TPNrCkTx4zvnD1OXTWukCFZIwm0gYFtOZLX8ZdqG7JeHF8QV0T1fHxdHb9/xQR Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 16:07:34 -0000 --00248c768f92a85cd804c8e27496 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 4, 2012 at 8:32 AM, William Mills wrote: > I've been having a side conversation with Nico. The MUST that used to be > there on authzid is removed. Servers like Ryan's use case can put in their > service docs that authzid is required, and it will become the de facto > usage standard for things like IMAP even if we don't write that into the > doc. > This works for me. The spec adheres to the approach defined by SASL, and I'll use a method of determining the user that's likely to be the same as other services attempting to do the same. -R --00248c768f92a85cd804c8e27496 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Sep 4, 2012 at 8:32 AM, William = Mills <wmills@yahoo-inc.com> wrote:
I've been having a side conversation with Nico.=A0 = The MUST that used to be there on authzid is removed.=A0 Servers like Ryan&= #39;s use case can put in their service docs that authzid is required, and = it will become the de facto usage standard for things like IMAP even if we = don't write that into the doc.

This works for me. =A0The spec adher= es to the approach defined by SASL, and I'll use a method of determinin= g the user that's likely to be the same as other services attempting to= do the same.

-R=A0

--00248c768f92a85cd804c8e27496-- From cantor.2@osu.edu Tue Sep 4 09:33: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 3A27221E8040 for ; Tue, 4 Sep 2012 09:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ElpA3TgOp0oE for ; Tue, 4 Sep 2012 09:33:08 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9E38B21E8039 for ; Tue, 4 Sep 2012 09:33:08 -0700 (PDT) Received: from mail254-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 16:33:08 +0000 Received: from mail254-tx2 (localhost [127.0.0.1]) by mail254-tx2-R.bigfish.com (Postfix) with ESMTP id EC80E130007F; Tue, 4 Sep 2012 16:33:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.168; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT05.osuad.osu.edu; RD:cio-tnc-ht05.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1155h1151h) Received-SPF: pass (mail254-tx2: domain of osu.edu designates 164.107.81.168 as permitted sender) client-ip=164.107.81.168; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT05.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail254-tx2 (localhost.localdomain [127.0.0.1]) by mail254-tx2 (MessageSwitch) id 1346776386747635_25883; Tue, 4 Sep 2012 16:33:06 +0000 (UTC) Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.246]) by mail254-tx2.bigfish.com (Postfix) with ESMTP id B19161700049; Tue, 4 Sep 2012 16:33:06 +0000 (UTC) Received: from CIO-TNC-HT05.osuad.osu.edu (164.107.81.168) by TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 16:33:04 +0000 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; Tue, 4 Sep 2012 12:32:56 -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, 4 Sep 2012 12:32:55 -0400 From: "Cantor, Scott" To: William Mills , Simon Josefsson Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNirNaDj304+GtZUyptIjTd8k0Mpd6md8A///GkwA= Date: Tue, 4 Sep 2012 16:32:56 +0000 Message-ID: In-Reply-To: <1346774302.33793.YahooMailNeo@web31804.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.138.201] Content-Type: text/plain; charset="us-ascii" Content-ID: <9BC6E472A9E19947A169DBE68BF6C59C@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 16:33:09 -0000 On 9/4/12 11:58 AM, "William Mills" wrote: > >Tell me how this works when the client sends no authz-id and is >authenticating with a Bearer token. SASL needs in the end to have a user >identity, where does that come from? The Bearer token, presumably. The GSS portion of your mech establishes a "name" for the identity of the initiator (the client). That name is then, I believe, surfaced in the SASL layer as the authenticated identity. >Based on the answer above, what language is correct to say that the >identity comes out of the token? The authentication identity definitely comes from the token; I was reacting to the statement that the SASL authz-id did. -- Scott From wmills@yahoo-inc.com Tue Sep 4 09:40: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 A7BD421F865C for ; Tue, 4 Sep 2012 09:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[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 zaDsQt2L84Fv for ; Tue, 4 Sep 2012 09:40:42 -0700 (PDT) Received: from nm11.bullet.mail.ne1.yahoo.com (nm11.bullet.mail.ne1.yahoo.com [98.138.90.74]) by ietfa.amsl.com (Postfix) with SMTP id E287121F85A7 for ; Tue, 4 Sep 2012 09:40:41 -0700 (PDT) Received: from [98.138.90.52] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 04 Sep 2012 16:40:35 -0000 Received: from [98.138.88.232] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 04 Sep 2012 16:40:35 -0000 Received: from [127.0.0.1] by omp1032.mail.ne1.yahoo.com with NNFMP; 04 Sep 2012 16:40:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 448071.97176.bm@omp1032.mail.ne1.yahoo.com Received: (qmail 4254 invoked by uid 60001); 4 Sep 2012 16:40:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346776834; bh=Ya4uxx+5I9ELdk7tXXyvKBoeLCBRxdZcOxs+Q5dgtH0=; 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=hS0ghLd6FyOXUHVgkfLGJoIolT1AhDxYmzF8Ruh2PrGDcanJjvVnikRyCXvT5HrdRQva4WCp4tRmcuglYuzLTXQqQu27PJRYh0AVXMiX5vwNvS05LSUxOgVsSR4okNaIs7Di2lon9GfloC94CWtp6T9zscUm+U/EloKeyKl1MoA= 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=GQPhBRoCz6Gp3Z5bDNNAYf7ZDwvQinK4EWzSeNOdplKqgEIesjYxVbIDPquR0zIHXdv8Dof/sSrxK+fM0EIYoeSst9cVs0ZtLfZTRgx8hlZcTanDuMYn8iMrLM9wwucDifP5AQYozyMsypr69hbpivOOZYnYXdkexjLgEJs3rk4=; X-YMail-OSG: ZZpK1UMVM1nRDIM_r.pCOqs8yTSX8tp8nZReRcSOuJ0F6yP MIhmXb69kw_Vhi1pGWajJS0czM0kaHTeIUgnsBAs0SSbZvuzqGfURtZHiI8W DqxY9sI2oJkzl36hnHS2PQpEyAg1L_bhxqkWb4YByxwFD_JozFLMjUmfO5yN NaKvgInyyyzbFWnZifIxzuDYU7n2p5iy2HzgCr7m5X2_ogjzldna.Q2tdwjf ngqUmrdY1aVL68M_GC4N_dEGrn_fmsepPBpAoN9Fo0DioBWhcO7F4_s1IAc_ qTyI8plOoiKQ0zjR_UjPtkVK74WfjgYHTlB5k_k5TaiVA2RqpZmxsdjKFNwo 4gx1vlNA4SMozHH3h4rsWzQ7KG3FG9Uk_ZMGSYdQSEbsfcuxfjo2sSO8SjDe 0NLai6H_G6sH3ze5rftdxNpenwJhiOkHotRuRzeuTUyIKVLKGvMH639P174Z .DhW4F8E- Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 09:40:33 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346774302.33793.YahooMailNeo@web31804.mail.mud.yahoo.com> Message-ID: <1346776833.99036.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 09:40:33 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Simon Josefsson In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1502656925-1670665117-1346776833=:99036" Cc: "kitten@ietf.org" Subject: Re: [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: Tue, 04 Sep 2012 16:40:42 -0000 --1502656925-1670665117-1346776833=:99036 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ah! I'm missusing the term authz-id then.=A0 So what's the right language t= hen for stating that the identity derived form the token is authoritative a= nd is what is used?=A0 =0A=0A=0A=0A=0A=0A>________________________________= =0A> From: "Cantor, Scott" =0A>To: William Mills ; Simon Josefsson =0A>Cc: "kitten@ietf.= org" =0A>Sent: Tuesday, September 4, 2012 9:32 AM=0A>Subj= ect: Re: [kitten] -06 posted Re: requirements/context/frustration Re: Comma= vs. %x01 Re: OAuth SASL draft -05=0A> =0A>On 9/4/12 11:58 AM, "William Mil= ls" wrote:=0A>>=0A>>Tell me how this works when the = client sends no authz-id and is=0A>>authenticating with a Bearer token.=A0 = SASL needs in the end to have a user=0A>>identity, where does that come fro= m?=0A>=0A>The Bearer token, presumably. The GSS portion of your mech establ= ishes a=0A>"name" for the identity of the initiator (the client). That name= is then,=0A>I believe, surfaced in the SASL layer as the authenticated ide= ntity.=0A>=0A>>Based on the answer above, what language is correct to say t= hat the=0A>>identity comes out of the token?=0A>=0A>The authentication iden= tity definitely comes from the token; I was=0A>reacting to the statement th= at the SASL authz-id did.=0A>=0A>-- Scott=0A>=0A>=0A>=0A>=0A> --1502656925-1670665117-1346776833=:99036 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Ah! I'm m= issusing the term authz-id then.  So what's the right language then fo= r stating that the identity derived form the token is authoritative and is = what is used? 


From: "Cantor, Scott" <cantor.2@osu.ed= u>
To: William Mill= s <wmills@yahoo-inc.com>; Simon Josefsson <simon@josefsson.org>=
Cc: "kitten@ietf.org" <kitten@i= etf.org>
Sent: Tue= sday, September 4, 2012 9:32 AM
S= ubject: Re: [kitten] -06 posted Re: requirements/context/frustra= tion Re: Comma vs. %x01 Re: OAuth SASL draft -05

On = 9/4/12 11:58 AM, "William Mills" <wmills@yahoo-inc.com> wrot= e:
>
>Tell me how this works when the client sends no authz-id = and is
>authenticating with a Bearer token.  SASL needs in the e= nd to have a user
>identity, where does that come from?

The Be= arer token, presumably. The GSS portion of your mech establishes a
"name= " for the identity of the initiator (the client). That name is then,
I b= elieve, surfaced in the SASL layer as the authenticated identity.

>Based on the answer above, what language is correct t= o say that the
>identity comes out of the token?

The authentic= ation identity definitely comes from the token; I was
reacting to the st= atement that the SASL authz-id did.

-- Scott




--1502656925-1670665117-1346776833=:99036-- From cantor.2@osu.edu Tue Sep 4 09:59: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 A46FF11E80A3 for ; Tue, 4 Sep 2012 09:59:13 -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=[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 qPaaRXRf9I7E for ; Tue, 4 Sep 2012 09:59:13 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 0925A11E809A for ; Tue, 4 Sep 2012 09:59:12 -0700 (PDT) Received: from mail214-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE011.bigfish.com (10.243.66.74) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 16:59:11 +0000 Received: from mail214-co1 (localhost [127.0.0.1]) by mail214-co1-R.bigfish.com (Postfix) with ESMTP id 32241840131; Tue, 4 Sep 2012 16:59:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zzbb2dI98dI9371Izz1202hzz1033IL8275bh8275dhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail214-co1: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail214-co1 (localhost.localdomain [127.0.0.1]) by mail214-co1 (MessageSwitch) id 1346777949238496_25678; Tue, 4 Sep 2012 16:59:09 +0000 (UTC) Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.231]) by mail214-co1.bigfish.com (Postfix) with ESMTP id 2EE14140047; Tue, 4 Sep 2012 16:59:09 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 16:59:06 +0000 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; Tue, 4 Sep 2012 12:59:03 -0400 From: "Cantor, Scott" To: William Mills , Simon Josefsson Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNirNaDj304+GtZUyptIjTd8k0Mpd6md8A///GkwCAAEU2gP//whkA Date: Tue, 4 Sep 2012 16:59:03 +0000 Message-ID: In-Reply-To: <1346776833.99036.YahooMailNeo@web31803.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 16:59:13 -0000 On 9/4/12 12:40 PM, "William Mills" wrote: >Ah! I'm missusing the term authz-id then. So what's the right language >then for stating that the identity derived form the token is >authoritative and is what is used? Used by what? I don't know what SASL's term of art is for the authenticated identity (I've spent more time at the GSS layer) but because your mechanism is actually a GSS mech, I would say that you need language along the lines of what's in mine (or I'll need different language myself). Section 5.4 of=20 http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-02 has my latest text for this. OAuth and SAML are not materially different. They both have to address that the identity of the user as typed in has zero to do with either the identity of the user at the actual IdP, the identity of the user in an issued token, or the identity of the user at the RP. Those are three different notions because of how federated identity works. The SASL authz-id concept addresses the latter. The rest is going to be something clients and mechanism implementations will have to deal with. Given a typical client, the user is entering "something" they're told to enter. That has to lead to appropriate behavior in the rest of the pieces based on policy at each point. For example, it could key into an identity "store" that selects the underlying credential to talk to the IdP with. So in my view, what's being entered is the authz-id. "Magic happens" to derive the right username to use when authenticating to the token issuer. And then the token includes some identifier that is based on how the token issuer is setup. And then the mechanism surfaces an authenticated identity (in GSS it's the initiator name) based on the token. And then policy kicks in to determine if that name can access the service, or access the service as the authz-id. -- Scott From wmills@yahoo-inc.com Tue Sep 4 10:14: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 5ABBF21F856C for ; Tue, 4 Sep 2012 10:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[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 hEuz+Ad9o0Nn for ; Tue, 4 Sep 2012 10:14:37 -0700 (PDT) Received: from nm11.bullet.mail.sp2.yahoo.com (nm11.bullet.mail.sp2.yahoo.com [98.139.91.81]) by ietfa.amsl.com (Postfix) with SMTP id 612AC21F8568 for ; Tue, 4 Sep 2012 10:14:37 -0700 (PDT) Received: from [72.30.22.93] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 04 Sep 2012 17:14:31 -0000 Received: from [72.30.22.33] by tm15.bullet.mail.sp2.yahoo.com with NNFMP; 04 Sep 2012 17:14:31 -0000 Received: from [127.0.0.1] by omp1061.mail.sp2.yahoo.com with NNFMP; 04 Sep 2012 17:14:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 258827.11344.bm@omp1061.mail.sp2.yahoo.com Received: (qmail 88469 invoked by uid 60001); 4 Sep 2012 17:14:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346778870; bh=W5sFHKGV114Gk/nZpGq/xIqp5fGYK732G9xDwsRUXxY=; 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=TDn7rPKUBVIN1yX2fu8Kt0igjbFLYVehPF4CDuzZ9+WZckiCKg3W4Lf3WbsPQVdcZWJJBu86nKe16iMVBl8MCy3kFnoDfs7qIps+4Xfk781sTqrE9KtbcJZ5xY0lQc/tbd0M6ISZEQM9nhAYFioKaIQ8Mf5ttiDOSqKbJw+OtLA= 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=ZMOKRCiLrG0AxbuqB8I28hmtPygPEGsbgnoh5h+stzTKG1qUg2gmjL94iQyglmyg4YpNuO+PRqtYDEMJxuo1MbmEwCgzUmtxkeCxTNoR0QUOsOBAhOv3ZiF/9LH7y9HJX/4TgSbM3mJPqdASzzLziDngDUFHJ2cydKGUYbV3lkI=; X-YMail-OSG: d9TUDk0VM1loOqTugHC8u.7Dut9ieNjVvMWJJ33X_nHNBq0 vIvBy_XUp.PsgFjik3n3TwlAF8_JF6lrpUlU7JQRlkvwQ7aqHaTqAHELRCzK K0MDXsmUDeq1ilMJxWmbKachxqsmRMAfEjUOT0_yWOvBlwUDbhXsZBGcgNs. FM5hZeWQKxv8I.hC77tTxD3xue71ZDqhHG12hCbDs4Z4qdr3gHnXhRi4aSJa o9JnzsT_tQE9s96CnK6N0vq.gbkzi9.eWSoAlrfXwLjHci6rp5PwMdodMLj9 Y90lFxH2le7ehNyRWb09dTN.9HydfJatkEeeutDEeJeQ2E09KbsxEd50SfFf hfNLX4d9ISSnC0GHFz.V6ecvh3VACoiIwTB_twCQO4F9xnXxsbgvREBEIZik 0mxwjc9Ses2KD6WlbewnAeJGEkbf9D3yACo6hNVZSf5tI8AswXiuEOY8c0Wi pn1T9_A-- Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 10:14:30 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346776833.99036.YahooMailNeo@web31803.mail.mud.yahoo.com> Message-ID: <1346778870.59415.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 10:14:30 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Simon Josefsson In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-2068127056-1346778870=:59415" Cc: "kitten@ietf.org" Subject: Re: [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: Tue, 04 Sep 2012 17:14:38 -0000 ---551393103-2068127056-1346778870=:59415 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable If I read your text right then basically you're leaving it completely to th= e implementer to magically use the info they have to provide the GSS_C_NT_U= SER_NAME?=A0 You're just saying ot have to provide it and give no guidance = for how it's related to the credentials at all?=0A=0A=0A=0A=0A=0A>_________= _______________________=0A> From: "Cantor, Scott" =0A>To:= William Mills ; Simon Josefsson =0A>Cc: "kitten@ietf.org" =0A>Sent: Tuesday, September = 4, 2012 9:59 AM=0A>Subject: Re: [kitten] -06 posted Re: requirements/contex= t/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>On 9/4/12= 12:40 PM, "William Mills" wrote:=0A>=0A>>Ah! I'm mi= ssusing the term authz-id then.=A0 So what's the right language=0A>>then fo= r stating that the identity derived form the token is=0A>>authoritative and= is what is used?=0A>=0A>Used by what?=0A>=0A>I don't know what SASL's term= of art is for the authenticated identity=0A>(I've spent more time at the G= SS layer) but because your mechanism is=0A>actually a GSS mech, I would say= that you need language along the lines of=0A>what's in mine (or I'll need = different language myself).=0A>=0A>Section 5.4 of =0A>http://tools.ietf.org= /html/draft-ietf-kitten-sasl-saml-ec-02 has my latest=0A>text for this.=0A>= =0A>OAuth and SAML are not materially different. They both have to address= =0A>that the identity of the user as typed in has zero to do with either th= e=0A>identity of the user at the actual IdP, the identity of the user in an= =0A>issued token, or the identity of the user at the RP. Those are three=0A= >different notions because of how federated identity works.=0A>=0A>The SASL= authz-id concept addresses the latter. The rest is going to be=0A>somethin= g clients and mechanism implementations will have to deal with.=0A>Given a = typical client, the user is entering "something" they're told to=0A>enter. = That has to lead to appropriate behavior in the rest of the pieces=0A>based= on policy at each point. For example, it could key into an identity=0A>"st= ore" that selects the underlying credential to talk to the IdP with.=0A>=0A= >So in my view, what's being entered is the authz-id. "Magic happens" to=0A= >derive the right username to use when authenticating to the token issuer.= =0A>And then the token includes some identifier that is based on how the to= ken=0A>issuer is setup. And then the mechanism surfaces an authenticated id= entity=0A>(in GSS it's the initiator name) based on the token. And then pol= icy kicks=0A>in to determine if that name can access the service, or access= the service=0A>as the authz-id.=0A>=0A>-- Scott=0A>=0A>=0A>=0A>=0A> ---551393103-2068127056-1346778870=:59415 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
If I read= your text right then basically you're leaving it completely to the impleme= nter to magically use the info they have to provide the GSS_C_NT_USER_NAME?  You're just saying ot= have to provide it and give no guidance for how it's related to the creden= tials at all?


From: "Cantor, Scott" <cantor.2@osu.edu>
= To: William Mills <wmills@yahoo= -inc.com>; Simon Josefsson <simon@josefsson.org>
Cc: "kitten@ietf.org" <kitten@ietf.o= rg>
Sent: Tuesday,= September 4, 2012 9:59 AM
Subjec= t: Re: [kitten] -06 posted Re: requirements/context/frustration = Re: Comma vs. %x01 Re: OAuth SASL draft -05

On 9/4/1= 2 12:40 PM, "William Mills" <wmills@yahoo-inc.com> wrote:
>Ah! I'm missusing the term authz-id then.  So what's the righ= t language
>then for stating that the identity derived form the token= is
>authoritative and is what is used?

Used by what?

I= don't know what SASL's term of art is for the authenticated identity
(I= 've spent more time at the GSS layer) but because your mechanism is
actuall= y a GSS mech, I would say that you need language along the lines of
what= 's in mine (or I'll need different language myself).

Section 5.4 of =
http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-= ec-02 has my latest
text for this.

OAuth and SAML are not mat= erially different. They both have to address
that the identity of the us= er as typed in has zero to do with either the
identity of the user at th= e actual IdP, the identity of the user in an
issued token, or the identi= ty of the user at the RP. Those are three
different notions because of h= ow federated identity works.

The SASL authz-id concept addresses the= latter. The rest is going to be
something clients and mechanism impleme= ntations will have to deal with.
Given a typical client, the user is entering "something" they're told to
enter. That has to lead to appropr= iate behavior in the rest of the pieces
based on policy at each point. F= or example, it could key into an identity
"store" that selects the under= lying credential to talk to the IdP with.

So in my view, what's bein= g entered is the authz-id. "Magic happens" to
derive the right username = to use when authenticating to the token issuer.
And then the token inclu= des some identifier that is based on how the token
issuer is setup. And = then the mechanism surfaces an authenticated identity
(in GSS it's the i= nitiator name) based on the token. And then policy kicks
in to determine= if that name can access the service, or access the service
as the authz= -id.

-- Scott




=
---551393103-2068127056-1346778870=:59415-- From rra@stanford.edu Tue Sep 4 10:56: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 B067C21E803A for ; Tue, 4 Sep 2012 10:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 mUDH+1TAwcyh for ; Tue, 4 Sep 2012 10:56:49 -0700 (PDT) Received: from smtp.stanford.edu (smtp3.Stanford.EDU [171.67.219.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0007511E809A for ; Tue, 4 Sep 2012 10:56:48 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CB7D145CAD8 for ; Tue, 4 Sep 2012 10:56:48 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 868C045C8D3 for ; Tue, 4 Sep 2012 10:56:48 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 5ABCE2F4E8; Tue, 4 Sep 2012 10:56:47 -0700 (PDT) From: Russ Allbery To: "kitten\@ietf.org" In-Reply-To: (Scott Cantor's message of "Tue, 4 Sep 2012 16:59:03 +0000") Organization: The Eyrie References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Tue, 04 Sep 2012 10:56:47 -0700 Message-ID: <87392xy8m8.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 17:56:49 -0000 "Cantor, Scott" writes: > OAuth and SAML are not materially different. They both have to address > that the identity of the user as typed in has zero to do with either the > identity of the user at the actual IdP, the identity of the user in an > issued token, or the identity of the user at the RP. Those are three > different notions because of how federated identity works. And not even just federated identity, but identity period, which is why SASL has had the separation between the authentication identity and the authorization identity even before federated identity became common. Separating authentication and authorization identity allows for delegation and proxying, where I (for example) authenticate to the IMAP server as myself (authentication identity) but say that I want to read the folders for some other user (authorization identity). RFC 2222: The transmitted authorization identity may be different than the identity in the client's authentication credentials. This permits agents such as proxy servers to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying. With any mechanism, transmitting an authorization identity of the empty string directs the server to derive an authorization identity from the client's authentication credentials. > So in my view, what's being entered is the authz-id. "Magic happens" to > derive the right username to use when authenticating to the token > issuer. And then the token includes some identifier that is based on > how the token issuer is setup. And then the mechanism surfaces an > authenticated identity (in GSS it's the initiator name) based on the > token. And then policy kicks in to determine if that name can access the > service, or access the service as the authz-id. Yes, that sounds right to me as well. -- Russ Allbery (rra@stanford.edu) From cantor.2@osu.edu Tue Sep 4 11:19: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 F354311E80A3 for ; Tue, 4 Sep 2012 11:19:14 -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=[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 TmVrWHP8jLDZ for ; Tue, 4 Sep 2012 11:19:14 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 5B11D11E809A for ; Tue, 4 Sep 2012 11:19:14 -0700 (PDT) Received: from mail153-co1-R.bigfish.com (10.243.78.246) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 18:19:13 +0000 Received: from mail153-co1 (localhost [127.0.0.1]) by mail153-co1-R.bigfish.com (Postfix) with ESMTP id BA90E8000B9; Tue, 4 Sep 2012 18:19:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail153-co1: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail153-co1 (localhost.localdomain [127.0.0.1]) by mail153-co1 (MessageSwitch) id 1346782751975852_9617; Tue, 4 Sep 2012 18:19:11 +0000 (UTC) Received: from CO1EHSMHS018.bigfish.com (unknown [10.243.78.232]) by mail153-co1.bigfish.com (Postfix) with ESMTP id EB2A0A40043; Tue, 4 Sep 2012 18:19:11 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by CO1EHSMHS018.bigfish.com (10.243.66.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 18:19:11 +0000 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; Tue, 4 Sep 2012 14:19:03 -0400 From: "Cantor, Scott" To: William Mills , Simon Josefsson Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNirNaDj304+GtZUyptIjTd8k0Mpd6md8A///GkwCAAEU2gP//whkAgABHYwD//873AA== Date: Tue, 4 Sep 2012 18:19:03 +0000 Message-ID: In-Reply-To: <1346778870.59415.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: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:19:15 -0000 On 9/4/12 1:14 PM, "William Mills" wrote: > >If I read your text right then basically you're leaving it completely to >the implementer to magically use the info they have to provide the >GSS_C_NT_USER_NAME? Well, that text is there because most apps using this infrastructure seem to more or less assume that's what they can use. Some of that is just historical I think, but it remains true. I'm still being guided on that by Simon and by somebody who's implementing my spec with ssh as a prototype. The implementer has to make sure that name form works or apps just won't work with the new mechanism. As far as what to do with it, the "magic" part is the separation between the client/server communication and what's going on between the client and the IdP and in the token. That's not exactly "magic" but it's not specified either because it isn't possible to specify it without breaking real world use of the technology (in my case SAML, in your case OAuth). >You're just saying ot have to provide it and give no guidance for how >it's related to the credentials at all? The mechanism if it's doing its job is making sure that any identity it reports to the mechglue (that's the layer between GSS-API libraries and mechanisms) is "supportable" by the credentials. In a bearer token case, it means the token is valid as presented, etc. I probably left that implicit, and it probably doesn't have to be. But you have to take some care to be clear that it's just that internal identity you're talking about. It's essentially saying "the authenticated identity reported by the mechanism is the identity which the mechanism has securely established for the client". Sort of common sense. But what you can't do is step into application land or step on the authz-id in SASL, which has no direct relationship to that identity. -- Scott From cantor.2@osu.edu Tue Sep 4 11:25: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 1582F21F8661 for ; Tue, 4 Sep 2012 11:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 JNVg+B-y8BEi for ; Tue, 4 Sep 2012 11:25:47 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 707A021F865E for ; Tue, 4 Sep 2012 11:25:47 -0700 (PDT) Received: from mail16-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 18:25:43 +0000 Received: from mail16-tx2 (localhost [127.0.0.1]) by mail16-tx2-R.bigfish.com (Postfix) with ESMTP id 210E338016E; Tue, 4 Sep 2012 18:25:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.40; KIP:(null); UIP:(null); IPV:NLI; H:CIO-KRC-HT02.osuad.osu.edu; RD:cio-krc-ht02.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzzz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail16-tx2: domain of osu.edu designates 164.107.81.40 as permitted sender) client-ip=164.107.81.40; envelope-from=cantor.2@osu.edu; helo=CIO-KRC-HT02.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail16-tx2 (localhost.localdomain [127.0.0.1]) by mail16-tx2 (MessageSwitch) id 1346783140462877_27753; Tue, 4 Sep 2012 18:25:40 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.249]) by mail16-tx2.bigfish.com (Postfix) with ESMTP id 6B4CD80046; Tue, 4 Sep 2012 18:25:40 +0000 (UTC) Received: from CIO-KRC-HT02.osuad.osu.edu (164.107.81.40) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 18:25:35 +0000 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, 4 Sep 2012 14:25:31 -0400 From: "Cantor, Scott" To: Russ Allbery , "kitten@ietf.org" Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNisqqnv0Bt8JNQUCpeASVGtnV/w== Date: Tue, 4 Sep 2012 18:25:31 +0000 Message-ID: In-Reply-To: <87392xy8m8.fsf@windlord.stanford.edu> 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: <97FAE503D6EA464A8A87C086708D277E@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:25:48 -0000 On 9/4/12 1:56 PM, "Russ Allbery" wrote: > >And not even just federated identity, but identity period, which is why >SASL has had the separation between the authentication identity and the >authorization identity even before federated identity became common. >Separating authentication and authorization identity allows for delegation >and proxying, where I (for example) authenticate to the IMAP server as >myself (authentication identity) but say that I want to read the folders >for some other user (authorization identity). That's certainly true, but with federation, the problems of naming uniformity (the lack thereof) become bigger, and it's practically a given that even when you aren't doing any delegation of authority the names on each side won't line up. I guess SASL's authz-id notion can be used to help with that. It's a serious issue with GSS that I think ends up needing name attributes and/or local mappings to deal with at this point. I believe even with Kerberos it is/was to some extent handled by mappings, but Kerberos at least has the simple, familiar, and Unix-like naming scheme for principals. OAuth and SAML do not (flexible, but also a pain to deal with). -- Scott From wmills@yahoo-inc.com Tue Sep 4 11:32: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 3E1EF21F8668 for ; Tue, 4 Sep 2012 11:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 qta3xRQdXDUB for ; Tue, 4 Sep 2012 11:32:15 -0700 (PDT) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) by ietfa.amsl.com (Postfix) with SMTP id 8787C21F867C for ; Tue, 4 Sep 2012 11:32:14 -0700 (PDT) Received: from [98.139.212.147] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 18:32:13 -0000 Received: from [98.139.212.218] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 18:32:13 -0000 Received: from [127.0.0.1] by omp1027.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 18:32:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 825453.76052.bm@omp1027.mail.bf1.yahoo.com Received: (qmail 62009 invoked by uid 60001); 4 Sep 2012 18:32:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346783533; bh=kilYm0AYlIvfFwTGuFeDGsO/GdNmAfpHS9E2vyc9734=; 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=bh5K3ZuWGdrXppFNeGqqR6Rka96Xlp0jSw6W8fYyVKh2qmekoJO6fvwtunjJOXmyZsEmiZ3XPSdqqBQG+FUUU6KTWCmGWi8x039HRNwlkCMaG/8IeVrZ6mSEExRlIciFcsP612cby7DF2LUJWDJXJ7HCJBqLgMY6d5HwDZBkrmA= 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=hQm0iDVpPZBWg3q6fWYgPGNeOSE7usTNUSjdt5BFlwbOrOdymnsu54oOIYPJfpCeeuyUwks8meirjpHmaZlW7Q0s9uz+sY/GgZ4b336LXEINgDVlRZSkLsybluUaiSubR49lFYhBAH0YVjYq52F/MkEVm2OqaG5L2TELKEZWGco=; X-YMail-OSG: OO9zwWsVM1kpYw9lvoMIlY.Ln6Jce5GHqBr5RbskUjFikfj 1Rqj4nz8a2VOYabeLjFTgP1w9mXhd3Snqx39pH5w7ej1nsKNFHtVHFDVohWB MPE0ilLfFqoqXWXVYOBfba0C0oXrSLtg20NTJhvmn97SSYzGGcNR6W.Ijy9H PBltxMvZqB.WlnL3HjKVojIj4hsVqgu9fWeuSL77bHulJ5l5KN3D69ysXuyJ kLrjtWbFtK1YBi1Vqa1vywvVu48Bdqm9Dzsu.AcbGWVCzqS5Kq1uWwMqZ.fN uIWl7ZqKqEA7NS4dc0YFT_5u519HEHBThVRVdgW.6y5v19wYLQg17.VYQ9K5 zSpV7szdjBYUSTmf_TmIebQaEnnIeIyKYcis9YFQjcaVypiv4u4z8XsqgDQI 1cygjbZP7y_dqLVGOC6f3TjZyO2DyCJiQBm3qc6ZtJkTJTdvjzC8f9_jfKSE DMJKaCA-- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 11:32:13 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346778870.59415.YahooMailNeo@web31805.mail.mud.yahoo.com> Message-ID: <1346783533.46750.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 11:32:13 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Simon Josefsson In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-1377147346-1346783533=:46750" Cc: "kitten@ietf.org" Subject: Re: [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: Tue, 04 Sep 2012 18:32:16 -0000 --258328648-1377147346-1346783533=:46750 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I really like the turn of phrase you use, "the authenticated identity=0Arep= orted by the mechanism is the identity which the mechanism has securely=0Ae= stablished for the client".=A0 It says exactly what I want to say.=A0 Would= this=0Apass muster in place of my mistaken usage of authz-id?=0A=0A-bill= =0A=0A=0A=0A=0A=0A>________________________________=0A> From: "Cantor, Scot= t" =0A>To: William Mills ; Simon Jo= sefsson =0A>Cc: "kitten@ietf.org" = =0A>Sent: Tuesday, September 4, 2012 11:19 AM=0A>Subject: Re: [kitten] -06 = posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SA= SL draft -05=0A> =0A>On 9/4/12 1:14 PM, "William Mills" wrote:=0A>>=0A>>If I read your text right then basically you're leaving= it completely to=0A>>the implementer to magically use the info they have t= o provide the=0A>>GSS_C_NT_USER_NAME?=0A>=0A>Well, that text is there becau= se most apps using this infrastructure seem=0A>to more or less assume that'= s what they can use. Some of that is just=0A>historical I think, but it rem= ains true. I'm still being guided on that by=0A>Simon and by somebody who's= implementing my spec with ssh as a prototype.=0A>=0A>The implementer has t= o make sure that name form works or apps just won't=0A>work with the new me= chanism. As far as what to do with it, the "magic"=0A>part is the separatio= n between the client/server communication and what's=0A>going on between th= e client and the IdP and in the token. That's not=0A>exactly "magic" but it= 's not specified either because it isn't possible to=0A>specify it without = breaking real world use of the technology (in my case=0A>SAML, in your case= OAuth).=0A>=0A>>You're just saying ot have to provide it and give no guida= nce for how=0A>>it's related to the credentials at all?=0A>=0A>The mechanis= m if it's doing its job is making sure that any identity it=0A>reports to t= he mechglue (that's the layer between GSS-API libraries and=0A>mechanisms) = is "supportable" by the credentials. In a bearer token case,=0A>it means th= e token is valid as presented, etc.=0A>=0A>I probably left that implicit, a= nd it probably doesn't have to be. But you=0A>have to take some care to be = clear that it's just that internal identity=0A>you're talking about. It's e= ssentially saying "the authenticated identity=0A>reported by the mechanism = is the identity which the mechanism has securely=0A>established for the cli= ent". Sort of common sense.=0A>=0A>But what you can't do is step into appli= cation land or step on the=0A>authz-id in SASL, which has no direct relatio= nship to that identity.=0A>=0A>-- Scott=0A>=0A>=0A>=0A>=0A> --258328648-1377147346-1346783533=:46750 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I really = like the turn of phrase you use, "the authenticated identity
reported by= the mechanism is the identity which the mechanism has securely
establis= hed for the client".  It says exactly what I want to say.  Would = this
pass muster in place of my mistaken usage of authz-id?

-bill=


From: "Cantor, Scott" <cantor.2@osu.edu>
To: William Mills <wmills@yahoo= -inc.com>; Simon Josefsson <simon@josefsson.org>
Cc: "kitten@ietf.org" <kitten@ietf.o= rg>
Sent: Tuesday,= September 4, 2012 11:19 AM
Subje= ct: Re: [kitten] -06 posted Re: requirements/context/frustration= Re: Comma vs. %x01 Re: OAuth SASL draft -05

On 9/4/= 12 1:14 PM, "William Mills" <wmills@yahoo-inc.com> wrote:>
>If I read your text right then basically you're leaving it com= pletely to
>the implementer to magically use the info they have to pr= ovide the
>GSS_C_NT_USER_NAME?

Well, that text is there becaus= e most apps using this infrastructure seem
to more or less assume that's= what they can use. Some of that is just
historical I think, but it remains t= rue. I'm still being guided on that by
Simon and by somebody who's imple= menting my spec with ssh as a prototype.

The implementer has to make= sure that name form works or apps just won't
work with the new mechanis= m. As far as what to do with it, the "magic"
part is the separation betw= een the client/server communication and what's
going on between the clie= nt and the IdP and in the token. That's not
exactly "magic" but it's not= specified either because it isn't possible to
specify it without breaki= ng real world use of the technology (in my case
SAML, in your case OAuth= ).

>You're just saying ot have to provide it and give no guidance= for how
>it's related to the credentials at all?

The mechanis= m if it's doing its job is making sure that any identity it
reports to t= he mechglue (that's the layer between GSS-API libraries and
mechanisms) is "supportable" by the credentials. In a bearer token = case,
it means the token is valid as presented, etc.

I probably l= eft that implicit, and it probably doesn't have to be. But you
have to t= ake some care to be clear that it's just that internal identity
you're t= alking about. It's essentially saying "the authenticated identity
report= ed by the mechanism is the identity which the mechanism has securely
est= ablished for the client". Sort of common sense.

But what you can't d= o is step into application land or step on the
authz-id in SASL, which h= as no direct relationship to that identity.

-- Scott



=
--258328648-1377147346-1346783533=:46750-- From cantor.2@osu.edu Tue Sep 4 11:36: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 90C8A21F8669 for ; Tue, 4 Sep 2012 11:36:18 -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 6jupEJwkL6Ua for ; Tue, 4 Sep 2012 11:36:18 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 0532F21F84D5 for ; Tue, 4 Sep 2012 11:36:18 -0700 (PDT) Received: from mail169-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 18:36:17 +0000 Received: from mail169-co1 (localhost [127.0.0.1]) by mail169-co1-R.bigfish.com (Postfix) with ESMTP id 52C4FB8010D; Tue, 4 Sep 2012 18:36:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail169-co1: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail169-co1 (localhost.localdomain [127.0.0.1]) by mail169-co1 (MessageSwitch) id 1346783775946774_19665; Tue, 4 Sep 2012 18:36:15 +0000 (UTC) Received: from CO1EHSMHS023.bigfish.com (unknown [10.243.78.240]) by mail169-co1.bigfish.com (Postfix) with ESMTP id DA877300047; Tue, 4 Sep 2012 18:36:15 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by CO1EHSMHS023.bigfish.com (10.243.66.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 18:36:14 +0000 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; Tue, 4 Sep 2012 14:36:10 -0400 From: "Cantor, Scott" To: William Mills Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNirNaDj304+GtZUyptIjTd8k0Mpd6md8A///GkwCAAEU2gP//whkAgABHYwD//873AAAI2AyA//++CIA= Date: Tue, 4 Sep 2012 18:36:09 +0000 Message-ID: In-Reply-To: <1346783533.46750.YahooMailNeo@web31808.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: <86ACF04C91E42E45A1ECCEB7580B4A9E@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:36:18 -0000 On 9/4/12 2:32 PM, "William Mills" wrote: > >I really like the turn of phrase you use, "the authenticated identity >reported by the mechanism is the identity which the mechanism has securely >established for the client". It says exactly what I want to say. Would >this >pass muster in place of my mistaken usage of authz-id? It's ok by me (obviously). -- Scott From rra@stanford.edu Tue Sep 4 11:40: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 EF3A421F8697 for ; Tue, 4 Sep 2012 11:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 yOK3LBx1lIrx for ; Tue, 4 Sep 2012 11:40:31 -0700 (PDT) Received: from smtp.stanford.edu (smtp1.Stanford.EDU [171.67.219.81]) by ietfa.amsl.com (Postfix) with ESMTP id 58BDE21F868A for ; Tue, 4 Sep 2012 11:40:31 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3EEFC12DAD1; Tue, 4 Sep 2012 11:40:31 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id E712412DAC5; Tue, 4 Sep 2012 11:40:29 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id CE1272F4E8; Tue, 4 Sep 2012 11:40:29 -0700 (PDT) From: Russ Allbery To: William Mills In-Reply-To: <1346783533.46750.YahooMailNeo@web31808.mail.mud.yahoo.com> (William Mills's message of "Tue, 4 Sep 2012 11:32:13 -0700 (PDT)") Organization: The Eyrie References: <1346778870.59415.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346783533.46750.YahooMailNeo@web31808.mail.mud.yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Tue, 04 Sep 2012 11:40:29 -0700 Message-ID: <87bohlws0y.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , "kitten@ietf.org" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:40:32 -0000 William Mills writes: > I really like the turn of phrase you use, "the authenticated identity > reported by the mechanism is the identity which the mechanism has > securely established for the client".=C2=A0 It says exactly what I want to > say.=C2=A0 Would this pass muster in place of my mistaken usage of authz-= id? Yup, that seems fine to me. --=20 Russ Allbery (rra@stanford.edu) From nico@cryptonector.com Tue Sep 4 13:02: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 D835E21F8468 for ; Tue, 4 Sep 2012 13:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 pzixF46lmqeS for ; Tue, 4 Sep 2012 13:02:21 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2D521F846D for ; Tue, 4 Sep 2012 13:02:21 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id EA84A1E087 for ; Tue, 4 Sep 2012 13:02:20 -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=JxaJsc36wDpnO4FlqHsk 6ERJ7Xw=; b=NYthkORLcdeccYf6irmtHGuowj55uAEAq6EUUJP65EMBtP1fEU5E uD552EnVHHhauqzPeErSyRPuDDHzsCZG44m7mrf6lAdaKcybA95DkwEhfx8MxOUY SDjNWy2SpbmejYjmbDZ+jRo7HZrD2dACViTqCAWnDANy7S5UZwetAZE= 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 CA2B81E080 for ; Tue, 4 Sep 2012 13:02:20 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so9672872pbb.31 for ; Tue, 04 Sep 2012 13:02:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.129.73 with SMTP id nu9mr48960781pbb.59.1346788940213; Tue, 04 Sep 2012 13:02:20 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 13:02:19 -0700 (PDT) In-Reply-To: References: <1346774302.33793.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 15:02:19 -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] -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:02:22 -0000 On Tue, Sep 4, 2012 at 11:32 AM, Cantor, Scott wrote: > The authentication identity definitely comes from the token; I was > reacting to the statement that the SASL authz-id did. The ID authenticated by the mechanism is the authcid. That has to (necessarily) come from the OAuth token, or else be implied by something in it. The authz-id is just an application-level concept that the mechanism transports without interpretation or modification. (Nor can the mechanism map an authcid to an authz-id). Nico -- From nico@cryptonector.com Tue Sep 4 13:04: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 F3BD121E8094 for ; Tue, 4 Sep 2012 13:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 wZJXzOemqjyl for ; Tue, 4 Sep 2012 13:04:14 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5092721E8082 for ; Tue, 4 Sep 2012 13:04:14 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id BB23D67C074 for ; Tue, 4 Sep 2012 13:04: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=sKL+0kATrgOcEbUYUrxc jGdjlvY=; b=sVTRmu15ZZlSgghV6pENIvPuQokp0UCIvQJzQwB4u6G1aYStIz2M HAyBE8FPE8brYgj5nqiRmaFVnwpMBs2oi+tLzb0e6Xw8KdQ99pg3Q+f4lMIINS7s tI1qWY17CVGByElCBiulF2fS6gzWuiNZjEdHtp7ziVaIGNNV+juU5dQ= 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 97F5967C073 for ; Tue, 4 Sep 2012 13:04:13 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so9675208pbb.31 for ; Tue, 04 Sep 2012 13:04:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.220.104 with SMTP id pv8mr48259097pbc.119.1346789053272; Tue, 04 Sep 2012 13:04:13 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 13:04:13 -0700 (PDT) In-Reply-To: <1346778870.59415.YahooMailNeo@web31805.mail.mud.yahoo.com> References: <1346776833.99036.YahooMailNeo@web31803.mail.mud.yahoo.com> <1346778870.59415.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 15:04:13 -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] -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:04:15 -0000 On Tue, Sep 4, 2012 at 12:14 PM, William Mills wrote: > If I read your text right then basically you're leaving it completely to the > implementer to magically use the info they have to provide the > GSS_C_NT_USER_NAME? You're just saying ot have to provide it and give no > guidance for how it's related to the credentials at all? GSS_Accept_sec_context() outputs the NAME of the initiator. This corresponds to the SASL authcid -- the ID authenticated by the mechanism. The constant "GSS_C_NT_USER_NAME" is a red herring here :) Nico -- From nico@cryptonector.com Tue Sep 4 13: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 6C2A521E8098 for ; Tue, 4 Sep 2012 13:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 E2ehkgg+BZQM for ; Tue, 4 Sep 2012 13:08:50 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 08D3B21E8082 for ; Tue, 4 Sep 2012 13:08:50 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id A0CF467C074 for ; Tue, 4 Sep 2012 13:08: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=v135Y6dyblLnIUkI9LMv SH7IiP8=; b=jdxCNe/wN6XgoB27zwa4obDknzIba4k5T00c6WxTXG0R872jrbwO TK6QuGvy7QKeEUSYWPLfvfZUrRAWrM/WyVcsY945+a9IIbjokIGsi/FmmAg6xt8P XoAtTi5XVY1lpvVejMwGMwFgj+hbttgWjaRMWhV5YIz6tfZb1aMCu9k= 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 84ADC67C06D for ; Tue, 4 Sep 2012 13:08:49 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so9680911pbb.31 for ; Tue, 04 Sep 2012 13:08:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.73 with SMTP id ra9mr48262774pbc.85.1346789328909; Tue, 04 Sep 2012 13:08:48 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 13:08:48 -0700 (PDT) In-Reply-To: <1346783533.46750.YahooMailNeo@web31808.mail.mud.yahoo.com> References: <1346778870.59415.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346783533.46750.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 15:08:48 -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] -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:08:50 -0000 On Tue, Sep 4, 2012 at 1:32 PM, William Mills wrote: > I really like the turn of phrase you use, "the authenticated identity > > reported by the mechanism is the identity which the mechanism has securely > established for the client". It says exactly what I want to say. Would > this > pass muster in place of my mistaken usage of authz-id? Yes, but post actual text? Whatever ID OAuth authenticates, that's the authcid. The OAuth *core* has absolutely nothing to do with the authz-id, nothing. The gs2-header transports the authz-id from the client app to the server app, and prepending the gs2-header to the CB data provides integrity protection to the authz-id (and other things in the gs2-header). Thus the SASL/GS2 OAuth mechanism, like any other SASL mechanism, provides for transportation of the authz-id, and it provides integrity protection as one would expect of any mechanism that can provide real security (as compared to PLAIN). Nico -- From cantor.2@osu.edu Tue Sep 4 13:13: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 A531021E809B for ; Tue, 4 Sep 2012 13:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 ZY+lXTT0nFOw for ; Tue, 4 Sep 2012 13:13:09 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFED21E8082 for ; Tue, 4 Sep 2012 13:13:09 -0700 (PDT) Received: from mail29-co1-R.bigfish.com (10.243.78.225) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 20:13:08 +0000 Received: from mail29-co1 (localhost [127.0.0.1]) by mail29-co1-R.bigfish.com (Postfix) with ESMTP id ADA007200E6; Tue, 4 Sep 2012 20:13:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail29-co1: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail29-co1 (localhost.localdomain [127.0.0.1]) by mail29-co1 (MessageSwitch) id 1346789586971458_16773; Tue, 4 Sep 2012 20:13:06 +0000 (UTC) Received: from CO1EHSMHS007.bigfish.com (unknown [10.243.78.229]) by mail29-co1.bigfish.com (Postfix) with ESMTP id E9C07DC0043; Tue, 4 Sep 2012 20:13:06 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by CO1EHSMHS007.bigfish.com (10.243.66.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 20:13:06 +0000 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, 4 Sep 2012 16:13: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; Tue, 4 Sep 2012 16:13:00 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: GSS name type (was Re: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05) Thread-Index: AQHNitmuzYw41GedIUG/T8qpAhEFZQ== Date: Tue, 4 Sep 2012 20:13:00 +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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" , Simon Josefsson Subject: [kitten] GSS name type (was Re: -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:13:09 -0000 On 9/4/12 4:04 PM, "Nico Williams" wrote: > >GSS_Accept_sec_context() outputs the NAME of the initiator. This >corresponds to the SASL authcid -- the ID authenticated by the >mechanism. > >The constant "GSS_C_NT_USER_NAME" is a red herring here :) I was told it's not really a red herring, because there are lots of GSS apps that just flat won't work unless the name's in that form from the mechanism, or at least translatable into it I suppose. -- Scott From wmills@yahoo-inc.com Tue Sep 4 13:19: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 3B61821E8043 for ; Tue, 4 Sep 2012 13:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 KJkPeK2Lx4xN for ; Tue, 4 Sep 2012 13:19:56 -0700 (PDT) Received: from nm20-vm0.bullet.mail.bf1.yahoo.com (nm20-vm0.bullet.mail.bf1.yahoo.com [98.139.213.165]) by ietfa.amsl.com (Postfix) with SMTP id 5544F21F8518 for ; Tue, 4 Sep 2012 13:19:56 -0700 (PDT) Received: from [98.139.212.144] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 20:19:55 -0000 Received: from [98.139.212.225] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 20:19:55 -0000 Received: from [127.0.0.1] by omp1034.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 20:19:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 694495.19109.bm@omp1034.mail.bf1.yahoo.com Received: (qmail 62072 invoked by uid 60001); 4 Sep 2012 20:19:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346789995; bh=zyNpG7dCV7XgISdjEZTbsK3Ng+RajJ4J3JVYd5J6O8k=; 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=hknTRyaBHq08BvEycOMFYxRxGYQfXAWmRFqa3h0dHVX5NF068fz+VTAmS9flRd55aRK7i12cbayIZAzsunb7pTdo9fz8chcvD1jgx/bTq8yXgOWJwNeJctA5fQvrKd75IDylWbkgiO91Oq43WIgcetM1wBYkhKy70wt4BlQPkj0= 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=dSKwoKmrfKa90TWN6Yn0NWHLlvY5ZsWSMW/Ur7qa3DvNRyUJYjhKAeU71SA4JYiPdsoUiIdjNPVQcm3QpRyzK0kYW5eYsbL9+43G/u4daI+G9MbS3GTf2o2YkHbDfCiGjdchMh1NbFhBd78Hy6UpGyUI8SOZirGfF5ZetYwpKe4=; X-YMail-OSG: NrrLWXUVM1n.DK281nySLOJwUT8P6mqwxsu933YPE6eYwhd aTI.bH5CnY7VEen5o.nbsX2qTb1kwgavh8eSQ2fi70uOXY9_2r59aMzUuYTT aP37qSAM41nNSrJCzcPuGjNq0gpsFrQaaMo55T0fnt3lL1dRjsfwustqkkQi vcKtWJaI84i1iRgw4qdeTXjiebdgrZKGOPnhBA_ekR1ms5fgvKIk24z91.RD Zdoubved7i.ABvZoUsb6U9Esb4j3Z124AQFQ3YNE3V4mT.jKj2cL4DwW1Cx_ 8vfaJfnGDz6P4eUKpbAZWuf0PyYeN.Fv60GAQZLOfqEWjudrk.GuVlPEkgrH uDPY9crtrcKnnfFW8VMGmjQ00oBZasmHwRKDIogibphtRyhk4HqsF5Agv4vQ g9Woi54BDr5C2vWbBsjdVrqGtlhWcy6YooYoz3TmHSussh8E9AfkvkcT75.o d09myKnI- Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 13:19:55 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346778870.59415.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346783533.46750.YahooMailNeo@web31808.mail.mud.yahoo.com> Message-ID: <1346789995.43005.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 13:19:55 -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] -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: Tue, 04 Sep 2012 20:19:57 -0000 =0A=0A=0A=0A=0A=0A=0A>________________________________=0A> From: Nico Willi= ams =0A>To: William Mills =0A= >Cc: "Cantor, Scott" ; Simon Josefsson ; "kitten@ietf.org" =0A>Sent: Tuesday, September 4, 20= 12 1:08 PM=0A>Subject: Re: [kitten] -06 posted Re: requirements/context/fru= stration Re: Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A>On Tue, Sep 4,= 2012 at 1:32 PM, William Mills wrote:=0A>> I really= like the turn of phrase you use, "the authenticated identity=0A>>=0A>> rep= orted by the mechanism is the identity which the mechanism has securely=0A>= > established for the client".=A0 It says exactly what I want to say.=A0 Wo= uld=0A>> this=0A>> pass muster in place of my mistaken usage of authz-id?= =0A>=0A>Yes, but post actual text?=0A>=0A>Whatever ID OAuth authenticates, = that's the authcid.=0A=0AOAuth can provide both the user identity and the i= dentity of the agent=0Ausing the ctredential.=A0 I don't think you want 2 v= alues for authcid.=0A=0A=0A>=0A>The OAuth *core* has absolutely nothing to = do with the authz-id,=0A>nothing.=A0 The gs2-header transports the authz-id= from the client app=0A>to the server app, and prepending the gs2-header to= the CB data=0A>provides integrity protection to the authz-id (and other th= ings in the=0A>gs2-header).=A0 Thus the SASL/GS2 OAuth mechanism, like any = other SASL=0A>mechanism, provides for transportation of the authz-id, and i= t=0A>provides integrity protection as one would expect of any mechanism=0A>= that can provide real security (as compared to PLAIN).=0A=0AAn OAuth mechan= ism can validate that the autz-id sent is correct, and=0Ain fact if the wro= ng agent presents a credential it SHOULD fail if that=0Acredential was issu= ed for a specific agent/proxy.=0A=0A=0A>=0A>Nico=0A>--=0A>=0A>=0A> From cantor.2@osu.edu Tue Sep 4 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 718A921F854C for ; Tue, 4 Sep 2012 13:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 SHfQumUTNqFU for ; Tue, 4 Sep 2012 13:30:35 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id D970921F853F for ; Tue, 4 Sep 2012 13:30:34 -0700 (PDT) Received: from mail94-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 20:30:34 +0000 Received: from mail94-ch1 (localhost [127.0.0.1]) by mail94-ch1-R.bigfish.com (Postfix) with ESMTP id 70F762005F; Tue, 4 Sep 2012 20:30:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.168; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT05.osuad.osu.edu; RD:cio-tnc-ht05.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail94-ch1: domain of osu.edu designates 164.107.81.168 as permitted sender) client-ip=164.107.81.168; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT05.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail94-ch1 (localhost.localdomain [127.0.0.1]) by mail94-ch1 (MessageSwitch) id 1346790631787221_26527; Tue, 4 Sep 2012 20:30:31 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail94-ch1.bigfish.com (Postfix) with ESMTP id BCAF240088; Tue, 4 Sep 2012 20:30:31 +0000 (UTC) Received: from CIO-TNC-HT05.osuad.osu.edu (164.107.81.168) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 20:30:28 +0000 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; Tue, 4 Sep 2012 16:30:27 -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, 4 Sep 2012 16:30:16 -0400 From: "Cantor, Scott" To: William Mills , Nico Williams Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNirNaDj304+GtZUyptIjTd8k0Mpd6md8A///GkwCAAEU2gP//whkAgABHYwD//873AAAI2AyA///buq2AAAIvgA== Date: Tue, 4 Sep 2012 20:30:15 +0000 Message-ID: In-Reply-To: <1346789995.43005.YahooMailNeo@web31810.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: <799BE18C9CFC584D95C6FF9487F516AD@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:30:35 -0000 On 9/4/12 4:19 PM, "William Mills" wrote: > >OAuth can provide both the user identity and the identity of the agent >using the ctredential. I don't think you want 2 values for authcid. No, but you have to pick one, and then make the other available if you choose to via GSS. There is no way to do that via SASL itself, I don't think. >An OAuth mechanism can validate that the autz-id sent is correct, and >in fact if the wrong agent presents a credential it SHOULD fail if that >credential was issued for a specific agent/proxy. No, you can't. Your mechanism will NOT know the authz-id because it's a GSS mechanism and the SASL part is stripped off. That's what we've been trying to explain. It is not your mech's job to do that anaylsis and rejection, it's the application's job. You don't need to say this, it's covered by SASL. You are conflating OAuth's notion of multiple identities with the authz-id. You can't do that. OAuth's notions have nothing to do with SASL's. In effect, there are three in play here, authz-id, and two OAuth notions that you have to collapse into an authcid for SASL. -- Scott From wmills@yahoo-inc.com Tue Sep 4 13:37: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 1B8C021E803F for ; Tue, 4 Sep 2012 13:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 GUu73peSFR0Q for ; Tue, 4 Sep 2012 13:37:43 -0700 (PDT) Received: from nm29.bullet.mail.ac4.yahoo.com (nm29.bullet.mail.ac4.yahoo.com [98.139.52.226]) by ietfa.amsl.com (Postfix) with SMTP id B9E1A11E80A4 for ; Tue, 4 Sep 2012 13:37:42 -0700 (PDT) Received: from [98.139.52.197] by nm29.bullet.mail.ac4.yahoo.com with NNFMP; 04 Sep 2012 20:37:39 -0000 Received: from [98.139.52.168] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 04 Sep 2012 20:37:39 -0000 Received: from [127.0.0.1] by omp1051.mail.ac4.yahoo.com with NNFMP; 04 Sep 2012 20:37:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 658720.19357.bm@omp1051.mail.ac4.yahoo.com Received: (qmail 8494 invoked by uid 60001); 4 Sep 2012 20:37:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346791058; bh=lX+/KTYTa9z30PiwtKYMEQn7iGMhCxmaYAki3MlcCBc=; 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=jWNPh9T9raVqjgjNkuIo7Qfh3SkDNmL5LCQv5H24mAwHMQsIKDO3uejo98SX0VASICemKa4lAppqV46jPhHSNHroqLD8AGkDYEqWXV2+WUz6j/U7I7bzsk8KzOf8XZ7fB6WOb//BnhREqgILaMTIummOGYtPGywUG7bvgzuPa4g= 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=APbfTjJzWCqtDB6mlaPlybRfsAiEFTbItuabys04A9prmX9vGp/QcHXHXX2xxy5f6DsP3EkenUfVALl6FviRH7QtHQv0ytgyLR8FYVfCtx0bEAlfHohqDuy+kEyVt2qBraeOsMM+yYD/zIbAWlEwwMJwUyNPFNTSOtKaVL2AW4M=; X-YMail-OSG: DfPhJgcVM1m._ovE3Y25CNVJfA92kqnAPoKS4UVkoCLMws2 QxhwFHFF68BB4AHw1k0qS8ysuLAm.fJf_7bpsxq8lCiB.z6TS.2f_jEkT3bD opGR8lrKmOzJ5aND6MmWn8LeOcuHhb.WGUUh57ZVZFHmikCOUiADGr1.dkit Y75dohz7x84nJpLRoPubbEX0_wOYqq.GAW7LHCYjZun26WD8iK_HRX1W_jMt 46czWxgu3nzuOEWb8d9ARftF3ibvrvGaJy3XMmkes0tfonX4gqenoJBYFnW0 ddc_dRHiPJvHShmhOepbAV9w8m.9kWrzvV4B_3r2DXpRt6sGHQecud84Ajue v9WJK.tNGqZzZktn3jU0Ly_AvFOPYb8BuNk5qSnZ4C7l3Gow2McoAANHaRwO .z8januTrhWN.1pUfNbcCXoLQxC6tA.QcMjhxPU9EuK7EBmU0sjG_CUDbNmt lRbLwuA8- Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 13:37:38 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346778870.59415.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346783533.46750.YahooMailNeo@web31808.mail.mud.yahoo.com> Message-ID: <1346791058.96431.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 13:37:38 -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] -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: Tue, 04 Sep 2012 20:37:44 -0000 Proposed text as requested.=A0 Starting with the last paragraph in -06 befo= re 3.2.1 the text WAS:=0A=0A=0A=A0=A0=A0 The server responds to a successfu= lly verified client message by =0Acompleting=0A=A0=A0=A0 the SASL negotiati= on. The authorization scheme MUST carry the user ID to be=0A=A0=A0=A0 used = as the=A0=A0authorization identity (identity to act as). The server MUST = =0A=0A=A0=A0=A0 use the ID obtained from the credential as the user =0Abein= g authorized.=A0=0A=0A=A0=A0=A0 3.2.1.=A0 Mapping to SASL Identities=0A=0A= =A0=A0=A0 Some OAuth mechanisms can provide both an authorization identity = and an=A0=A0 =0A=0A=A0=A0=A0 authentication identity.=A0=A0An example of th= is is OAuth 1.0a [RFC5849] =0Awhere=A0 =0A=0A=A0=A0=A0 the consumer key (oa= uth_consumer_key) identifies the entity using the token =0A=0A=A0=A0=A0 whi= ch equates to the=A0=A0SASL authentication identity, and is =0Aauthenticate= d using =0A=0A=A0=A0=A0 the shared secret.=A0=A0 The server MAY use a consu= mer =0Akey, a value=A0=A0derived from =0A=0A=A0=A0=A0 it, or other comparab= le identity in the OAuth authorization scheme=A0=A0to allow =0A=0A=A0=A0=A0= SASL an authentication identity =0Adifferent from the authorization identi= ty to =0A=0A=A0=A0=A0 be set.=A0=0A=0AThe proposed new text IS:=0A=0A=0A=A0= =A0=A0 The server responds to a =0Asuccessfully verified client message by = completing =0A=0A=A0=A0=A0 the SASL negotiation. The authenticated identity= reported by the mechanism=0A=A0=A0=A0 is the identity =0Awhich the mechani= sm has securely established for the client =0A=0A=A0=A0=A0 with the =0AOAut= h credential.=0A=A0=A0=A0 3.2.1.=A0Mapping to SASL Identities=0A=0A=A0=A0= =A0 Note that the semantics of the authz-id are specified by the SASL =0Afr= amework =0A=A0=A0=A0 [RFC4422]. A SASL application is, of course, free to a= pply =0Amappings of the =0A=A0=A0=A0 OAuth authcid to authz-ids as per-SASL= , and it is free =0Ato apply mappings common =0A=A0=A0=A0 to non-SASL OAuth= applications. For example a =0Adeveloper implementing an OAuth =0A=A0=A0= =A0 1.0a=A0[RFC5849]=A0mechanism where the =0Aconsumer key (oauth_consumer_= key) identifies =0A=A0=A0=A0 the entity using the token and the token itsel= f identifies the user=0Athe developer =0A=A0=A0=A0 could map these to the S= ASL authz-id and authcid.=0A=0A=0A=0A=0A=0A=0A=0A=0A----- Original Message = -----=0A> From: Nico Williams =0A> To: William Mills= =0A> Cc: "Cantor, Scott" ; Simon J= osefsson ; "kitten@ietf.org" =0A> Sen= t: Tuesday, September 4, 2012 1:08 PM=0A> Subject: Re: [kitten] -06 posted = Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draf= t -05=0A> =0A> On Tue, Sep 4, 2012 at 1:32 PM, William Mills =0A> wrote:=0A>>=A0=A0I really like the turn of phrase you use, "t= he authenticated identity=0A>> =0A>>=A0=A0reported by the mechanism is the = identity which the mechanism has securely=0A>>=A0=A0established for the cli= ent".=A0 It says exactly what I want to say.=A0 =0A> Would=0A>>=A0=A0this= =0A>>=A0=A0pass muster in place of my mistaken usage of authz-id?=0A> =0A> = Yes, but post actual text?=0A> =0A> Whatever ID OAuth authenticates, that's= the authcid.=0A> =0A> The OAuth *core* has absolutely nothing to do with t= he authz-id,=0A> nothing.=A0 The gs2-header transports the authz-id from th= e client app=0A> to the server app, and prepending the gs2-header to the CB= data=0A> provides integrity protection to the authz-id (and other things i= n the=0A> gs2-header).=A0 Thus the SASL/GS2 OAuth mechanism, like any other= SASL=0A> mechanism, provides for transportation of the authz-id, and it=0A= > provides integrity protection as one would expect of any mechanism=0A> th= at can provide real security (as compared to PLAIN).=0A> =0A> Nico=0A> --= =0A> From nico@cryptonector.com Tue Sep 4 13: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 DE2DA21F847F for ; Tue, 4 Sep 2012 13:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 HXn8WnrVv0ze for ; Tue, 4 Sep 2012 13:40:09 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 38ECE21F8471 for ; Tue, 4 Sep 2012 13:40:09 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id BF2466B007F for ; Tue, 4 Sep 2012 13: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=DfladHrG5/CH6tH15R+S LGSsL6c=; b=rvPXy27Wa6EDyzJ5Wv6tMAGwIkLQBo7ccjCDn4MZjoJz2LMIhWmF 9PWO9lTLd4JyL9muHGeviFDsKZNryDy1C9eVsuaD3oYLnb+kPZPQ/GQ3APZxG0/Y dr1oQaxL3n65A8ViMHsy6z2FoUf4govBzs8nvP0+reENd3O8B75rhec= 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 9F6CC6B007B for ; Tue, 4 Sep 2012 13:40:08 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so9715747pbb.31 for ; Tue, 04 Sep 2012 13:40:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.220.104 with SMTP id pv8mr48445876pbc.119.1346791208184; Tue, 04 Sep 2012 13:40:08 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 13:40:07 -0700 (PDT) In-Reply-To: <1346789995.43005.YahooMailNeo@web31810.mail.mud.yahoo.com> References: <1346778870.59415.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346783533.46750.YahooMailNeo@web31808.mail.mud.yahoo.com> <1346789995.43005.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 15:40:07 -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] -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:40:10 -0000 On Tue, Sep 4, 2012 at 3:19 PM, William Mills wrote: >>Whatever ID OAuth authenticates, that's the authcid. > > OAuth can provide both the user identity and the identity of the agent > using the ctredential. I don't think you want 2 values for authcid. This is why I suggested earlier that you report a combination of the two as the authcid. However, a better suggestion is provided below based on GSS naming extensions. I will repeat: > An OAuth mechanism can validate that the autz-id sent is correct, and > in fact if the wrong agent presents a credential it SHOULD fail if that > credential was issued for a specific agent/proxy. NO. The OAuth mechanism CANNOT INTERPRET OR MODIFY OR PROVIDE an authz-id. Given that you have *two* IDs to report in the authcid vein, where SASL only allows *one*, we have what appears to be a fundamental incompatibility between OAuth and SASL. We *can* address this as follows: - make one of the user or agent IDs the authcid - treat the other of those two IDs as a GSS name attribute It's perfectly fine to extend existing SASL APIs to provide the second ID in some way other than by exposing a GSS NAME object to the application. The question is: which ID is best to report as the authcid: the user, or the agent ID? Nico -- From wmills@yahoo-inc.com Tue Sep 4 13:42: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 0640A21F84A0 for ; Tue, 4 Sep 2012 13:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 RZoJvKGUchve for ; Tue, 4 Sep 2012 13:42:22 -0700 (PDT) Received: from nm39-vm3.bullet.mail.bf1.yahoo.com (nm39-vm3.bullet.mail.bf1.yahoo.com [72.30.239.147]) by ietfa.amsl.com (Postfix) with SMTP id 9A6E021F849B for ; Tue, 4 Sep 2012 13:42:19 -0700 (PDT) Received: from [98.139.212.149] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 20:42:19 -0000 Received: from [98.139.212.212] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 20:42:19 -0000 Received: from [127.0.0.1] by omp1021.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 20:42:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 844.45884.bm@omp1021.mail.bf1.yahoo.com Received: (qmail 22603 invoked by uid 60001); 4 Sep 2012 20:42:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346791338; bh=LM1xslVGLz8XPHdNprtHRontzGbJp7KnaZ5qbv7sIkk=; 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=UNpI/2jmG1xz6QEfM35oxPzG3aC2cbmD4mfmN9YaufCFsTsSuwkLr80UnqIw4YjvAorIPz3LfAIQbpO/45HkFhdCdc07rNpiuhJ2i8iRq4V80k3KOr4rkICSgIG915TviWHt9dpnt3ssknFVQF4YAnay/+5CRo1swudRS/WxPxk= 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=VkVbQeGcTWJw0PjT3bMQYunFFf0c2Rlv3g5ppwnQzmYzJ5CBXfT/DQPWXzddvaavtYQ3dABi3lD0JJqL+DqMYkHryTTyeO8MlSsnByR7ylAep9/5/R6ZcFKCV8kvOewut+BAPf+iCVJUg+HSbafsGYwpbuacsS/7mKZqyMfRVAw=; X-YMail-OSG: ty0lq2kVM1l8Gnz.Y9gqcH1MRJORWF0CcmXzxnAbrKo5WBg codxcOvRb7COTny1hE3YHdmfUd2Zrxq_T6lUfbb2dYQ3lnUryDG3ib1xsU9A PUJNRYrh1jao7kMoPCjKpPG3vRgo_B7bJsxbY3W5iiZ3B4v5Y4b.g_zH_kMs rKqApvHbATjYGsGUwUKCpTExT7z0QIN.zRNuoEbHJXRJ28hD5IC_VqAupOIg s6qEBXjiI2johSnkWMvzFijD20w277UrZUjsh_VIAixLzAjJb4v8G2Y.YWL0 lEPvpfR8TiiLC8KkPfd1mdW38ABvApGu9.TFHv.3ROrL5DYzRguHmpXUz5AT bQD0A_0G7MZULg4ZaLz0qOPb_FUiJ4WIG19aUhD1LnxXwuoq31Y61spfut7U hJ3AvjDfmgdSFnU95nGAfN4ZZCac.QXVqLCkOpRHBJr.I_5nXVzVyrWCz9mv DegWkxk8- Received: from [209.131.62.115] by web31809.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 13:42:18 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346789995.43005.YahooMailNeo@web31810.mail.mud.yahoo.com> Message-ID: <1346791338.14378.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 13:42:18 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [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: Tue, 04 Sep 2012 20:42:23 -0000 =0A> No, you can't. Your mechanism will NOT know the authz-id because it's = a=0A> GSS mechanism and the SASL part is stripped off. That's what we've be= en=0A> trying to explain. It is not your mech's job to do that anaylsis and= =0A=0A=0AYou're directly contradicting what others have said I think? =0A= =0A=0A=0A=0A=0A----- Original Message -----=0A> From: "Cantor, Scott" =0A> To: William Mills ; Nico Williams <= nico@cryptonector.com>=0A> Cc: Simon Josefsson ; "kitt= en@ietf.org" =0A> Sent: Tuesday, September 4, 2012 1:30 PM= =0A> Subject: Re: [kitten] -06 posted Re: requirements/context/frustration = Re: Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A> On 9/4/12 4:19 PM, "Wi= lliam Mills" wrote:=0A>> =0A>> OAuth can provide bot= h the user identity and the identity of the agent=0A>> using the ctredentia= l.=A0 I don't think you want 2 values for authcid.=0A> =0A> No, but you hav= e to pick one, and then make the other available if you=0A> choose to via G= SS. There is no way to do that via SASL itself, I don't=0A> think.=0A> =0A>= > An OAuth mechanism can validate that the autz-id sent is correct, and=0A>= > in fact if the wrong agent presents a credential it SHOULD fail if that= =0A>> credential was issued for a specific agent/proxy.=0A> =0A> No, you ca= n't. Your mechanism will NOT know the authz-id because it's a=0A> GSS mecha= nism and the SASL part is stripped off. That's what we've been=0A> trying t= o explain. It is not your mech's job to do that anaylsis and=0A> rejection,= it's the application's job. You don't need to say this, =0A> it's=0A> cove= red by SASL.=0A> =0A> You are conflating OAuth's notion of multiple identit= ies with the=0A> authz-id. You can't do that. OAuth's notions have nothing = to do with=0A> SASL's. In effect, there are three in play here, authz-id, a= nd two OAuth=0A> notions that you have to collapse into an authcid for SASL= .=0A> =0A> -- Scott=0A> From nico@cryptonector.com Tue Sep 4 13: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 2EBAE21F849B for ; Tue, 4 Sep 2012 13:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 2ZIJC8lUS5z6 for ; Tue, 4 Sep 2012 13:43:03 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id E204421F853F for ; Tue, 4 Sep 2012 13:43:02 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id A624A2F406D for ; Tue, 4 Sep 2012 13:43:02 -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=Nn7VFH0qfQLF0sDirRRO kyafXX0=; b=Cm6CNLIXaiaPGpuis2xQprtkFPNYjAv12xDbdwITNnMdZuEWPc8h KawO73xshJi0jx7zjSMoysD3Ou4WlxL1eUQN6JxCPESf4zbrtIWvb1F/Kjz7Egb8 R2//7EcRlsBjYiXiXdJvJ6JvLP5zKPpUGRNmwXcjb4IrK3fJGtNGyZA= 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 8C5962F406A for ; Tue, 4 Sep 2012 13:43:02 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so9718791pbb.31 for ; Tue, 04 Sep 2012 13:43:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.196 with SMTP id ow4mr19265713pbb.25.1346791382156; Tue, 04 Sep 2012 13:43:02 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 13:43:02 -0700 (PDT) In-Reply-To: References: <1346778870.59415.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346783533.46750.YahooMailNeo@web31808.mail.mud.yahoo.com> <1346789995.43005.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 15:43:02 -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] -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:43:04 -0000 On Tue, Sep 4, 2012 at 3:40 PM, Nico Williams wrote: > On Tue, Sep 4, 2012 at 3:19 PM, William Mills wrote: >>>Whatever ID OAuth authenticates, that's the authcid. >> >> OAuth can provide both the user identity and the identity of the agent >> using the ctredential. I don't think you want 2 values for authcid. > > This is why I suggested earlier that you report a combination of the > two as the authcid. However, a better suggestion is provided below > based on GSS naming extensions. I should add that if it is absolutely essential that there be no risk of an existing server SASL application not considering *both* IDs then I think you *must* combine the two (unambiguously, parseably) into a single authcid value. > I will repeat: > >> An OAuth mechanism can validate that the autz-id sent is correct, and >> in fact if the wrong agent presents a credential it SHOULD fail if that >> credential was issued for a specific agent/proxy. > > NO. The OAuth mechanism CANNOT INTERPRET OR MODIFY OR PROVIDE an authz-id. And I should clarify: the mechanism is only allowed to transport an application-provided authz-id. Nico -- From cantor.2@osu.edu Tue Sep 4 13:43: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 8D6B421F84B9 for ; Tue, 4 Sep 2012 13:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.813 X-Spam-Level: X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 plYg1Nf26tbE for ; Tue, 4 Sep 2012 13:43:39 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 0214521F84A0 for ; Tue, 4 Sep 2012 13:43:39 -0700 (PDT) Received: from mail57-co1-R.bigfish.com (10.243.78.247) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 20:43:38 +0000 Received: from mail57-co1 (localhost [127.0.0.1]) by mail57-co1-R.bigfish.com (Postfix) with ESMTP id 1A7362E011F; Tue, 4 Sep 2012 20:43:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.37; KIP:(null); UIP:(null); IPV:NLI; H:CIO-KRC-HT01.osuad.osu.edu; RD:cio-krc-ht01.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail57-co1: domain of osu.edu designates 164.107.81.37 as permitted sender) client-ip=164.107.81.37; envelope-from=cantor.2@osu.edu; helo=CIO-KRC-HT01.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail57-co1 (localhost.localdomain [127.0.0.1]) by mail57-co1 (MessageSwitch) id 1346791415858442_8464; Tue, 4 Sep 2012 20:43:35 +0000 (UTC) Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.226]) by mail57-co1.bigfish.com (Postfix) with ESMTP id CC969700045; Tue, 4 Sep 2012 20:43:35 +0000 (UTC) Received: from CIO-KRC-HT01.osuad.osu.edu (164.107.81.37) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 20:43:34 +0000 Received: from CIO-TNC-HT07.osuad.osu.edu (2002:a46b:51ae::a46b:51ae) by CIO-KRC-HT01.osuad.osu.edu (2002:a46b:5115::a46b:5115) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 4 Sep 2012 16:43:31 -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, 4 Sep 2012 16:43:31 -0400 From: "Cantor, Scott" To: Nico Williams , William Mills Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNirNaDj304+GtZUyptIjTd8k0Mpd6md8A///GkwCAAEU2gP//whkAgABHYwD//873AAAI2AyA///buq2AAEgCgP//vd8A Date: Tue, 4 Sep 2012 20:43:30 +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: <58CACF84BAFB1144B2A863750FFCD4DB@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:43:43 -0000 On 9/4/12 4:40 PM, "Nico Williams" wrote: > >The question is: which ID is best to report as the authcid: the user, >or the agent ID? Almost certainly the user. The OAuth mechanism should be evaluating the suitability of the token, and part of that involves the policy decision about who can wield tokens for some set of users, I would imagine. -- Scott From wmills@yahoo-inc.com Tue Sep 4 13:46: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 1157921F8523 for ; Tue, 4 Sep 2012 13:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 HbamZdaSk+Bt for ; Tue, 4 Sep 2012 13:46:51 -0700 (PDT) Received: from nm38-vm7.bullet.mail.ne1.yahoo.com (nm38-vm7.bullet.mail.ne1.yahoo.com [98.138.229.151]) by ietfa.amsl.com (Postfix) with SMTP id 2084B21F84A2 for ; Tue, 4 Sep 2012 13:46:51 -0700 (PDT) Received: from [98.138.90.52] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 04 Sep 2012 20:46:47 -0000 Received: from [98.138.89.195] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 04 Sep 2012 20:46:47 -0000 Received: from [127.0.0.1] by omp1053.mail.ne1.yahoo.com with NNFMP; 04 Sep 2012 20:46:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 670208.10370.bm@omp1053.mail.ne1.yahoo.com Received: (qmail 61229 invoked by uid 60001); 4 Sep 2012 20:46:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346791607; bh=QcEfvJdW0cWV9MKXbFGO5Duja9s4f6wKHtKyilRo9FY=; 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=lX/magnQBmh0r/9ujee4D240DmgfprVtrMqMVTlphKceb2HKac4rul/SInubIr7HZtdKxBfDfDGc8WQaAGf143bTOtprTUcOpw+QqMXOQteI9ZaCuVw3I8maVZ2h1kKbPzrQc14SEc75pQKOdBGcL0QsnjtQA0I56FWGRxbYdcE= 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=R3KURydQvavM8izysghG+Tc1nMl2dW5NCEaIJYe8I65uOAgWGVnaVgImUp2AvrzjbH2aOzeZPWUqLvhdEmTUBIJj6vvI2n4lEHKeQu50nL0QWoEpxX5FzQrjV8bTOnrhuqn4rRP9oJbDddMWvBZ8KGA3Nei8FvKPJoGhbCnpjhk=; X-YMail-OSG: KJpEBdwVM1lTQSUhiBcjlq6eirsMK9OZHd95Lnc4lXEy6Ht 6JfbRWJTStSBn3sMtMEXf0vPlsGuvFj30JO3fVisxnd3ZpRvEAURsq2FE55P p6PQrc3JLWrtvLEccK4vyynW5YKpLB4BU2mOWTRJ0QSYDGRg4wazXz8izijD 92akansJh9RgNgf2Aser2AZ81aUK.UiDX.isp.cCvFBXDAwXgKvNnEHKSt60 AGsNW1zEKIq7BF76qNNExyjvFglIiQXnxqFvTKC5vCDA.8a2ZXa57viSF6e7 7wxurlnqZLibH.LVJINTKlhJmqdPZ1a0X6iDGr.lvY2h9BBJ0rnNNA4xRWKm X8XfvWAsfqzWNnuyoMvZTunQecenwito.9VVMPM_LjcuUdd2x7ZRuCgM80Gp sfLtZa7Ibov0SBxbnzxug9.i61W4LLkLhGloqwCdk23be0cuUDePIBD7ZYcs Ak6ZhziXg Received: from [209.131.62.115] by web31802.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 13:46:47 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346778870.59415.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346783533.46750.YahooMailNeo@web31808.mail.mud.yahoo.com> <1346789995.43005.YahooMailNeo@web31810.mail.mud.yahoo.com> Message-ID: <1346791607.54023.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 13:46:47 -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] -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: Tue, 04 Sep 2012 20:46:52 -0000 So it appears we have come around to the point where authz-id is useless in= this context for what I need.=A0 I should ignore it completely, and put th= e user field back into the SASL payload because we want that in plain text?= =0A=0A=0A=0A=0A----- Original Message -----=0A> From: Nico Williams =0A> To: William Mills =0A> Cc: "Cant= or, Scott" ; Simon Josefsson ; "kitt= en@ietf.org" =0A> Sent: Tuesday, September 4, 2012 1:40 PM= =0A> Subject: Re: [kitten] -06 posted Re: requirements/context/frustration = Re: Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A> On Tue, Sep 4, 2012 at= 3:19 PM, William Mills =0A> wrote:=0A>>> Whatever I= D OAuth authenticates, that's the authcid.=0A>> =0A>> OAuth can provide bo= th the user identity and the identity of the agent=0A>> using the ctredent= ial.=A0 I don't think you want 2 values for authcid.=0A> =0A> This is why I= suggested earlier that you report a combination of the=0A> two as the auth= cid.=A0 However, a better suggestion is provided below=0A> based on GSS nam= ing extensions.=0A> =0A> I will repeat:=0A> =0A>> An OAuth mechanism can v= alidate that the autz-id sent is correct, and=0A>> in fact if the wrong ag= ent presents a credential it SHOULD fail if that=0A>> credential was issue= d for a specific agent/proxy.=0A> =0A> NO.=A0 The OAuth mechanism CANNOT IN= TERPRET OR MODIFY OR PROVIDE an authz-id.=0A> =0A> Given that you have *two= * IDs to report in the authcid vein, where=0A> SASL only allows *one*, we h= ave what appears to be a fundamental=0A> incompatibility between OAuth and = SASL.=A0 We *can* address this as=0A> follows:=0A> =0A> - make one of the u= ser or agent IDs the authcid=0A> =0A> - treat the other of those two IDs as= a GSS name attribute=0A> =0A> It's perfectly fine to extend existing SASL = APIs to provide the second=0A> ID in some way other than by exposing a GSS = NAME object to the=0A> application.=0A> =0A> The question is: which ID is b= est to report as the authcid: the user,=0A> or the agent ID?=0A> =0A> Nico= =0A> --=0A> From nico@cryptonector.com Tue Sep 4 13:47: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 D1C0421F84DF for ; Tue, 4 Sep 2012 13:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 YK8UYQQc-eik for ; Tue, 4 Sep 2012 13:47:34 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 36F1821F84A2 for ; Tue, 4 Sep 2012 13:47:27 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 932A8202038 for ; Tue, 4 Sep 2012 13:47:26 -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=WIfB+BMyak5Ajoz3DUcZ zS7m0Uo=; b=TcYfmQ/2EF0ra7XLOzxk1HbP71NlpPJBvDfHdksMY+a2BRUgTp3Z soGNp8EphdJLLWbNbWhdFYJWf47lp2WfqeDqxB6grUJS1pylDNLVgT9pPCS1W9gC RrBynwuWKDPERoO/Dl+M1NqcWkyT7ADKGI6B0Ide4uk1ZwxImBj4HCo= 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 4810B202022 for ; Tue, 4 Sep 2012 13:47:26 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so9723541pbb.31 for ; Tue, 04 Sep 2012 13:47:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr46735329pbc.149.1346791645816; Tue, 04 Sep 2012 13:47:25 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 13:47:25 -0700 (PDT) In-Reply-To: <1346791338.14378.YahooMailNeo@web31809.mail.mud.yahoo.com> References: <1346789995.43005.YahooMailNeo@web31810.mail.mud.yahoo.com> <1346791338.14378.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 15:47:25 -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] -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:47:34 -0000 On Tue, Sep 4, 2012 at 3:42 PM, William Mills wrote: > >> No, you can't. Your mechanism will NOT know the authz-id because it's a >> GSS mechanism and the SASL part is stripped off. That's what we've been >> trying to explain. It is not your mech's job to do that anaylsis and > > > You're directly contradicting what others have said I think? I'm not. The authz-id, for the umpteenth time (subtext: I'm frustrated that you do not appear to acknowledge this), is from a namespace, and of a syntax that are specified by the application protocol. And the mechanism does not and CANNOT know what that protocol is. Indeed, the set of application protocols is *open*, so that even if the mechanism could know what application is using it, it cannot know the application protocol's authz-id namespace and syntax. So there's simply nothing that the mechanism can do with the authz-id other than to transport it. Nico -- From cantor.2@osu.edu Tue Sep 4 13:47: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 B3BA921F8594 for ; Tue, 4 Sep 2012 13:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[AWL=-0.188, 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 66sZl8yKeDVu for ; Tue, 4 Sep 2012 13:47:51 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0B521F8592 for ; Tue, 4 Sep 2012 13:47:51 -0700 (PDT) Received: from mail205-co1-R.bigfish.com (10.243.78.239) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 20:47:50 +0000 Received: from mail205-co1 (localhost [127.0.0.1]) by mail205-co1-R.bigfish.com (Postfix) with ESMTP id 89972140173; Tue, 4 Sep 2012 20:47:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail205-co1: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail205-co1 (localhost.localdomain [127.0.0.1]) by mail205-co1 (MessageSwitch) id 1346791668698624_32690; Tue, 4 Sep 2012 20:47:48 +0000 (UTC) Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.232]) by mail205-co1.bigfish.com (Postfix) with ESMTP id A6E99C80042; Tue, 4 Sep 2012 20:47:48 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 20:47:47 +0000 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; Tue, 4 Sep 2012 16:47:23 -0400 From: "Cantor, Scott" To: William Mills Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNirNaDj304+GtZUyptIjTd8k0Mpd6md8A///GkwCAAEU2gP//whkAgABHYwD//873AAAI2AyA///buq2AAAIvgIAARm8A//++WIA= Date: Tue, 4 Sep 2012 20:47:24 +0000 Message-ID: In-Reply-To: <1346791338.14378.YahooMailNeo@web31809.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:47:51 -0000 On 9/4/12 4:42 PM, "William Mills" wrote: > >> No, you can't. Your mechanism will NOT know the authz-id because it's a >> GSS mechanism and the SASL part is stripped off. That's what we've been >> trying to explain. It is not your mech's job to do that anaylsis and > >You're directly contradicting what others have said I think? I don't believe I am, no. We've said over and over that the authz-id is not a concept that you will see in GSS or in your mechanism itelf because it's a SASL/application layer issue to pass it and process it. Your mechanism knows nothing about it. You are conflating that authz-id with the second ID in the OAuth token and they are not the same. -- Scott From nico@cryptonector.com Tue Sep 4 13: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 E1ABC11E80A6 for ; Tue, 4 Sep 2012 13:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 ootgEw0aWs4r for ; Tue, 4 Sep 2012 13:50:48 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id CBBB911E80A4 for ; Tue, 4 Sep 2012 13:50:47 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 1841E58406A for ; Tue, 4 Sep 2012 13:50: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=8bdzW/txpqqcjcDQkRyP tsLLp5I=; b=J4PVNQ1nZ5iszdS98oN+HmUowjfLBk8PYl0W1Fw9/zAu6YcoqLri CTJ+EcF6joUwz0Zs42ntV91TKQ9hgD8HVUNOd52fPJ7GedLtJO+4B/4oxkj9WN12 tX5nAv901zIP71oSAyCL9SU4WeUFOYFfWpdsnN5OfeZaKIztEVO1wOY= 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 EC8A0584064 for ; Tue, 4 Sep 2012 13:50:46 -0700 (PDT) Received: by dadf8 with SMTP id f8so4405265dad.31 for ; Tue, 04 Sep 2012 13:50:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr46751742pbc.149.1346791846597; Tue, 04 Sep 2012 13:50:46 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 13:50:46 -0700 (PDT) In-Reply-To: <1346791607.54023.YahooMailNeo@web31802.mail.mud.yahoo.com> References: <1346778870.59415.YahooMailNeo@web31805.mail.mud.yahoo.com> <1346783533.46750.YahooMailNeo@web31808.mail.mud.yahoo.com> <1346789995.43005.YahooMailNeo@web31810.mail.mud.yahoo.com> <1346791607.54023.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 15:50:46 -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] -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:50:50 -0000 On Tue, Sep 4, 2012 at 3:46 PM, William Mills wrote: > So it appears we have come around to the point where authz-id is useless in this context for what I need. I should ignore it completely, and put the user field back into the SASL payload because we want that in plain text? The user field would be in what would be the GSS payload. It's fine there. But I thought that OAuth surely already had ways to indicate both IDs anyways -- what am I missing? From cantor.2@osu.edu Tue Sep 4 13:54: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 B59C821E8040 for ; Tue, 4 Sep 2012 13:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.766 X-Spam-Level: X-Spam-Status: No, score=-3.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 iqqSGwJcyuFN for ; Tue, 4 Sep 2012 13:54:58 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 18A5511E80A6 for ; Tue, 4 Sep 2012 13:54:58 -0700 (PDT) Received: from mail166-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 20:54:57 +0000 Received: from mail166-va3 (localhost [127.0.0.1]) by mail166-va3-R.bigfish.com (Postfix) with ESMTP id 0B2992600BF; Tue, 4 Sep 2012 20:54:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.40; KIP:(null); UIP:(null); IPV:NLI; H:CIO-KRC-HT02.osuad.osu.edu; RD:cio-krc-ht02.osuad.osu.edu; EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zzbb2dI98dI9371Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail166-va3: domain of osu.edu designates 164.107.81.40 as permitted sender) client-ip=164.107.81.40; envelope-from=cantor.2@osu.edu; helo=CIO-KRC-HT02.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail166-va3 (localhost.localdomain [127.0.0.1]) by mail166-va3 (MessageSwitch) id 1346792078497489_18592; Tue, 4 Sep 2012 20:54:38 +0000 (UTC) Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.239]) by mail166-va3.bigfish.com (Postfix) with ESMTP id 7475D360045; Tue, 4 Sep 2012 20:54:38 +0000 (UTC) Received: from CIO-KRC-HT02.osuad.osu.edu (164.107.81.40) by VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 20:54:36 +0000 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, 4 Sep 2012 16:54:32 -0400 From: "Cantor, Scott" To: William Mills , Nico Williams Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNirNaDj304+GtZUyptIjTd8k0Mpd6md8A///GkwCAAEU2gP//whkAgABHYwD//873AAAI2AyA///buq2AAEgCgIAAAdyA//+/GYA= Date: Tue, 4 Sep 2012 20:54:32 +0000 Message-ID: In-Reply-To: <1346791607.54023.YahooMailNeo@web31802.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: <3FD39FE51BB3304BB4112837E5124F04@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:54:58 -0000 On 9/4/12 4:46 PM, "William Mills" wrote: >So it appears we have come around to the point where authz-id is useless >in this context for what I need. I should ignore it completely, and put >the user field back into the SASL payload because we want that in plain >text? No, that is not IMHO what you want. You could break GSS support by creating your own field to carry the authz-id in SASL, but you would still be breaking the essential abstraction by trying to tie the authz-id to something inside the OAuth token and you just shouldn't (possibly even "can't") do that. If you need to expose both OAuth identities to the application you can't solve that by trying to make one of them the authz-id. You simply don't control that field, the application protocol does. In this particular case, I really don't think you have a problem. The OAuth token is issued for some user identity. The fact that there may be a delegate identity is useful to know in some contexts but I think for the vast majority of cases, it's consumed by the OAuth mechanism, validated against policy, and that's that. It's the user's identity that you surface. -- Scott From nico@cryptonector.com Tue Sep 4 13:59: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 90E0021E8040 for ; Tue, 4 Sep 2012 13:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 2+i7qWzwDr82 for ; Tue, 4 Sep 2012 13:59:36 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id D0C6711E80A4 for ; Tue, 4 Sep 2012 13:59:36 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 841607E407C for ; Tue, 4 Sep 2012 13:59: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=J2FNr1Amc6cqnKI+q/pd 8H6yzjQ=; b=AgoUn1bk1iEedeUbm5iCYveEIKKcZffgDYDGeQumQIishsJxDJNi LujUBQphPiCO6omDMKvo8Z4tmHu2USzJQ0RTLA6IyQ9k0V2TrftgbaPouKRR3aQK koloNCp7htDZWa0EmcgT/XHwg7dMHctxTVfGrQlPQ5OKDW935W6qqgY= 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 68B087E4072 for ; Tue, 4 Sep 2012 13:59:36 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so9736204pbb.31 for ; Tue, 04 Sep 2012 13:59:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr46796376pbc.149.1346792376058; Tue, 04 Sep 2012 13:59:36 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 13:59:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Sep 2012 15:59:35 -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] GSS name type (was Re: -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:59:37 -0000 On Tue, Sep 4, 2012 at 3:13 PM, Cantor, Scott wrote: > On 9/4/12 4:04 PM, "Nico Williams" wrote: >> >>GSS_Accept_sec_context() outputs the NAME of the initiator. This >>corresponds to the SASL authcid -- the ID authenticated by the >>mechanism. >> >>The constant "GSS_C_NT_USER_NAME" is a red herring here :) > > I was told it's not really a red herring, because there are lots of GSS > apps that just flat won't work unless the name's in that form from the > mechanism, or at least translatable into it I suppose. You can generally use any name type in the GSS_Import_name() call that the mechanism supports. HOWEVER, the name type reported by GSS_Display_name() on an MN (specifically: the name returned by GSS_Accept_sec_context() for the initator principal, or the names returned by GSS_Inquire_context()) can and typically are mechanism-specific. The classic example of this is the Kerberos mechanism. Since the concept of "name type" is informative in the Kerberos protocol, and since it's often lost, most (if not all) of the acceptor implementations return GSS_KRB5_NT_PRINCIPAL_NAME as the name type of MNs. In the GSS naming extensions document (which is on the RFC-Editor queue and practically done) we added a function for displaying a name as a given generic name type if possible: GSS_Display_name_ext(). With this function you could ask the mechanism to display an MN as a GSS_C_NT_USER_NAME, and it will fail if that makes no sense. A Kerberos mechanism implementation might simply do this only for a) principals from the "default" realm (or the same realm as the acceptor princ, perhaps), b) that have a single component in their name (a Kerberos implementation on an OS that supports users from multiple domains might only apply (b)). Nico -- From nico@cryptonector.com Tue Sep 4 14:14: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 C191E21E805A for ; Tue, 4 Sep 2012 14:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 isgQdvQRwkSx for ; Tue, 4 Sep 2012 14:14:13 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0E22021E8040 for ; Tue, 4 Sep 2012 14:14:13 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id B3FF72AC073 for ; Tue, 4 Sep 2012 14:14: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=niTBJJ9NEouzkmSCUXll jehFR8g=; b=jCZgjPmwo7vmVcE9hzlabj5auGWylx1bB1pGP8YXBGOqYLA6ctxM aPX4xBnuykJl7URLAQJ1H1o4Q5x1GpxWaT9Ki+I78fJH57TVzUo+MccDIY6tCqkQ 9qvn85Nt7Kb46AB6xqmtNhkEGdToUJaBvbLkm6iyIKO/+9ep9r0K9cM= 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-a90.g.dreamhost.com (Postfix) with ESMTPSA id 8751C2AC06A for ; Tue, 4 Sep 2012 14:14:12 -0700 (PDT) Received: by dadf8 with SMTP id f8so4416452dad.31 for ; Tue, 04 Sep 2012 14:14:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.75.133 with SMTP id c5mr44305715paw.24.1346793252000; Tue, 04 Sep 2012 14:14:12 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 14:14:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Sep 2012 16:14:11 -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] GSS name type (was Re: -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 21:14:13 -0000 I should add that mechanisms with a single name-type can and should use the generic name types in their GSS_Display_name() implementations. But even OAuth surely can handle more than one name type? Sure, users are users, but agents are not. Of course, we could pretend that agents are users, but we cannot impose a naming convention for agents and say that they are usernames: generic GSS apps wouldn't know about that convention. True, generic GSS apps may not know about new name types either (should we need one here), but then, generic GSS apps are supposed to use the exported name token as the driver for authorization (and now also the naming extensions, of course). In practice pre-naming extensions GSS acceptor (server) apps come in several flavors: - those that parse mech-specific name type (sigh) - those that use exported name tokens as a lookup key - those that effectively implement some extension by which to ask the mechanism for "cooked" authz data (a "get an access token" or "get a UID and a list of GIDs" function) - those that effectively implement some extension by which the mechanism can implement an authorization function (a "userok" function) Nico -- From cantor.2@osu.edu Tue Sep 4 14:27: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 2CD6421E809D for ; Tue, 4 Sep 2012 14:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ProTg6Hxposj for ; Tue, 4 Sep 2012 14:27:05 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6F20821E8040 for ; Tue, 4 Sep 2012 14:27:02 -0700 (PDT) Received: from mail89-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 21:27:01 +0000 Received: from mail89-tx2 (localhost [127.0.0.1]) by mail89-tx2-R.bigfish.com (Postfix) with ESMTP id 709F43E0125; Tue, 4 Sep 2012 21:27:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1418Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail89-tx2: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail89-tx2 (localhost.localdomain [127.0.0.1]) by mail89-tx2 (MessageSwitch) id 1346794018832472_30089; Tue, 4 Sep 2012 21:26:58 +0000 (UTC) Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.254]) by mail89-tx2.bigfish.com (Postfix) with ESMTP id C83A760048; Tue, 4 Sep 2012 21:26:58 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by TX2EHSMHS044.bigfish.com (10.9.99.144) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 21:26:56 +0000 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; Tue, 4 Sep 2012 17:26:55 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] GSS name type (was Re: -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05) Thread-Index: AQHNiuI8a1ZxuVOkVE6tX1IHkACeuZd6sjyA Date: Tue, 4 Sep 2012 21:26:55 +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: <3B35D8D441F1B94488BC42FFBDCEBFB8@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS name type (was Re: -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 21:27:06 -0000 On 9/4/12 5:14 PM, "Nico Williams" wrote: >I should add that mechanisms with a single name-type can and should >use the generic name types in their GSS_Display_name() >implementations. I'll have to dig into my notes from this summer to ask anything more specific, but I believe we ran into constraints that made it impractical to define a new name-type and accomplish much with it using existing target applications. But I could be confused about what the problem was. I just know that at the moment I have not yet defined any SAML name-types. >In practice pre-naming extensions GSS acceptor (server) apps come in >several flavors: This is much of what's missing when one sets out to define a mechanism. >- those that effectively implement some extension by which the >mechanism can implement an authorization function (a "userok" >function) I think this is missing from the conversation because that function takes the moral equivalent (perhaps the actual equivalent) of the authz-id from SASL as input. So when William says "my mech needs that ID", I think this is how it gets it. Not during processing of the mechanism exchange itself but in an authorization hook. But since that hook is nowhere in any specs, that's not clear to mech authors. And to elaborate on that, I think that if the mechanism implementer wanted to impose a rule that the userok() code compared the proposed value to something in the OAuth token, it could do so. But not as a matter of mechanism specification, only implementation. -- Scott From nico@cryptonector.com Tue Sep 4 14:37: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 E542221E8082 for ; Tue, 4 Sep 2012 14:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 0pcslqDxb6Fz for ; Tue, 4 Sep 2012 14:37:05 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4876A21E805A for ; Tue, 4 Sep 2012 14:37:05 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 06D896B007C for ; Tue, 4 Sep 2012 14:37: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=FAPOi+lTmtib23CoOaHR ofn2VDk=; b=RWGpmFu6fhZtgN+grIF45ca4xUcMqobPdu0yhEUqTcaMINi8IEKi CyDgV9gZ3h5yoXHRvGXwtynlizT3rFl6feT1+I+/uU1uFQGtGt2lsMhxtVet982F KtN/TuZ1qxqx2pmg1pyP53E6Xz250Okv5/3BERHJdoTPEbVBeLz5QWk= 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 E5B6F6B0078 for ; Tue, 4 Sep 2012 14:37:04 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so9774785pbb.31 for ; Tue, 04 Sep 2012 14:37:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.77.7 with SMTP id o7mr44003551paw.37.1346794624541; Tue, 04 Sep 2012 14:37:04 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 14:37:04 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Sep 2012 16:37:04 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS name type (was Re: -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 21:37:06 -0000 On Tue, Sep 4, 2012 at 4:26 PM, Cantor, Scott wrote: > On 9/4/12 5:14 PM, "Nico Williams" wrote: > >>I should add that mechanisms with a single name-type can and should >>use the generic name types in their GSS_Display_name() >>implementations. > > I'll have to dig into my notes from this summer to ask anything more > specific, but I believe we ran into constraints that made it impractical > to define a new name-type and accomplish much with it using existing > target applications. But I could be confused about what the problem was. I > just know that at the moment I have not yet defined any SAML name-types. Any GSS mechanism specification kinda needs to cover this :) For SCRAM it was rather easy. >>In practice pre-naming extensions GSS acceptor (server) apps come in >>several flavors: > > This is much of what's missing when one sets out to define a mechanism. Well, some of this is covered in RFC2743, but not all, and very dryly anyways... >>- those that effectively implement some extension by which the >>mechanism can implement an authorization function (a "userok" >>function) > > I think this is missing from the conversation because that function takes > the moral equivalent (perhaps the actual equivalent) of the authz-id from > SASL as input. So when William says "my mech needs that ID", I think this > is how it gets it. Not during processing of the mechanism exchange itself > but in an authorization hook. A userok function takes an authcid and authz-id and returns TRUE or FALSE: TRUE if the authcid is allowed access to the given authz-id. Except that typically a userok function only applies to one particular authz-id namespace/syntax. The traditional examples are krb5_kuserok() and gss_userok(), which treat the authz-id as a Unix username. An LDAP server would first have to map the SASL authz-id onyo a Unix username if it wanted to use such a userok() function. > But since that hook is nowhere in any specs, that's not clear to mech > authors. In practice authorization is a local problem, so a mechanism specification can't really say much about it. Of course, with SAML and fine-grained authorization data delivered by mechanisms the situation changes somewhat: we can now at least specify that fine-grained authz data and we can cover enough use cases with it that generic, portable mechanisms applications are now feasible. > And to elaborate on that, I think that if the mechanism implementer wanted > to impose a rule that the userok() code compared the proposed value to > something in the OAuth token, it could do so. But not as a matter of > mechanism specification, only implementation. Indeed! Nico -- From nico@cryptonector.com Tue Sep 4 14:49: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 A7A6721E8092 for ; Tue, 4 Sep 2012 14:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 r3B+NrO0U8V5 for ; Tue, 4 Sep 2012 14:49:58 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 1410B21E805A for ; Tue, 4 Sep 2012 14:49:58 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id C419821DE6A for ; Tue, 4 Sep 2012 14:49: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=VXeav6G3sbjjGKPxvZkm F2xI8QU=; b=vQOl919vyppZpHE1CWmFMshdiWOEHh9XxiCoETkEdFG1AHnv+JRg m2EiI+wIGME0bdFXPumSOxc16EPBPPdfLYbIeZ5XHgFCPzreIc4FbILBs81G9r24 XoY7aay/xVas3zh0U5tkpqJ5ufUSLMsmJri9FlAUkhsTMGY6JDpHckg= 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-a30.g.dreamhost.com (Postfix) with ESMTPSA id 9936121DE59 for ; Tue, 4 Sep 2012 14:49:57 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so9787480pbb.31 for ; Tue, 04 Sep 2012 14:49:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.83.166 with SMTP id r6mr43691063pay.25.1346795396948; Tue, 04 Sep 2012 14:49:56 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 14:49:56 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Sep 2012 16:49:56 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS name type (was Re: -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 21:49:58 -0000 It's interesting how to a large extent these are generic matters, not ones specific to GSS or SASL. These problems and concepts show up in pure TLS apps too. You also get why we needed naming extensions... BTW, I wish we'd added a function by which to list the generic name types that an MN could be interpreted as... I wish we'd covered the issuer name issue in time as well. HOWEVER, Sam and I have realized that a lot of these "I wish we'd added this other naming extension" cases can almost all be handled... via the name attributes concept anyways. For example, the NAME of the issuer of an MN could be obtained by asking for the value of an attribute that is the issuer. The raw value(s) would be the exported name token form of the issuer NAME, and the display_value(s) would be the display form! And to get the issuer of a given attribute value? Just prefix that issuer attribute URI to the attribute in question! The concept of composable attribute names is extremely powerful. Let's call these prefixes "meta-attributes". This is something I've been meaning to write an I-D about. The first set of meta-attributes I want to define: - issuer (this would correspond to 'realm' in the case of the Kerberos mechanism) - trust transit path (here the set of values would form the path) (remember, in GSS sets are order-preserving) - the transit policy checked flag Nico -- From cantor.2@osu.edu Tue Sep 4 14:53: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 899A221E80A2 for ; Tue, 4 Sep 2012 14:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.872 X-Spam-Level: X-Spam-Status: No, score=-3.872 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 NZpTpswU6aFF for ; Tue, 4 Sep 2012 14:53:32 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id CBFA821E8098 for ; Tue, 4 Sep 2012 14:53:31 -0700 (PDT) Received: from mail34-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 21:53:30 +0000 Received: from mail34-co1 (localhost [127.0.0.1]) by mail34-co1-R.bigfish.com (Postfix) with ESMTP id DF6673000B4; Tue, 4 Sep 2012 21:53:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.40; KIP:(null); UIP:(null); IPV:NLI; H:CIO-KRC-HT02.osuad.osu.edu; RD:cio-krc-ht02.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail34-co1: domain of osu.edu designates 164.107.81.40 as permitted sender) client-ip=164.107.81.40; envelope-from=cantor.2@osu.edu; helo=CIO-KRC-HT02.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail34-co1 (localhost.localdomain [127.0.0.1]) by mail34-co1 (MessageSwitch) id 1346795609673889_21252; Tue, 4 Sep 2012 21:53:29 +0000 (UTC) Received: from CO1EHSMHS006.bigfish.com (unknown [10.243.78.225]) by mail34-co1.bigfish.com (Postfix) with ESMTP id A08F2460047; Tue, 4 Sep 2012 21:53:29 +0000 (UTC) Received: from CIO-KRC-HT02.osuad.osu.edu (164.107.81.40) by CO1EHSMHS006.bigfish.com (10.243.66.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 21:53:27 +0000 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; Tue, 4 Sep 2012 17:53:26 -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, 4 Sep 2012 17:53:25 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] GSS name type (was Re: -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05) Thread-Index: AQHNiuI8a1ZxuVOkVE6tX1IHkACeuZd6sjyAgABF5wD//8F+gA== Date: Tue, 4 Sep 2012 21:53:24 +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: <0A1F9AF45DEA464D84B04381BFA6CE01@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS name type (was Re: -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 21:53:34 -0000 On 9/4/12 5:37 PM, "Nico Williams" wrote: >> >> I'll have to dig into my notes from this summer to ask anything more >> specific, but I believe we ran into constraints that made it impractical >> to define a new name-type and accomplish much with it using existing >> target applications. But I could be confused about what the problem >>was. I >> just know that at the moment I have not yet defined any SAML name-types. > >Any GSS mechanism specification kinda needs to cover this :) Cover it, yes, but not necessary define anything new, or am I wrong? I peeked at some old emails, and I think the problem was that on the client, with a GSS-only app, you import a name that's got to be understandable to the user (the thing he types in) and that's by necessity going to imported via a simple name-type. Turning that into a SAML name-type has no value because it doesn't mean anything. It won't match what the IdP actually issues as a SAML name, etc. It also means nothing as a format for building ACLs because nobody's going to build ACLs based on SAML names (if they even could, usually not). So that left no use case for defining a name-type that would carry the "native" SAML name. What is the use case that would require it? -- Scott From nico@cryptonector.com Tue Sep 4 15:12: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 E9FB621F84C9 for ; Tue, 4 Sep 2012 15:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 OENyWllVIe1k for ; Tue, 4 Sep 2012 15:12:30 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 632A121F84B9 for ; Tue, 4 Sep 2012 15:12:30 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 2A98F9406B for ; Tue, 4 Sep 2012 15:12: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=s+mmx5vp+IGWGLGYBw9k JCh5Vso=; b=kfPO5JlrZiUR7YldKfgOUtSOd50r+qDBsyvQBteYYIoFQ960JhOh OJVdwytZ6dvedMtxNVG54/ppR7V59aFUuCvWVcsXkYVt3K7jIFm6Y6MS1QJE5ZHF kFoyoJCP7ATQWnwX0SjAixaH7ON0+hN2pWhqdsEIrAU70aDmFERXA9Q= 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 02D6694059 for ; Tue, 4 Sep 2012 15:12:24 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so9808914pbb.31 for ; Tue, 04 Sep 2012 15:12:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.83.166 with SMTP id r6mr43796165pay.25.1346796744681; Tue, 04 Sep 2012 15:12:24 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 15:12:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Sep 2012 17:12:24 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS name type (was Re: -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 22:12:36 -0000 On Tue, Sep 4, 2012 at 4:53 PM, Cantor, Scott wrote: > On 9/4/12 5:37 PM, "Nico Williams" wrote: >>> >>> I'll have to dig into my notes from this summer to ask anything more >>> specific, but I believe we ran into constraints that made it impractical >>> to define a new name-type and accomplish much with it using existing >>> target applications. But I could be confused about what the problem >>>was. I >>> just know that at the moment I have not yet defined any SAML name-types. >> >>Any GSS mechanism specification kinda needs to cover this :) > > Cover it, yes, but not necessary define anything new, or am I wrong? The minimum a GSS mech spec must do is: - specify what generic name types (if any) it supports - specify what mechanism-specific namet types (if any) it supports - the mech must support at least one name type - for an Internet standards-track mech it really should support at least GSS_C_NT_HOSTBASED_SERVICE - specify how to map from generic name forms to mechanism-specific name forms, including, too, how to "canonicalize" names (but see below) - specify an exported name token format Optional: - for naming extensions a mech spec should also specify how to map an MN to a give name type. And possibly (I want to add this) how to determine what generic name types an MN can be displayed as. - specify how to compare names > I peeked at some old emails, and I think the problem was that on the > client, with a GSS-only app, you import a name that's got to be > understandable to the user (the thing he types in) and that's by necessity > going to imported via a simple name-type. Turning that into a SAML > name-type has no value because it doesn't mean anything. It won't match > what the IdP actually issues as a SAML name, etc. Right. This mostly is about how we go from what the user typed in to what the mechanism wants under the hood. The authorization problem is less critical because as long as you specify an exported name token format you can do *something*. > It also means nothing as a format for building ACLs because nobody's going > to build ACLs based on SAML names (if they even could, usually not). So > that left no use case for defining a name-type that would carry the > "native" SAML name. What is the use case that would require it? Well, the canonical method of authorization in RFC2743 is to call GSS_Export_name() and then do octet string comparisons (length + memcmp()) or lookups using the exported name tokens... That's... kinda difficult to use effectively in practice because that means that GSS dictates ACL form, and because name canonicalization is a bit of a thing of the past in a world of fine-grained authorization and of privacy protecting gateways. And who wants the security framework to dictate their ACLs? Active Directory and NTFS use ACL forms dictated by the OS, not by GSS, and that's just one example. It's hard to imagine an RFC2743-pure world of applications. [Sure, we could pretend that privacy-protected names are just anonymous names, but we still need to use the fine-grained authz data delivered by the mechanism. But this only covers some use cases and requires naming extensions anyways. Another thing we could do is to encode all the fine-grained authz data into the display name form, but that's no good from a usability perspective. And we can't encode fine-grained authz data in exported name tokens because that would break any RFC2743-pure apps that exist (some do). The only real choice we have is to use naming extensions.] I think we now want to say that sorry, some mechanisms don't support "canonical names", and/or don't support a canonicalization service (specifically: GSS_Canonicalize_name()), and/or don't support GSS_Export_name(). Such mechanisms are only really usable in conjunction with GSS naming extensions, therefore they must support those. Nico -- From wmills@yahoo-inc.com Tue Sep 4 15:27: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 5EE9E21E8092 for ; Tue, 4 Sep 2012 15:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 fQRmOsqNpPfs for ; Tue, 4 Sep 2012 15:27:00 -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 932DD21E805A for ; Tue, 4 Sep 2012 15:27:00 -0700 (PDT) Received: from [98.139.52.195] by nm4.bullet.mail.ac4.yahoo.com with NNFMP; 04 Sep 2012 22:26:57 -0000 Received: from [98.139.52.147] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 04 Sep 2012 22:26:57 -0000 Received: from [127.0.0.1] by omp1030.mail.ac4.yahoo.com with NNFMP; 04 Sep 2012 22:26:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 509445.69617.bm@omp1030.mail.ac4.yahoo.com Received: (qmail 57094 invoked by uid 60001); 4 Sep 2012 22:26:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346797616; bh=8r2V0a00YJEV8QI+baoC1uc4I2A3xazdD9czY8PuXz0=; 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=MURNqgNqxQjr83dCbPP8MYs+2n+jWaUiazaflBCVpEWbazJL4Ek48IIgzT9ufKw5vhB3SCDjkT5u2V36ff4CxJhMk6OmGEV/uQGyoLGGQ8hZH0v7Wff9dv5GhdaQOe1HXhsYvf4qj8tHRFe2e0FGIBMHvrM9AktfsZHiPjSm/yE= 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=QVuWh3LKCSgoehKfRoTK5FHIngSJrc4EFX1C9Jw1AZVrKRi6ODxIvFY5IfRXnsH39AX7SyZ0BGNfFq7/NLjMf2tlG4yPkQ2VXLSquDy7dqxBT6C9HyA5PvnpxZsqamC4cVLJ+JVZ7z4Mu8xutsuO7RDkkahZ37GsGtuwKAkfKbQ=; X-YMail-OSG: ijkZdXgVM1m0S1x1REeuAQrRWOVTh.Wqrzy2oHU.ygqjP1u UKJ7mclbE66CRXuKSY1WFqccWng7xJOV3AYiXAXSeppdi8.0PVXA4bVpiHEh xI4._NlJPHsnu0D4uNxFdg9aRmVL_sbV6ScTQm_RoARe5lOsO4kVlKbteKuo ewLZKmC3VXPjC8.aiDihHm7AD_y7ohkMXigilnXIsLzYL5DBzvkkb4J._xoQ PWwk4lacr4rMWTi0Rj.NKolJ_6xCnPAqLlEBmd0_6OwDXntQOOLfGmc5wVVV Qnax.MCR_I314KSJpWPetZfIPv3_t5fo.2By8XhIMQsyy.4EPgo0Waz5WG.9 WS3fuTvGCawYYkyStBGrgIYeM7zyZXz0pywMmuQwsTKeSn43H61CFTj0UnqI _NYBEWmVvnqooRUs0GeKtTPiYBOLXeneetiQv5_mBYAZU Received: from [99.31.212.42] by web31807.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 15:26:56 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346791607.54023.YahooMailNeo@web31802.mail.mud.yahoo.com> Message-ID: <1346797616.19925.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 15:26:56 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [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: Tue, 04 Sep 2012 22:27:01 -0000 No you're confused.=A0 I don't care at all about the actual authz-id.=A0 Fo= rget that part.=A0 Help me solve the problem of having a plain text copy of= the user identity for the resource being accessed available to the mechani= sm.=0A=0A=0A=0A=0A----- Original Message -----=0A> From: "Cantor, Scott" =0A> To: William Mills ; Nico William= s =0A> Cc: Simon Josefsson ; "k= itten@ietf.org" =0A> Sent: Tuesday, September 4, 2012 1:54= PM=0A> Subject: Re: [kitten] -06 posted Re: requirements/context/frustrati= on Re: Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A> On 9/4/12 4:46 PM, = "William Mills" wrote:=0A> =0A>> So it appears we ha= ve come around to the point where authz-id is useless=0A>> in this context = for what I need.=A0 I should ignore it completely, and put=0A>> the user fi= eld back into the SASL payload because we want that in plain=0A>> text?=0A>= =0A> No, that is not IMHO what you want. You could break GSS support by=0A= > creating your own field to carry the authz-id in SASL, but you would stil= l=0A> be breaking the essential abstraction by trying to tie the authz-id t= o=0A> something inside the OAuth token and you just shouldn't (possibly eve= n=0A> "can't") do that.=0A> =0A> If you need to expose both OAuth identitie= s to the application you can't=0A> solve that by trying to make one of them= the authz-id. You simply don't=0A> control that field, the application pro= tocol does.=0A> =0A> In this particular case, I really don't think you have= a problem. The=0A> OAuth token is issued for some user identity. The fact = that there may be a=0A> delegate identity is useful to know in some context= s but I think for the=0A> vast majority of cases, it's consumed by the OAut= h mechanism, validated=0A> against policy, and that's that. It's the user's= identity that you =0A> surface.=0A> =0A> -- Scott=0A> From cantor.2@osu.edu Tue Sep 4 15:33: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 F030321E8082 for ; Tue, 4 Sep 2012 15:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 0ezrbGYLYj1t for ; Tue, 4 Sep 2012 15:33:33 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 4785521E805A for ; Tue, 4 Sep 2012 15:33:30 -0700 (PDT) Received: from mail199-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 22:33:30 +0000 Received: from mail199-co1 (localhost [127.0.0.1]) by mail199-co1-R.bigfish.com (Postfix) with ESMTP id 554913800AB; Tue, 4 Sep 2012 22:33:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zzbb2dI98dI9371Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail199-co1: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail199-co1 (localhost.localdomain [127.0.0.1]) by mail199-co1 (MessageSwitch) id 1346798008102254_30265; Tue, 4 Sep 2012 22:33:28 +0000 (UTC) Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.229]) by mail199-co1.bigfish.com (Postfix) with ESMTP id 11701D8004A; Tue, 4 Sep 2012 22:33:28 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 22:33:25 +0000 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, 4 Sep 2012 18:33:24 -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, 4 Sep 2012 18:33:24 -0400 From: "Cantor, Scott" To: William Mills Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNirNaDj304+GtZUyptIjTd8k0Mpd6md8A///GkwCAAEU2gP//whkAgABHYwD//873AAAI2AyA///buq2AAEgCgIAAAdyA//+/GYCAAFzjAP//vlcA Date: Tue, 4 Sep 2012 22:32:00 +0000 Message-ID: In-Reply-To: <1346797616.19925.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: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <462CF713E2647047A0C953E82C48945F@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 22:33:34 -0000 On 9/4/12 6:26 PM, "William Mills" wrote: >No you're confused. I don't care at all about the actual authz-id. >Forget that part. Ok. >Help me solve the problem of having a plain text copy of the user >identity for the resource being accessed available to the mechanism. Who is supplying that identity? Where does it come from and for what will it be used? It isn't what Ryan was asking for. Not based on what he posted anyway. So I haven't seen any explanation of it that I understand. -- Scott From cantor.2@osu.edu Tue Sep 4 15:34: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 1962C21E80A2 for ; Tue, 4 Sep 2012 15:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.83 X-Spam-Level: X-Spam-Status: No, score=-3.83 tagged_above=-999 required=5 tests=[AWL=-0.231, 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 TzL8tPDJDpsX for ; Tue, 4 Sep 2012 15:34:27 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id C9FD921E805A for ; Tue, 4 Sep 2012 15:34:19 -0700 (PDT) Received: from mail168-co1-R.bigfish.com (10.243.78.234) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 22:34:19 +0000 Received: from mail168-co1 (localhost [127.0.0.1]) by mail168-co1-R.bigfish.com (Postfix) with ESMTP id 7AACB200F1; Tue, 4 Sep 2012 22:34:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zzbb2dI98dI9371Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail168-co1: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail168-co1 (localhost.localdomain [127.0.0.1]) by mail168-co1 (MessageSwitch) id 1346798057218744_8698; Tue, 4 Sep 2012 22:34:17 +0000 (UTC) Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.242]) by mail168-co1.bigfish.com (Postfix) with ESMTP id 254C31C0042; Tue, 4 Sep 2012 22:34:17 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 22:34:15 +0000 Received: from CIO-TNC-HT07.osuad.osu.edu (2002:a46b:51ae::a46b:51ae) by CIO-TNC-HT06.osuad.osu.edu (2002:a46b:51a5::a46b:51a5) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 4 Sep 2012 18:34:14 -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, 4 Sep 2012 18:34:14 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] GSS name type Thread-Index: AQHNiu1p4OVAGSJ03kWzEODrOrqEyQ== Date: Tue, 4 Sep 2012 22:34:14 +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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS name type 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, 04 Sep 2012 22:34:28 -0000 On 9/4/12 6:12 PM, "Nico Williams" wrote: >Well, the canonical method of authorization in RFC2743 is to call >GSS_Export_name() and then do octet string comparisons (length + >memcmp()) or lookups using the exported name tokens... >That's... kinda difficult to use effectively in practice because that >means that GSS dictates ACL form, and because name canonicalization is >a bit of a thing of the past in a world of fine-grained authorization >and of privacy protecting gateways. Right. > And who wants the security >framework to dictate their ACLs? Active Directory and NTFS use ACL >forms dictated by the OS, not by GSS, and that's just one example. >It's hard to imagine an RFC2743-pure world of applications. Ok, so... >[Sure, we could pretend that privacy-protected names are just >anonymous names, but we still need to use the fine-grained authz data >delivered by the mechanism. But this only covers some use cases and >requires naming extensions anyways. Another thing we could do is to >encode all the fine-grained authz data into the display name form, but >that's no good from a usability perspective. And we can't encode >fine-grained authz data in exported name tokens because that would >break any RFC2743-pure apps that exist (some do). The only real >choice we have is to use naming extensions.] Agree, so... >I think we now want to say that sorry, some mechanisms don't support >"canonical names", and/or don't support a canonicalization service >(specifically: GSS_Canonicalize_name()), and/or don't support >GSS_Export_name(). Such mechanisms are only really usable in >conjunction with GSS naming extensions, therefore they must support >those. And that's where I'm at. So thus far, I haven't bothered to include a MN for SAML in my draft. I feel like it's only valuable if I can understand how it will get used. But it wouldn't be rocket science, it's just some canonical XML. -- Scott From wmills@yahoo-inc.com Tue Sep 4 15:40: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 5E5C221E8082 for ; Tue, 4 Sep 2012 15:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 vSkC6wti6nC5 for ; Tue, 4 Sep 2012 15:40:24 -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 SMTP id 9BDE221E805A for ; Tue, 4 Sep 2012 15:40:24 -0700 (PDT) Received: from [98.139.212.152] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 22:40:24 -0000 Received: from [98.139.212.207] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 22:40:24 -0000 Received: from [127.0.0.1] by omp1016.mail.bf1.yahoo.com with NNFMP; 04 Sep 2012 22:40:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 11901.32490.bm@omp1016.mail.bf1.yahoo.com Received: (qmail 96435 invoked by uid 60001); 4 Sep 2012 22:40:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346798423; bh=ff+kDbBhDs/MZMqiK6sFrzYcAezYB5PAUuUUWawrNt4=; 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=Pl5UCEq0v0B3RxKMXg/jlpIP5TSvxXSEwlljv+utE/jId6WbnOANjGv5BmDIRzhWsZ5VQPnR6S8QkhwnxzKW5gO833nal7dgngumzraM5tTsIg7e/BiVVvsJKmJA500unlg+l0nbdKw6Nx1RJiPZORoPtqGj0D92xGes7J5zzYU= 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=hxRflkPFBTFiNUzml1CeuPUNNjusAQtF88U5yGQNKtNXnI6Rh5+1Su2yMDSCno3guSg4Rsykf9lOWW3CQNBzw5WPhLZpOFx8eyJ9TRjZ4dHPp1Cw6Pfna5uhXBWB6rWtJIk6libWh1wtBGZNr3QLXT7h393cratK0KV6eJuSlnM=; X-YMail-OSG: hkxVWYsVM1lAFECTrFZUJgDuU3orzLhUmXqOBzxLF16yaR2 p3ji6zCy6VzINXMIlud5Gg.qje71LADjKhjoThn3NS4wKaw5UubfoKqsHC1a mai01UOm5pBsyqzVm1AUJ7Ck4FWiMQCtbd6.M25EyKLyc6.XmNu82KAl4NgN CHtvXWFPdI16P85wvGkecT6La6_P1LS8P7P6hxyvdYiEhX2slvVcNUmFb1n_ RyldikpZV_pWGuyZF9Dnh2JYWfgYEbka.Zk1BGXvcDzYzKhWkxKnz5uJ50Ot lnXIiqky0r0AvCNo3HKvQbex8jLfGTyiCt7ADn2nF6iALCYgsOQm4A_jLX07 eQ7F0Q2pHkJDHYpKOsgf9jfm8DRy3mCgpcDIovyySKN3swtAnQSoL3whuOdA JOkBsnk4aGHVg1qDAvg0cya2M0bbx2yYE3uiaXsa5SIjqUg_pvnjWW72qf5K UdiEWTQ-- Received: from [209.131.62.115] by web31809.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 15:40:23 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346797616.19925.YahooMailNeo@web31807.mail.mud.yahoo.com> Message-ID: <1346798423.70922.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 15:40:23 -0700 (PDT) From: William Mills To: "Cantor, Scott" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [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: Tue, 04 Sep 2012 22:40:25 -0000 The client will provide that identity, which in IMAP for example will be th= e username fore the mailbox being accessed.=A0 =0A=0A=0A=0A=0A----- Origina= l Message -----=0A> From: "Cantor, Scott" =0A> To: Willia= m Mills =0A> Cc: "kitten@ietf.org" = =0A> Sent: Tuesday, September 4, 2012 3:32 PM=0A> Subject: Re: [kitten] -06= posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth S= ASL draft -05=0A> =0A> On 9/4/12 6:26 PM, "William Mills" wrote:=0A> =0A>> No you're confused.=A0 I don't care at all about the= actual authz-id.=0A>> Forget that part.=0A> =0A> Ok.=0A> =0A>> Help me sol= ve the problem of having a plain text copy of the user=0A>> identity for th= e resource being accessed available to the mechanism.=0A> =0A> Who is suppl= ying that identity? Where does it come from and for what will=0A> it be use= d?=0A> =0A> It isn't what Ryan was asking for. Not based on what he posted = anyway. So=0A> I haven't seen any explanation of it that I understand.=0A> = =0A> -- Scott=0A> From cantor.2@osu.edu Tue Sep 4 15: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 CD26A21E8082 for ; Tue, 4 Sep 2012 15:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.813 X-Spam-Level: X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 55wP0lPMwZIl for ; Tue, 4 Sep 2012 15:46:28 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id EB1FD21E8098 for ; Tue, 4 Sep 2012 15:46:27 -0700 (PDT) Received: from mail10-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 22:46:26 +0000 Received: from mail10-va3 (localhost [127.0.0.1]) by mail10-va3-R.bigfish.com (Postfix) with ESMTP id 10D833600EA; Tue, 4 Sep 2012 22:46:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1418Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail10-va3: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail10-va3 (localhost.localdomain [127.0.0.1]) by mail10-va3 (MessageSwitch) id 1346798784152062_15825; Tue, 4 Sep 2012 22:46:24 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.253]) by mail10-va3.bigfish.com (Postfix) with ESMTP id 211BD48008C; Tue, 4 Sep 2012 22:46:24 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 22:46:23 +0000 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; Tue, 4 Sep 2012 18:46:23 -0400 From: "Cantor, Scott" To: William Mills Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNirNaDj304+GtZUyptIjTd8k0Mpd6md8A///GkwCAAEU2gP//whkAgABHYwD//873AAAI2AyA///buq2AAEgCgIAAAdyA//+/GYCAAFzjAP//vlcAgABFa4D//76bAA== Date: Tue, 4 Sep 2012 22:46:23 +0000 Message-ID: In-Reply-To: <1346798423.70922.YahooMailNeo@web31809.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: <0F532CEF8ACA574E910F22D45BFE8D4E@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 22:46:28 -0000 On 9/4/12 6:40 PM, "William Mills" wrote: >The client will provide that identity, which in IMAP for example will be >the username fore the mailbox being accessed. That doesn't answer the rest of my question. So that's where it comes from, fine. I think that's the SASL authz-id, which is not what you want to hear. But leave that aside; at the point that client enters that, what is that you're trying to do with it and on which end(s)? -- Scott From cantor.2@osu.edu Tue Sep 4 15:52: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 E3B6C21F84F5 for ; Tue, 4 Sep 2012 15:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 rA9-dUnT9FT4 for ; Tue, 4 Sep 2012 15:52:32 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id C990C21F84EA for ; Tue, 4 Sep 2012 15:52:31 -0700 (PDT) Received: from mail37-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE009.bigfish.com (10.243.66.72) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 22:52:31 +0000 Received: from mail37-co1 (localhost [127.0.0.1]) by mail37-co1-R.bigfish.com (Postfix) with ESMTP id 3C32AB0011E; Tue, 4 Sep 2012 22:52:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.168; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT05.osuad.osu.edu; RD:cio-tnc-ht05.osuad.osu.edu; EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zzbb2dI98dI9371Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail37-co1: domain of osu.edu designates 164.107.81.168 as permitted sender) client-ip=164.107.81.168; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT05.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail37-co1 (localhost.localdomain [127.0.0.1]) by mail37-co1 (MessageSwitch) id 1346799148227424_7087; Tue, 4 Sep 2012 22:52:28 +0000 (UTC) Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.245]) by mail37-co1.bigfish.com (Postfix) with ESMTP id 2C2F86A0047; Tue, 4 Sep 2012 22:52:28 +0000 (UTC) Received: from CIO-TNC-HT05.osuad.osu.edu (164.107.81.168) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 22:52:28 +0000 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, 4 Sep 2012 18:52:23 -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; Tue, 4 Sep 2012 22:52:22 +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; Tue, 4 Sep 2012 18:34:14 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] GSS name type Thread-Index: AQHNiu1p4OVAGSJ03kWzEODrOrqEyQ== Date: Tue, 4 Sep 2012 22:34:14 +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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS name type 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, 04 Sep 2012 22:52:38 -0000 On 9/4/12 6:12 PM, "Nico Williams" wrote: >Well, the canonical method of authorization in RFC2743 is to call >GSS_Export_name() and then do octet string comparisons (length + >memcmp()) or lookups using the exported name tokens... >That's... kinda difficult to use effectively in practice because that >means that GSS dictates ACL form, and because name canonicalization is >a bit of a thing of the past in a world of fine-grained authorization >and of privacy protecting gateways. Right. > And who wants the security >framework to dictate their ACLs? Active Directory and NTFS use ACL >forms dictated by the OS, not by GSS, and that's just one example. >It's hard to imagine an RFC2743-pure world of applications. Ok, so... >[Sure, we could pretend that privacy-protected names are just >anonymous names, but we still need to use the fine-grained authz data >delivered by the mechanism. But this only covers some use cases and >requires naming extensions anyways. Another thing we could do is to >encode all the fine-grained authz data into the display name form, but >that's no good from a usability perspective. And we can't encode >fine-grained authz data in exported name tokens because that would >break any RFC2743-pure apps that exist (some do). The only real >choice we have is to use naming extensions.] Agree, so... >I think we now want to say that sorry, some mechanisms don't support >"canonical names", and/or don't support a canonicalization service >(specifically: GSS_Canonicalize_name()), and/or don't support >GSS_Export_name(). Such mechanisms are only really usable in >conjunction with GSS naming extensions, therefore they must support >those. And that's where I'm at. So thus far, I haven't bothered to include a MN for SAML in my draft. I feel like it's only valuable if I can understand how it will get used. But it wouldn't be rocket science, it's just some canonical XML. -- Scott From rra@stanford.edu Tue Sep 4 15: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 DECF721F854F for ; Tue, 4 Sep 2012 15:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 TvPZ+VSsNZj8 for ; Tue, 4 Sep 2012 15:53:12 -0700 (PDT) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id 542A221F854C for ; Tue, 4 Sep 2012 15:53:12 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 37BC7628EA1 for ; Tue, 4 Sep 2012 15:53:12 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id EDB34629116 for ; Tue, 4 Sep 2012 15:53:11 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id C484D2F4E8; Tue, 4 Sep 2012 15:53:11 -0700 (PDT) From: Russ Allbery To: "kitten\@ietf.org" In-Reply-To: <1346798423.70922.YahooMailNeo@web31809.mail.mud.yahoo.com> (William Mills's message of "Tue, 4 Sep 2012 15:40:23 -0700 (PDT)") Organization: The Eyrie References: <1346797616.19925.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346798423.70922.YahooMailNeo@web31809.mail.mud.yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Tue, 04 Sep 2012 15:53:11 -0700 Message-ID: <871uihtn6w.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 22:53:13 -0000 William Mills writes: > The client will provide that identity, which in IMAP for example will be > the username fore the mailbox being accessed.=C2=A0 In IMAP, the username for the mailbox being accessed is exactly the SASL authz-id, which you're not allowed to touch as part of a SASL mechanism. It's up to the IMAP server, outside of SASL, to decide whether a given authenticated identity is permitted to assert that authz-id. I suspect that one of the things that's making this complex is that SASL is designed to be purely an authentication protocol. It conveys authentication information (plus a client-provided authz-id that it only passes through but doesn't validate), and leaves all authorization to the application. OAuth, on the other hand, *isn't* purely an authentication framework; it also has an authorization component. You're going to have some real difficulty trying to wedge the authorization bit into SASL, since SASL by design tries to stay completely out of the authorization business. --=20 Russ Allbery (rra@stanford.edu) From wmills@yahoo-inc.com Tue Sep 4 16:14: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 7625721E8082 for ; Tue, 4 Sep 2012 16:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ppKg0s+FkKWM for ; Tue, 4 Sep 2012 16:14:51 -0700 (PDT) Received: from nm29-vm0.bullet.mail.sp2.yahoo.com (nm29-vm0.bullet.mail.sp2.yahoo.com [98.139.91.236]) by ietfa.amsl.com (Postfix) with SMTP id AF1D021E805A for ; Tue, 4 Sep 2012 16:14:51 -0700 (PDT) Received: from [72.30.22.78] by nm29.bullet.mail.sp2.yahoo.com with NNFMP; 04 Sep 2012 23:14:46 -0000 Received: from [98.139.91.37] by tm12.bullet.mail.sp2.yahoo.com with NNFMP; 04 Sep 2012 23:14:46 -0000 Received: from [127.0.0.1] by omp1037.mail.sp2.yahoo.com with NNFMP; 04 Sep 2012 23:14:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 752182.94714.bm@omp1037.mail.sp2.yahoo.com Received: (qmail 72393 invoked by uid 60001); 4 Sep 2012 23:14:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346800486; bh=WJL94ZExahLhQgJTu2Ivdm7qUUShzS6civ6fj2BqeSY=; 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=Mr6y1GKCbtBOt22GlSjw3H/e75zw7jV7LGLFPtdzPMWmrSj4mnLMTAOanlqNhnpe2MUCAt+87paLISG2b/lOHa6AIZ7SD24GbPWwgSAvJkGM4JqVtiD/3sQn9TM0MKg1/B9ptUkTYPWLaWwzLHYvzfwL9XrqUPKTruazl10+fk0= 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=TWtx8HOoWNZ08bUBDjwfw0XBv8/eurDKJ0gHNBi5ktlbn8X/zkUQGnA2WWXZGuvRNNZQEt3bltDJnFhL8rr64Fzk9dQPXq+YZ8V8bJ9qCM1wRb/+nBKVYUorhJTex4av7SVcQa+AS+2k1OMzd+f/5J9G/fgtfidRj+FV8kY2L1s=; X-YMail-OSG: P3i.KsUVM1nXtkaz07OMYcbBEaOkeCE3ARbLxfzSXb9R9cD lAbOXw4ePdyMi0BMG5ElKgyddkcpqCOKB5mR8UPyg_4fHAL1P8IPCmAfuJzZ d2pNSn07ncBudvX5L1_ZpT.5wp7I6uqDylAEFi0M5EjClKZOCoX5IE3F02X0 MH1KzQZ0yCvjpOt_tGHuYtOQ8.3hapwXNKxCAjvnA83sCXCPF6cCf0P6rc20 shK2akGTGCSMADkHioFdZZU4rU6OTkuUWGOZlt.GxvKIvs5istHy8XM_JyOh qx32kHQsC6p_l8UOwLwBoPD8k6gUhx.oD9LV3kdMXbjR.ARL0mPP8rKPt9H9 U2BqTHHDEtW110X_45ilHAnZLLp89yVtevlVrOo4WBOwdELl2Iznie28oOlB SXHR8cipC6tzroPX66oqEl40oqDIlJYzwaEyo5cHdRQD9FXGu.LpiJ7qdifQ 3B19L.Kmc2XrEYgs_LRfo4TvIbNkuTIEUl.gVbcMq3RjomiRSuRa3MQNRifB wMrIV89vtN.il8Zc- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 16:14:46 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346797616.19925.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346798423.70922.YahooMailNeo@web31809.mail.mud.yahoo.com> <871uihtn6w.fsf@windlord.stanford.edu> Message-ID: <1346800486.70436.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 16:14:46 -0700 (PDT) From: William Mills To: Russ Allbery , "kitten@ietf.org" In-Reply-To: <871uihtn6w.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [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: Tue, 04 Sep 2012 23:14:52 -0000 OK, so authz-id is in fact the piece of data I need but the mechanism can't= use it?=A0 =0A=0ASay I've got a bad guy hitting my server and in authz-id = he sends good@example.com, but the credential he sends is for evil@exampl.c= om.=A0 Does the SASL mechanism succeed and then the application has to comp= are the two values?=0A=0A=0A=0A=0A----- Original Message -----=0A> From: Ru= ss Allbery =0A> To: "kitten@ietf.org" = =0A> Cc: =0A> Sent: Tuesday, September 4, 2012 3:53 PM=0A> Subject: Re: [ki= tten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re= : OAuth SASL draft -05=0A> =0A> William Mills writes= :=0A> =0A>> The client will provide that identity, which in IMAP for examp= le will be=0A>> the username fore the mailbox being accessed.=A0=0A> =0A> = In IMAP, the username for the mailbox being accessed is exactly the SASL=0A= > authz-id, which you're not allowed to touch as part of a SASL mechanism.= =0A> It's up to the IMAP server, outside of SASL, to decide whether a given= =0A> authenticated identity is permitted to assert that authz-id.=0A> =0A> = I suspect that one of the things that's making this complex is that SASL=0A= > is designed to be purely an authentication protocol.=A0 It conveys=0A> au= thentication information (plus a client-provided authz-id that it only=0A> = passes through but doesn't validate), and leaves all authorization to the= =0A> application.=A0 OAuth, on the other hand, *isn't* purely an authentica= tion=0A> framework; it also has an authorization component.=0A> =0A> You're= going to have some real difficulty trying to wedge the=0A> authorization b= it into SASL, since SASL by design tries to stay completely=0A> out of the = authorization business.=0A> =0A> -- =0A> Russ Allbery (rra@stanford.edu)=A0= =A0 =A0 =A0 =A0 =A0 =0A> __________________= _____________________________=0A> Kitten mailing list=0A> Kitten@ietf.org= =0A> https://www.ietf.org/mailman/listinfo/kitten=0A> From rra@stanford.edu Tue Sep 4 16:17: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 2E28621E8082 for ; Tue, 4 Sep 2012 16:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 zsb+1+gYZxwb for ; Tue, 4 Sep 2012 16:17:28 -0700 (PDT) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2A921E805A for ; Tue, 4 Sep 2012 16:17:28 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 77A3662921E for ; Tue, 4 Sep 2012 16:17:28 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 3E13A62921C for ; Tue, 4 Sep 2012 16:17:28 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 29D7E2F4E8; Tue, 4 Sep 2012 16:17:27 -0700 (PDT) From: Russ Allbery To: "kitten\@ietf.org" In-Reply-To: <1346800486.70436.YahooMailNeo@web31816.mail.mud.yahoo.com> (William Mills's message of "Tue, 4 Sep 2012 16:14:46 -0700 (PDT)") Organization: The Eyrie References: <1346797616.19925.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346798423.70922.YahooMailNeo@web31809.mail.mud.yahoo.com> <871uihtn6w.fsf@windlord.stanford.edu> <1346800486.70436.YahooMailNeo@web31816.mail.mud.yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Tue, 04 Sep 2012 16:17:27 -0700 Message-ID: <87ipbts7i0.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 23:17:30 -0000 William Mills writes: > OK, so authz-id is in fact the piece of data I need but the mechanism > can't use it?=C2=A0 > Say I've got a bad guy hitting my server and in authz-id he sends > good@example.com, but the credential he sends is for evil@exampl.com.=C2= =A0 > Does the SASL mechanism succeed and then the application has to compare > the two values? Correct. He has successfully authenticated as evil@example.com, at which point SASL's role in the protocol is complete. SASL communicates both that identity and the requested authz-id to the application and exits the picture. The decision beyond that point is an authorization decision, which SASL leaves to the application. --=20 Russ Allbery (rra@stanford.edu) From nico@cryptonector.com Tue Sep 4 16:20: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 9CB9121E8082 for ; Tue, 4 Sep 2012 16:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 9EvWvG29sM8K for ; Tue, 4 Sep 2012 16:20:44 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 329F921E805A for ; Tue, 4 Sep 2012 16:20:43 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id ED54321DE58 for ; Tue, 4 Sep 2012 16:20: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; s=cryptonector.com; bh=n0xhdvyAssZFDi7Ii8vz HCOcykU=; b=d7PQZjRhQ414pDffqrXjwWyCAXuQOfOGrULw46a5ol39sIz0VF8j e3MByn99Cuo3zI5e/nCUdJXyXlgY2yKE1p/ACowZutMssr92LdIVXfCjdhic7S9t 5kGXXN98QEGt/NsiUGo4P9SUn78/9yYUIMabJUGam8KtVE6VmvUeEDE= 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-a30.g.dreamhost.com (Postfix) with ESMTPSA id CB10221DE55 for ; Tue, 4 Sep 2012 16:20:42 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so9871935pbb.31 for ; Tue, 04 Sep 2012 16:20:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.211.105 with SMTP id nb9mr50053516pbc.67.1346800842393; Tue, 04 Sep 2012 16:20:42 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 16:20:42 -0700 (PDT) In-Reply-To: <1346800486.70436.YahooMailNeo@web31816.mail.mud.yahoo.com> References: <1346797616.19925.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346798423.70922.YahooMailNeo@web31809.mail.mud.yahoo.com> <871uihtn6w.fsf@windlord.stanford.edu> <1346800486.70436.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 18:20:42 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 23:20:45 -0000 On Tue, Sep 4, 2012 at 6:14 PM, William Mills wrote: > OK, so authz-id is in fact the piece of data I need but the mechanism can't use it? Yes and yes. > Say I've got a bad guy hitting my server and in authz-id he sends good@example.com, but the credential he sends is for evil@exampl.com. Does the SASL mechanism succeed and then the application has to compare the two values? The application performs an authorization check, yes. Who knows, maybe good and evil go together and evil has access to good's mailbox intentionally. The key is that the mechanism transports the authz-id *with* integrity protection. (Confidentiality protection might be nice, but GS2 doesn't provide that, sorry.) Then the application decides if the authcid gets access to the requested authz-id. Nico -- From cantor.2@osu.edu Tue Sep 4 17:11: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 467E621E8053 for ; Tue, 4 Sep 2012 17:11:36 -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=[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 zK1DrRKzVMQs for ; Tue, 4 Sep 2012 17:11:29 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id BF0C721E804E for ; Tue, 4 Sep 2012 17:11:29 -0700 (PDT) Received: from mail165-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Sep 2012 00:11:29 +0000 Received: from mail165-co1 (localhost [127.0.0.1]) by mail165-co1-R.bigfish.com (Postfix) with ESMTP id 3463A980111; Wed, 5 Sep 2012 00:11:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail165-co1: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail165-co1 (localhost.localdomain [127.0.0.1]) by mail165-co1 (MessageSwitch) id 1346803886564624_30108; Wed, 5 Sep 2012 00:11:26 +0000 (UTC) Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.239]) by mail165-co1.bigfish.com (Postfix) with ESMTP id 8689B380042; Wed, 5 Sep 2012 00:11:26 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Sep 2012 00:11:26 +0000 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, 4 Sep 2012 20:11:24 -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, 4 Sep 2012 20:11:24 -0400 From: "Cantor, Scott" To: Nico Williams , William Mills Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNivPrp8848xvAw027B7SlrgYYc5d64AsA Date: Wed, 5 Sep 2012 00:11:24 +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: <27FF5CA2A6870347A897370FF9FCDD2D@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 00:11:36 -0000 On 9/4/12 7:20 PM, "Nico Williams" wrote: > >The key is that the mechanism transports the authz-id *with* integrity >protection. I believe that's only in the case where channel binding is possible. Otherwise, it's left to TLS to protect it all and you punt. I note that since the vastly more common OAuth case will be bearer tokens and no CB. -- Scott From cantor.2@osu.edu Tue Sep 4 17:13: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 9583F21E8095 for ; Tue, 4 Sep 2012 17:13:51 -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=[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 ipag-c0ZoQX1 for ; Tue, 4 Sep 2012 17:13:51 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 1636821E809F for ; Tue, 4 Sep 2012 17:13:51 -0700 (PDT) Received: from mail97-co1-R.bigfish.com (10.243.78.247) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Sep 2012 00:13:50 +0000 Received: from mail97-co1 (localhost [127.0.0.1]) by mail97-co1-R.bigfish.com (Postfix) with ESMTP id C822C4800E3; Wed, 5 Sep 2012 00:13:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail97-co1: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail97-co1 (localhost.localdomain [127.0.0.1]) by mail97-co1 (MessageSwitch) id 1346804028850029_32740; Wed, 5 Sep 2012 00:13:48 +0000 (UTC) Received: from CO1EHSMHS011.bigfish.com (unknown [10.243.78.231]) by mail97-co1.bigfish.com (Postfix) with ESMTP id CC68E58004F; Wed, 5 Sep 2012 00:13:48 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by CO1EHSMHS011.bigfish.com (10.243.66.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Sep 2012 00:13:48 +0000 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; Tue, 4 Sep 2012 20:13:43 -0400 From: "Cantor, Scott" To: William Mills , "kitten@ietf.org" Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNivtOmKimty3gzEq9XsZDrm3dGw== Date: Wed, 5 Sep 2012 00:13:42 +0000 Message-ID: In-Reply-To: <1346800486.70436.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: <6268F45EDD619E4BBEB85A87DB8FA562@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 00:13:51 -0000 On 9/4/12 7:14 PM, "William Mills" wrote: >OK, so authz-id is in fact the piece of data I need but the mechanism >can't use it? =20 > >Say I've got a bad guy hitting my server and in authz-id he sends >good@example.com, but the credential he sends is for evil@exampl.com. >Does the SASL mechanism succeed and then the application has to compare >the two values? If you read some of the other messages in the thread that I forked off, you'll see the userok function notion mentioned. There are some APIs that hook into a mechanism and pass in a proposed userid (in your example, good@) and then the implementation can say "I'm going to validate the claimed ID against my OAuth token's contents" if you want it to. That's all fine, it's just not something on the wire in the mechanism or mandated. -- Scott From wmills@yahoo-inc.com Tue Sep 4 17:14: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 27E5221E8053 for ; Tue, 4 Sep 2012 17:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 i1pVX8iCBlEt for ; Tue, 4 Sep 2012 17:14:35 -0700 (PDT) Received: from nm32-vm3.bullet.mail.bf1.yahoo.com (nm32-vm3.bullet.mail.bf1.yahoo.com [72.30.239.139]) by ietfa.amsl.com (Postfix) with SMTP id 0662E21E809F for ; Tue, 4 Sep 2012 17:14:34 -0700 (PDT) Received: from [98.139.212.150] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 05 Sep 2012 00:14:34 -0000 Received: from [98.139.212.197] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 05 Sep 2012 00:14:34 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 05 Sep 2012 00:14:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 346515.14816.bm@omp1006.mail.bf1.yahoo.com Received: (qmail 6715 invoked by uid 60001); 5 Sep 2012 00:14:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346804073; bh=R2rSC1T4IUzjlzmqXTLVIGzzGX9WUkeGTG4ibAUldNw=; 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=ATvEd+rTHcNZ85u0RSJEY/SAOKXfEHFLFal1Pd7lXEP545c1k/RC8rR1bQWqMucC7NtLfNuPLhKeJYn42iKHvb689HsdT98roAt0fDNTz7z93lZYJYz103gMpcJUUqJU3oAz5cUG+1rVq54DF1rXPu8VrrBfOKATGXuHWutRZNk= 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=WEInw9BjmJxn5L5JGQHsoWNlYckR+xRzab0MC59lp8CnvRqdK9ZDScKZ2pXDHr6x9pmtsxSWjFnEKLas7Gbay22UfhoaeEdWkJhZVnx/H4EezRzBEIwzwivqoH9fIq5oxtJ4SVKapL8zBv4PXMERJL5Q6HyhQ+9LaZAf0u5WAoI=; X-YMail-OSG: dErveNgVM1ktXQ2Ik9.rC8yyQEu5Rp6_zPMi.ES2VJaNFCH snw9luxQ1pSlhLccK0ru1SdU7h7PX7euaoJH2oRgVxA85JOypmHwRzbHlznK .rBq1N.mIS.gfhgI83JlBES4ZpdZ8AU4kclvNOGjTfc4puvjTgPUZxMzc3aD mI_zlaymy_NWv.J8QukIK09hViFdy95aWHjd5Koyn.Cfb8YDkOTEsK3OYkWu qa0ZxAP_QRmkzGVd2SiFQFUJKW391gu38YAYOeFabavc9iyQMLFRxL5YlPr6 NP_MxdyKh_DjNHQiGjvNoCWZSoYLHeGoeDtX66lNbBUO..VIquwmAOEeWPDP 0RShX4Z7BzhXC036IARFEPauu3FYGc2mlcaIam.z2ZgDl1JzOJudZN3ufBf. HEvLOiRHDYoez0PX.ptfwjk9QqQxZWJFYKD4f_r_4656TrAOCa_rWUVwqYtD g71X7KgT5fzXg86dKEMTukYF5hDQUEUHgdjpp5gZ.1lgqMRtgkvGwZkMlCcD dytdkPQGfUBf7p6E- Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 17:14:33 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346797616.19925.YahooMailNeo@web31807.mail.mud.yahoo.com> <1346798423.70922.YahooMailNeo@web31809.mail.mud.yahoo.com> <871uihtn6w.fsf@windlord.stanford.edu> <1346800486.70436.YahooMailNeo@web31816.mail.mud.yahoo.com> <87ipbts7i0.fsf@windlord.stanford.edu> Message-ID: <1346804073.6654.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 17:14:33 -0700 (PDT) From: William Mills To: Russ Allbery , "kitten@ietf.org" In-Reply-To: <87ipbts7i0.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [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: Wed, 05 Sep 2012 00:14:36 -0000 OK, so based on this is this:=0A=0A=A0=A0=A0 Some OAuth schemes can carry b= oth a user identity and a "proxy" identity,=0A=A0=A0=A0 for example an OAut= h 1.0a mechanism where the =0A=0A=A0=A0=A0 consum= er key (oauth_consumer_key) identifies the entityusing the token =0A=0A=A0= =A0=A0 and the token itself identifies the user. If both identitiesare nee= ded =0A=0A=A0=A0=A0 by an application the developer will need to provide a = way to communicate =0A=0A=A0=A0=A0 that from the SASL mechanism back to the= application.=0Asafe to say?=0A=0AThanks,=0A=0A-bill=0A=0A=0A=0A=0A----- Or= iginal Message -----=0A> From: Russ Allbery =0A> To: "kit= ten@ietf.org" =0A> Cc: =0A> Sent: Tuesday, September 4, 20= 12 4:17 PM=0A> Subject: Re: [kitten] -06 posted Re: requirements/context/fr= ustration Re: Comma vs. %x01 Re: OAuth SASL draft -05=0A> =0A> William Mill= s writes:=0A> =0A>> OK, so authz-id is in fact the = piece of data I need but the mechanism=0A>> can't use it?=A0=0A> =0A>> Sa= y I've got a bad guy hitting my server and in authz-id he sends=0A>> good@= example.com, but the credential he sends is for evil@exampl.com.=A0=0A>> D= oes the SASL mechanism succeed and then the application has to compare=0A>>= the two values?=0A> =0A> Correct.=A0 He has successfully authenticated as= evil@example.com, at which=0A> point SASL's role in the protocol is comple= te.=A0 SASL communicates both=0A> that identity and the requested authz-id = to the application and exits the=0A> picture.=A0 The decision beyond that p= oint is an authorization decision,=0A> which SASL leaves to the application= .=0A> =0A> -- =0A> Russ Allbery (rra@stanford.edu)=A0 =A0 =A0 =A0 =A0 =A0 = =0A> ________________________________________= _______=0A> Kitten mailing list=0A> Kitten@ietf.org=0A> https://www.ietf.or= g/mailman/listinfo/kitten=0A> From lukeh@padl.com Tue Sep 4 17:17: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 86D1A21E8053 for ; Tue, 4 Sep 2012 17:17:52 -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 yX2y88MMn6OY for ; Tue, 4 Sep 2012 17:17:52 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id E578D21F84D6 for ; Tue, 4 Sep 2012 17:17:51 -0700 (PDT) Received: by us.padl.com with ESMTP id q850HjWR013728; Tue, 4 Sep 2012 20:17:47 -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, 5 Sep 2012 10:17:42 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <145D0113-859E-490A-86AF-111F72A6C74B@padl.com> References: To: "Cantor, Scott" 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.4 Cc: "kitten@ietf.org" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 00:17:52 -0000 On 05/09/2012, at 10:11 AM, "Cantor, Scott" wrote: > On 9/4/12 7:20 PM, "Nico Williams" wrote: >>=20 >> The key is that the mechanism transports the authz-id *with* = integrity >> protection. >=20 > I believe that's only in the case where channel binding is possible. > Otherwise, it's left to TLS to protect it all and you punt. Well, GS1 (RFC 2222) integrity protected it with GSS_Wrap(). But that's = a historical footnote now. -- Luke= From cantor.2@osu.edu Tue Sep 4 17:21: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 781C121F84DA for ; Tue, 4 Sep 2012 17:21:30 -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=[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 Ru91gcs1MAP1 for ; Tue, 4 Sep 2012 17:21:30 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id D488721F84D8 for ; Tue, 4 Sep 2012 17:21:29 -0700 (PDT) Received: from mail33-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Sep 2012 00:21:29 +0000 Received: from mail33-ch1 (localhost [127.0.0.1]) by mail33-ch1-R.bigfish.com (Postfix) with ESMTP id 39F64C00DF; Wed, 5 Sep 2012 00:21:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.40; KIP:(null); UIP:(null); IPV:NLI; H:CIO-KRC-HT02.osuad.osu.edu; RD:cio-krc-ht02.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail33-ch1: domain of osu.edu designates 164.107.81.40 as permitted sender) client-ip=164.107.81.40; envelope-from=cantor.2@osu.edu; helo=CIO-KRC-HT02.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail33-ch1 (localhost.localdomain [127.0.0.1]) by mail33-ch1 (MessageSwitch) id 134680448746628_27953; Wed, 5 Sep 2012 00:21:27 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail33-ch1.bigfish.com (Postfix) with ESMTP id 09E611C004A; Wed, 5 Sep 2012 00:21:27 +0000 (UTC) Received: from CIO-KRC-HT02.osuad.osu.edu (164.107.81.40) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Sep 2012 00:21:25 +0000 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; Tue, 4 Sep 2012 20:21:25 -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, 4 Sep 2012 20:21:24 -0400 From: "Cantor, Scott" To: William Mills , "kitten@ietf.org" Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNivxhZ1NOEL+hvkCxa7oYN7r9pA== Date: Wed, 5 Sep 2012 00:21:24 +0000 Message-ID: In-Reply-To: <1346804073.6654.YahooMailNeo@web31810.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: <97EECD3465F7964BA89D8A8DF76A13C6@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 00:21:30 -0000 On 9/4/12 8:14 PM, "William Mills" wrote: >OK, so based on this is this: > > Some OAuth schemes can carry both a user identity and a "proxy" >identity, > for example an OAuth 1.0a mechanism where th= e > consumer key (oauth_consumer_key) identifies the entityusing the token > and the token itself identifies the user. If both identitiesare >needed > by an application the developer will need to provide a way to >communicate > that from the SASL mechanism back to the application. >safe to say? It depends what level of interop you're looking for, I guess. Nico was trying to say that if you wanted to nail that down, you could do that by specifying an encoding of the two in the single value communicated back. Nobody's saying that's wrong, only that conflating it with some kind of verification of the authz-id is wrong. You could do this by specifying a GSS name-type specific to this mechanism that encoded the two bits of data in some way. What I can't really say is how that impacts SASL apps in particular, but others should be able to address that question. -- Scott From wmills@yahoo-inc.com Tue Sep 4 17:26: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 2C66721E8054 for ; Tue, 4 Sep 2012 17:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 lRpTb55Dmjsi for ; Tue, 4 Sep 2012 17:26:20 -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 4B53921F853F for ; Tue, 4 Sep 2012 17:26:20 -0700 (PDT) Received: from [98.139.212.144] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 05 Sep 2012 00:26:19 -0000 Received: from [98.139.212.230] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 05 Sep 2012 00:26:19 -0000 Received: from [127.0.0.1] by omp1039.mail.bf1.yahoo.com with NNFMP; 05 Sep 2012 00:26:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 652166.95114.bm@omp1039.mail.bf1.yahoo.com Received: (qmail 71941 invoked by uid 60001); 5 Sep 2012 00:26:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346804779; bh=r6yEbV9kfORnFNrKim5aC2Nn27H+uwgjDHUJejr5cXQ=; 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=qSmfgt/niurunx6GaASPBN2fy+Cp6ZfbUHCAySyV6ktROlxoE8f7mRFydnT5T8q3Dsf80JdR5jSCRZC8pO6Nlsoxp8aWA4VJNUMLjMEnh3+WHPG+Fya7NXSL0Yovj52WVpv6xY56jm7o41lZ31dajU60N5yvLjkDs4QYbzBCUKQ= 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=NrN5hzGRzJPHH0YVWEuwODpvifZuCyGTzLv07JJZApKNcbwQZZLr5tb1ieMnvSPVsAAoBIP0eutmx8cPVMwPbRdMZ1VgAjLwca4URkcP9ml2YVlmvS3U9dKHA5XKXp/oqwMdiCsmU1GsMyNanAph547Skt8O38r8YXG5O/2HYBs=; X-YMail-OSG: 5nWFsBQVM1nfhw7JsLOY8qrP1wXVQCFikNB1qxT9j6H8SFb MfVTVABGkx2jcwLSM5YWIR8GA2s0.fa_x0FDNCZAChU6IoFajlEzJOHOmxd. rq2rrFsuGUAYYpKd58kYMBQqypJRwAFHFBuQC3iffERcJKqdtc6xeM9nLHGL wmeHSWBdQNSIGcd0ODfWOGMJG5PULRbRvG7edV0FcAyrggk8PE4TKVzcET7q 6u46IHnWz_MdG0B5n4xh5VlkN0hQwHV2TGgSc7TRiMhX7ZhWnbAiuaohcUAX s4vZ0UsaquCvJP3_iloEXUqWymjB8xY.psMMJ618Ex8R0WnHCn54eEiHd0or 15pbAEhsDNGwguUv.gMDmgSBXbTtyeU6rSJaudPAOwT2caQimBfKrmfjlaSL SN1ZOdZ4JlT6XYwnNfPscIJB.9j8.zdURo0prmNUMiuL9IYyHPONAkzkYHp5 eX0HPLg-- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 17:26:19 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346804073.6654.YahooMailNeo@web31810.mail.mud.yahoo.com> Message-ID: <1346804779.57122.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 17:26:19 -0700 (PDT) From: William Mills To: "Cantor, Scott" , "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] -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: Wed, 05 Sep 2012 00:26:21 -0000 =0A> It depends what level of interop you're looking for, I guess. Nico was= =0A> trying to say that if you wanted to nail that down, you could do that = by=0A> specifying an encoding of the two in the single value communicated b= ack.=0A=0AYeah, that's probably the way it works.=A0 But now that I think I= 've grokked this=0AI was gonna leave it up to the mech developer and applic= ation to decide.=A0 Just=0Anoting that it might need to be communicated.=A0= I can get more specific but I can=0Asee custom implementations doing somet= hing different.=0A=0A=0A-bill=0A=0A=0A=0A=0A----- Original Message -----=0A= > From: "Cantor, Scott" =0A> To: William Mills ; "kitten@ietf.org" =0A> Cc: =0A> Sent: Tuesda= y, September 4, 2012 5:21 PM=0A> Subject: Re: [kitten] -06 posted Re: requi= rements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05=0A>= =0A> On 9/4/12 8:14 PM, "William Mills" wrote:=0A> = =0A>> OK, so based on this is this:=0A>> =0A>> =A0 =A0 Some OAuth schemes c= an carry both a user identity and a =0A> "proxy"=0A>> identity,=0A>> =A0 = =A0 for example an OAuth 1.0a target=3D"RFC5849"/>mechanism wher= e the=0A>> =A0 =A0 consumer key (oauth_consumer_key) identifies the entityu= sing the token=0A>> =A0 =A0 and the token itself identifies the user.=A0 If= both identitiesare=0A>> needed=0A>> =A0 =A0 by an application the develope= r will need to provide a way to=0A>> communicate=0A>> =A0 =A0 that from the= SASL mechanism back to the application.=0A>> safe to say?=0A> =0A> It depe= nds what level of interop you're looking for, I guess. Nico was=0A> trying = to say that if you wanted to nail that down, you could do that by=0A> speci= fying an encoding of the two in the single value communicated back.=0A> =0A= > Nobody's saying that's wrong, only that conflating it with some kind of= =0A> verification of the authz-id is wrong.=0A> =0A> You could do this by s= pecifying a GSS name-type specific to this mechanism=0A> that encoded the t= wo bits of data in some way. What I can't really say is=0A> how that impact= s SASL apps in particular, but others should be able to=0A> address that qu= estion.=0A> =0A> -- Scott=0A> From cantor.2@osu.edu Tue Sep 4 17:30: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 BBB8621E8096 for ; Tue, 4 Sep 2012 17:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 nZfUNbH4pM8E for ; Tue, 4 Sep 2012 17:30:02 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDDD21E8054 for ; Tue, 4 Sep 2012 17:30:02 -0700 (PDT) Received: from mail28-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Sep 2012 00:30:01 +0000 Received: from mail28-tx2 (localhost [127.0.0.1]) by mail28-tx2-R.bigfish.com (Postfix) with ESMTP id 7FF9D2E011C; Wed, 5 Sep 2012 00:30:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail28-tx2: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail28-tx2 (localhost.localdomain [127.0.0.1]) by mail28-tx2 (MessageSwitch) id 1346804999264930_1180; Wed, 5 Sep 2012 00:29:59 +0000 (UTC) Received: from TX2EHSMHS008.bigfish.com (unknown [10.9.14.250]) by mail28-tx2.bigfish.com (Postfix) with ESMTP id 3C54012004B; Wed, 5 Sep 2012 00:29:59 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by TX2EHSMHS008.bigfish.com (10.9.99.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Sep 2012 00:29:57 +0000 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; Tue, 4 Sep 2012 20:29:53 -0400 From: "Cantor, Scott" To: William Mills , "kitten@ietf.org" Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNivxhZ1NOEL+hvkCxa7oYN7r9pJd7JziA//+97IA= Date: Wed, 5 Sep 2012 00:29:53 +0000 Message-ID: In-Reply-To: <1346804779.57122.YahooMailNeo@web31808.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: <713B4A7943EB4B458B355EE27B9E7DBA@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 00:30:03 -0000 On 9/4/12 8:26 PM, "William Mills" wrote: > >Yeah, that's probably the way it works. But now that I think I've >grokked this >I was gonna leave it up to the mech developer and application to decide. >Just >noting that it might need to be communicated. I can get more specific >but I can >see custom implementations doing something different. The problem, I think, is that you generally want the app layer independent of the mechanism implementation, so getting them to behave in custom ways isn't really the goal. Obviously if you just package it up for one mechanism to run inside a custom app, it doesn't matter. My opinion, as I have said, is that in practice the delegation would be evaluated with the mechanism and not exposed, or that it would be done via hooks that call into the mechanism explicitly with the authz-id and then it gets to do its own custom eval of both the identities in the token. Either way, I don't think both need to be exposed to the application to do useful things with them. -- Scott From wmills@yahoo-inc.com Tue Sep 4 17:34: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 0543921E8054 for ; Tue, 4 Sep 2012 17:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 sLtFaU-egc4r for ; Tue, 4 Sep 2012 17:34:36 -0700 (PDT) Received: from nm28-vm1.bullet.mail.ne1.yahoo.com (nm28-vm1.bullet.mail.ne1.yahoo.com [98.138.91.35]) by ietfa.amsl.com (Postfix) with SMTP id 2053F21E8053 for ; Tue, 4 Sep 2012 17:34:36 -0700 (PDT) Received: from [98.138.90.55] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 05 Sep 2012 00:34:33 -0000 Received: from [98.138.88.235] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 05 Sep 2012 00:34:33 -0000 Received: from [127.0.0.1] by omp1035.mail.ne1.yahoo.com with NNFMP; 05 Sep 2012 00:34:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 121849.15103.bm@omp1035.mail.ne1.yahoo.com Received: (qmail 64350 invoked by uid 60001); 5 Sep 2012 00:34:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346805272; bh=z76shxMhHWPDe8kk0c0ZeWhjd5hLYW0qMI4BieeBuW8=; 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=hXAN9l+LQScxbBLetGIIngDPa5nnHUOm5hTWUKE13bqNnQOVbEZQpzj/i/L3/NDSZTcx7SwJfiazuavhKUjLwari3hlZ88j9vT8gemlohqHQO0lPXEM0cEhWF6pz9w1MFmv8rm/jy9pAgv7OYdW6VfBNnaqsmsS474Jm+Fl3mC8= 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=ozEgtu/tQQfdc2UP7hD5zPvciYd21+o3lx0QlM1PiQP8pV46cdcMIOOR/GXHDqhJTceptAfmgYPyhMBXafQ5fzqBtFbET/iWOSUlipFPs7h0TY7ErsEupIqNvESbUNyygQCVPTo+JwbNSY/hoZOYhgE/RT3AFYi9y2RPImJjF54=; X-YMail-OSG: GAFv6rMVM1nTTRI3.bPw90cIP4_rLakC.dpowvzVfYX8y97 JRKOsXfhfzsDWfb9FghU3xHk3Q3TaKdxDsvaFULA7IMDgBBFZTzcDizu9QpA 5vRZ.FaVzS9VZPZvSEOGCI7fNdgq2UZ79Lof8ajCXEF958ZQO7X4rzTUB5Xl DYSldocy2PVkBPBpULuT_CmPW52IALEZSySdnjy7CgOSgZ29Tw4ENisJW4p5 ELijsK_gbWxiUo557e4OVIg03l2YcZQsTNB4xB5FHQ_hb9Holr4C3txAiPHP 3cc85vEYDePSvEAZ_jD3348R.8Qetq1SLGAc08i_p_HTWhh7N0gi6cNys6mN AHWYgsxHDVd88tbYpay.zTlvxudOep3LzhyObAeghMmmIMy.rTsDhjN4ACrz IBce67N9Lg2OGdiv7U13angwnokcn4DIvvX_U54B7e90oYNhpUAjtJ4UFFWW m6kKLjA-- Received: from [209.131.62.115] by web31801.mail.mud.yahoo.com via HTTP; Tue, 04 Sep 2012 17:34:32 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <1346804779.57122.YahooMailNeo@web31808.mail.mud.yahoo.com> Message-ID: <1346805272.48733.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Tue, 4 Sep 2012 17:34:32 -0700 (PDT) From: William Mills To: "Cantor, Scott" , "kitten@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [kitten] communicating back to the app Re: -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: Wed, 05 Sep 2012 00:34:37 -0000 Yeah, but in cases where you're interested in what 3rd party is using deleg= ated credentials you want that in the app data for logging stuff.=A0 It pro= bably does want to get communicated back.=0A=0A=0A=0A=0A----- Original Mess= age -----=0A> From: "Cantor, Scott" =0A> To: William Mill= s ; "kitten@ietf.org" =0A> Cc: =0A> = Sent: Tuesday, September 4, 2012 5:29 PM=0A> Subject: Re: [kitten] -06 post= ed Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL d= raft -05=0A> =0A> On 9/4/12 8:26 PM, "William Mills" = wrote:=0A>> =0A>> Yeah, that's probably the way it works.=A0 But now that = I think I've=0A>> grokked this=0A>> I was gonna leave it up to the mech dev= eloper and application to decide.=0A>> Just=0A>> noting that it might need = to be communicated.=A0 I can get more specific=0A>> but I can=0A>> see cust= om implementations doing something different.=0A> =0A> The problem, I think= , is that you generally want the app layer independent=0A> of the mechanism= implementation, so getting them to behave in custom ways=0A> isn't really = the goal. Obviously if you just package it up for one=0A> mechanism to run = inside a custom app, it doesn't matter.=0A> =0A> My opinion, as I have said= , is that in practice the delegation would be=0A> evaluated with the mechan= ism and not exposed, or that it would be done via=0A> hooks that call into = the mechanism explicitly with the authz-id and then=0A> it gets to do its o= wn custom eval of both the identities in the token.=0A> Either way, I don't= think both need to be exposed to the application to do=0A> useful things w= ith them.=0A> =0A> -- Scott=0A> From lukeh@padl.com Tue Sep 4 17:35: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 BCDC921E8054 for ; Tue, 4 Sep 2012 17:35: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 X7ybCqqziCHo for ; Tue, 4 Sep 2012 17:35:04 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1170221E8053 for ; Tue, 4 Sep 2012 17:35:04 -0700 (PDT) Received: by us.padl.com with ESMTP id q850YvOD014035; Tue, 4 Sep 2012 20:35:01 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Luke Howard In-Reply-To: <1346804779.57122.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Wed, 5 Sep 2012 10:34:54 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1346804073.6654.YahooMailNeo@web31810.mail.mud.yahoo.com> <1346804779.57122.YahooMailNeo@web31808.mail.mud.yahoo.com> To: William Mills 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" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 00:35:04 -0000 On 05/09/2012, at 10:26 AM, William Mills wrote: >=20 >> It depends what level of interop you're looking for, I guess. Nico = was >> trying to say that if you wanted to nail that down, you could do that = by >> specifying an encoding of the two in the single value communicated = back. >=20 > Yeah, that's probably the way it works. But now that I think I've = grokked this > I was gonna leave it up to the mech developer and application to = decide. Just > noting that it might need to be communicated. I can get more specific = but I can > see custom implementations doing something different. You probably want to say that the SASL authentication identity = corresponds to the OAuth user identity. Optionally you might define a well known GSS naming attribute (URN) that = conveys the OAuth proxy identity. Nico or Sam Hartman could give you = some guidance on this. -- Luke= From cantor.2@osu.edu Tue Sep 4 17:47:29 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 28F8821E8054 for ; Tue, 4 Sep 2012 17:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.474 X-Spam-Level: X-Spam-Status: No, score=-5.474 tagged_above=-999 required=5 tests=[AWL=1.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EyOjU335i+ID for ; Tue, 4 Sep 2012 17:47:28 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 361C221E8053 for ; Tue, 4 Sep 2012 17:47:28 -0700 (PDT) Received: from mail41-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Sep 2012 00:47:27 +0000 Received: from mail41-tx2 (localhost [127.0.0.1]) by mail41-tx2-R.bigfish.com (Postfix) with ESMTP id D2A4614008C; Wed, 5 Sep 2012 00:47:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zzbb2dI98dI9371Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail41-tx2: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail41-tx2 (localhost.localdomain [127.0.0.1]) by mail41-tx2 (MessageSwitch) id 1346806046400606_25798; Wed, 5 Sep 2012 00:47:26 +0000 (UTC) Received: from TX2EHSMHS008.bigfish.com (unknown [10.9.14.241]) by mail41-tx2.bigfish.com (Postfix) with ESMTP id 5EB3C4A0042; Wed, 5 Sep 2012 00:47:26 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by TX2EHSMHS008.bigfish.com (10.9.99.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Sep 2012 00:47:26 +0000 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, 4 Sep 2012 20:47:23 -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, 4 Sep 2012 20:47:23 -0400 From: "Cantor, Scott" To: William Mills , "kitten@ietf.org" Thread-Topic: communicating back to the app Re: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNivxhZ1NOEL+hvkCxa7oYN7r9pJd7JziA//+97ICAAERgAP//wISA Date: Wed, 5 Sep 2012 00:47:22 +0000 Message-ID: In-Reply-To: <1346805272.48733.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: [71.74.80.179] Content-Type: text/plain; charset="us-ascii" Content-ID: <3BC9A87DA263BA4E990879833A8F4B42@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Subject: Re: [kitten] communicating back to the app Re: -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 00:47:29 -0000 On 9/4/12 8:34 PM, "William Mills" wrote: >Yeah, but in cases where you're interested in what 3rd party is using >delegated credentials you want that in the app data for logging stuff. Possibly, yes, or it could be logged by the mechanism. >It probably does want to get communicated back. In SASL terms, I don't know that you'd have much option but to carry it in a combined value. In GSS, you definitely can just expose it as a name attribute and/or you can carry it in a custom mechanism name-type. - Scott From lukeh@padl.com Tue Sep 4 17:55: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 5784321E8092 for ; Tue, 4 Sep 2012 17:55:47 -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 PwIxzIKGqEnD for ; Tue, 4 Sep 2012 17:55:47 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id C951F21E8053 for ; Tue, 4 Sep 2012 17:55:46 -0700 (PDT) Received: by us.padl.com with ESMTP id q850tfdN015429; Tue, 4 Sep 2012 20:55:44 -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, 5 Sep 2012 10:55:38 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <54AF2A9F-2679-4C1C-A253-21B8AD924E3A@padl.com> References: To: "Cantor, Scott" 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] communicating back to the app Re: -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 00:55:47 -0000 On 05/09/2012, at 10:47 AM, "Cantor, Scott" wrote: >> It probably does want to get communicated back. >=20 > In SASL terms, I don't know that you'd have much option but to carry = it in > a combined value. In GSS, you definitely can just expose it as a name > attribute and/or you can carry it in a custom mechanism name-type. I suspect carrying it in a combined value is going to cause problems = with mechanism-agnostic applications that assume, in the absence of an = explicit authorisation identity, the authentication identity can be = interpreted similarly. If that makes any sense... -- Luke= From cantor.2@osu.edu Tue Sep 4 18:01: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 588DA21E8096 for ; Tue, 4 Sep 2012 18:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-0.600, 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 rQzlae7q3or2 for ; Tue, 4 Sep 2012 18:01:13 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1B62D21E8092 for ; Tue, 4 Sep 2012 18:01:12 -0700 (PDT) Received: from mail258-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Sep 2012 01:01:12 +0000 Received: from mail258-va3 (localhost [127.0.0.1]) by mail258-va3-R.bigfish.com (Postfix) with ESMTP id 711ECA800A8; Wed, 5 Sep 2012 01:01:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail258-va3: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail258-va3 (localhost.localdomain [127.0.0.1]) by mail258-va3 (MessageSwitch) id 1346806870284070_5509; Wed, 5 Sep 2012 01:01:10 +0000 (UTC) Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.243]) by mail258-va3.bigfish.com (Postfix) with ESMTP id 3B0B2D00043; Wed, 5 Sep 2012 01:01:10 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Sep 2012 01:01:05 +0000 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, 4 Sep 2012 21:01:04 -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, 4 Sep 2012 21:01:04 -0400 From: "Cantor, Scott" To: Luke Howard Thread-Topic: [kitten] communicating back to the app Re: -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNiwEwxgMOhU5w5k+qNQPivkZU55d67dMA Date: Wed, 5 Sep 2012 01:01:04 +0000 Message-ID: In-Reply-To: <54AF2A9F-2679-4C1C-A253-21B8AD924E3A@padl.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [kitten] communicating back to the app Re: -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 01:01:14 -0000 On 9/4/12 8:55 PM, "Luke Howard" wrote: > >On 05/09/2012, at 10:47 AM, "Cantor, Scott" wrote: > >>In SASL terms, I don't know that you'd have much option but to carry it >>in >> a combined value. In GSS, you definitely can just expose it as a name >> attribute and/or you can carry it in a custom mechanism name-type. > >I suspect carrying it in a combined value is going to cause problems with >mechanism-agnostic applications that assume, in the absence of an >explicit authorisation identity, the authentication identity can be >interpreted similarly. If that makes any sense... Yes, that was really what I expected somebody would say. ;-) But I don't know if SASL APIs in general would get you access to the GSS name underneath to be able to extract the data in other ways. That's clearly better. In fact, I'll just say that I don't think OAuth has only those two pieces of information in play, any more than SAML would. A SAML assertion has lots of information the app might want, even aside from extensible user attributes, which I know that OAuth will also have to support. So at some point, I think you have to accept that if all you have is "userid", that's just for compatibility/normalization and that newer apps with real needs are going to have to go after the GSS attributes. You can handle the particular case of the client ID in OAuth alone, but that's just going to solve a small part of the general problem. -- Scott From rra@stanford.edu Tue Sep 4 18:02: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 959EF21E8096 for ; Tue, 4 Sep 2012 18:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Ui+nPBeVSpck for ; Tue, 4 Sep 2012 18:02:36 -0700 (PDT) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id E2AEF21E8092 for ; Tue, 4 Sep 2012 18:02:35 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C647D6291CB for ; Tue, 4 Sep 2012 18:02:34 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 454DC6291CC for ; Tue, 4 Sep 2012 18:02:34 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 30F0B2F4E8; Tue, 4 Sep 2012 18:02:33 -0700 (PDT) From: Russ Allbery To: "kitten\@ietf.org" In-Reply-To: (Scott Cantor's message of "Wed, 5 Sep 2012 01:01:04 +0000") Organization: The Eyrie References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Tue, 04 Sep 2012 18:02:33 -0700 Message-ID: <871uihqo2e.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [kitten] communicating back to the app Re: -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 01:02:36 -0000 "Cantor, Scott" writes: > In fact, I'll just say that I don't think OAuth has only those two > pieces of information in play, any more than SAML would. A SAML > assertion has lots of information the app might want, even aside from > extensible user attributes, which I know that OAuth will also have to > support. So at some point, I think you have to accept that if all you > have is "userid", that's just for compatibility/normalization and that > newer apps with real needs are going to have to go after the GSS > attributes. Yes, this sounds right to me too. -- Russ Allbery (rra@stanford.edu) From lukeh@padl.com Tue Sep 4 18:07: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 D0F3B21F8446 for ; Tue, 4 Sep 2012 18:07:24 -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 qjoULGxAw0j4 for ; Tue, 4 Sep 2012 18:07:24 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 42E1921F8444 for ; Tue, 4 Sep 2012 18:07:24 -0700 (PDT) Received: by us.padl.com with ESMTP id q8517Ii4015643; Tue, 4 Sep 2012 21:07:23 -0400 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <0583F627-2F4D-4014-A8BB-BF1C50A4148F@padl.com> X-Mailer: iPhone Mail (9B206) From: Luke Howard Date: Wed, 5 Sep 2012 11:07:14 +1000 To: "Cantor, Scott" X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.9 Cc: "kitten@ietf.org" Subject: Re: [kitten] communicating back to the app Re: -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 01:07:25 -0000 Cyrus does. You could do something similar with SSPI. Sent from my iPhone On 05/09/2012, at 11:01, "Cantor, Scott" wrote: > But I don't know if SASL APIs in general would get you access to the GSS > name underneath to be able to extract the data in other ways. That's > clearly better. From nico@cryptonector.com Tue Sep 4 19:10: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 4686821F84B9 for ; Tue, 4 Sep 2012 19:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 Q1G4QeZsEVUo for ; Tue, 4 Sep 2012 19:10:52 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 42E6E21F84B8 for ; Tue, 4 Sep 2012 19:10:52 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id CB42D318059 for ; Tue, 4 Sep 2012 19:10:51 -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=ZLZhob5/YrDS8J0ktiq1 sNm3TuQ=; b=iuQFnq1CQB6UjQ5dBWlXNWv9l65Lv9e64GzkehBQx3TCktkWIM2U LtV3/bok7iH5i1Tek5oO50Svkgrex6Iwy3YayfN4osAfGvFm346o7w3MpMNyDUlL QLuF+EvcOMERvx+j+kyXToWmXPLeruQKeVDNutA7VlMyQs5fQbeUdqI= 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-a89.g.dreamhost.com (Postfix) with ESMTPSA id AA7B6318058 for ; Tue, 4 Sep 2012 19:10:51 -0700 (PDT) Received: by dadf8 with SMTP id f8so4550013dad.31 for ; Tue, 04 Sep 2012 19:10:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.73 with SMTP id ra9mr50139662pbc.85.1346811051143; Tue, 04 Sep 2012 19:10:51 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 19:10:50 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 19:10:50 -0700 (PDT) In-Reply-To: <0583F627-2F4D-4014-A8BB-BF1C50A4148F@padl.com> References: <0583F627-2F4D-4014-A8BB-BF1C50A4148F@padl.com> Date: Tue, 4 Sep 2012 21:10:50 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: multipart/alternative; boundary=047d7b1605a148718b04c8eae2a4 Cc: kitten@ietf.org Subject: Re: [kitten] communicating back to the app Re: -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 02:10:56 -0000 --047d7b1605a148718b04c8eae2a4 Content-Type: text/plain; charset=UTF-8 On Sep 4, 2012 9:07 PM, "Luke Howard" wrote: > > Cyrus does. You could do something similar with SSPI. What Luke said. --047d7b1605a148718b04c8eae2a4 Content-Type: text/html; charset=UTF-8


On Sep 4, 2012 9:07 PM, "Luke Howard" <lukeh@padl.com> wrote:
>
> Cyrus does. You could do something similar with SSPI.

What Luke said.

--047d7b1605a148718b04c8eae2a4-- From nico@cryptonector.com Tue Sep 4 21:20: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 9A04A11E80D9 for ; Tue, 4 Sep 2012 21:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ya7HSqXaHaLA for ; Tue, 4 Sep 2012 21:20:11 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id EA36511E80D3 for ; Tue, 4 Sep 2012 21:20:11 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 9C6CD59805F for ; Tue, 4 Sep 2012 21:20:11 -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=404pIsmMIzis1CUd3J7e QvotThk=; b=u30V++Fg9iHfHqT7t9Vo2yL1N0bw5uxZ6lMQ5hLtS8Za6+/s4Z3E R8QwunfJPUtvZVgJXEtZF9c9HajudhW8B1hs9zWKyWCg2IZzi7w3I+nwAOfULzRS 98GAyenofM7ZjZ+KOo95QYLQ9Bg5qWN6mOSMssmXK0/HBnMCKZ4dDcA= 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-a27.g.dreamhost.com (Postfix) with ESMTPSA id 8266F598058 for ; Tue, 4 Sep 2012 21:20:11 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so246558pbb.31 for ; Tue, 04 Sep 2012 21:20:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.90.4 with SMTP id bs4mr24332457pab.3.1346818811154; Tue, 04 Sep 2012 21:20:11 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 4 Sep 2012 21:20:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Sep 2012 23:20:11 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 04:20:12 -0000 On Tue, Sep 4, 2012 at 7:11 PM, Cantor, Scott wrote: > On 9/4/12 7:20 PM, "Nico Williams" wrote: >>The key is that the mechanism transports the authz-id *with* integrity >>protection. > > I believe that's only in the case where channel binding is possible. > Otherwise, it's left to TLS to protect it all and you punt. Indeed. GS2 kinda sorta (no, really) presumes CB... > I note that since the vastly more common OAuth case will be bearer tokens > and no CB. I'll pretend that that isn't so and then we can pretend that bearer mechanisms (or any half round trip mechanisms; a 1 round trip bearer token mech could handle CB) handle CB :) Nico -- From simon@josefsson.org Tue Sep 4 23:49: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 1C5DB21F8518 for ; Tue, 4 Sep 2012 23:49:08 -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 f1M4FHOcVZ24 for ; Tue, 4 Sep 2012 23:49:07 -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 532F321F8522 for ; Tue, 4 Sep 2012 23:49:07 -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 q856mnSR018628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Sep 2012 08:48:50 +0200 From: Simon Josefsson To: "Cantor\, Scott" References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120905:kitten@ietf.org::tPM7Zu8neHg8XNis:2yNz X-Hashcash: 1:22:120905:cantor.2@osu.edu::9nVQspA/nbKzaBL8:36R8 X-Hashcash: 1:22:120905:nico@cryptonector.com::Pmij0OpYWp+I10rp:4Ln0 X-Hashcash: 1:22:120905:wmills@yahoo-inc.com::F3bdAzex6/vjYIFc:Qf+B Date: Wed, 05 Sep 2012 08:48:46 +0200 In-Reply-To: (Scott Cantor's message of "Tue, 4 Sep 2012 20:43:30 +0000") Message-ID: <87bohlotgx.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] -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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 06:49:08 -0000 "Cantor, Scott" writes: > On 9/4/12 4:40 PM, "Nico Williams" wrote: >> >>The question is: which ID is best to report as the authcid: the user, >>or the agent ID? > > Almost certainly the user. The OAuth mechanism should be evaluating the > suitability of the token, and part of that involves the policy decision > about who can wield tokens for some set of users, I would imagine. I agree. SASL only has the concept of clients and servers -- it doesn't have a concept of agents. So from the SASL point of view, I believe the agent could be seen as acting as a proxy for the user, so the identity to report should be the user's. /Simon From wmills@yahoo-inc.com Wed Sep 5 07:33: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 4846421F85A4 for ; Wed, 5 Sep 2012 07:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Q6-18eCRpzB9 for ; Wed, 5 Sep 2012 07:33:30 -0700 (PDT) Received: from nm25-vm0.bullet.mail.bf1.yahoo.com (nm25-vm0.bullet.mail.bf1.yahoo.com [98.139.213.156]) by ietfa.amsl.com (Postfix) with SMTP id 3F85E21F8551 for ; Wed, 5 Sep 2012 07:33:30 -0700 (PDT) Received: from [98.139.212.149] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 05 Sep 2012 14:33:29 -0000 Received: from [98.139.212.229] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 05 Sep 2012 14:33:29 -0000 Received: from [127.0.0.1] by omp1038.mail.bf1.yahoo.com with NNFMP; 05 Sep 2012 14:33:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 674621.51950.bm@omp1038.mail.bf1.yahoo.com Received: (qmail 34854 invoked by uid 60001); 5 Sep 2012 14:33:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1346855608; bh=O/Bf/X5J7XAwob7SUDuRfJqdOxp3gZJFvSWLOyTpWvY=; 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=L35ojxhNqfwPuI7gldRzpmeH8Z+UEaq7Znnu5Ol45WuSWU7atALGOAmJwuqew+4SJR3aZAyWC/RrNxpAK+X3zS/PwgJGf0YcwbQpEQ83lm35aAVB5I++UTzuWAudsqVTvRm+y2fEvEwcoZH/XJ64HyniZk2Ov7k9UTIsnvrZmtU= 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=bYt+msQ6lo7dcKfOGs6EHZGFsNrcw/En/yhrdsSD6XwqcuJgC6gB+brmdEg7PIVunMy3iI1BNkQFy0M3JYSX614DFJgKXuG6IxZoBllw/U7oxe9DhtgPDgjOPMsYzxIk/hXRUPx3RMXEU4m4C7YO3ldKM3ELj+q8QS6BFiTE4xQ=; X-YMail-OSG: l4q301sVM1m2kUzZ.mviJoqcu.X0l7qg8z33R2Z0IJ9aqKN mIYnxdj9Y97ksl8V836jGYEETJ4jON_iIJFgG_Er_JlOYkDd.fXG4_vt_S3C yCc7o4jRoo4O0h_G7Md32XjqDr18EBhU3YaNU3lHW9wnR9u18LaiRiKToflp 2vN3P_WZjg9OLr4cRL0ZCoDNTXZ5A4KwqpataKvVuV4QrskhOuqEpdvABuXh Yn1ICCJW3jp3E7tWSSGR1N2ghaf3NNLXXIOve7nSw_rhkBEpVWax2K94K.Yx usE1uAxe3XIxTC2CiQnDBbzUNwE5eoricliLnqq_4gWs8Mz7KrKowKtDereQ hZfDaC3Ke.fWYZ3HOca_VeJQMJiRckuvq0a34zNoXnXvF.dY1jFHvk.EKSB1 CsKNU8Ruo.JIjC2QTW4Ejq_cSDy1ZbRWrahbf2trkRQEY2GDjAEdOVW_9tEb 0AQgcISo- Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Wed, 05 Sep 2012 07:33:28 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <87bohlotgx.fsf@latte.josefsson.org> Message-ID: <1346855608.8694.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Wed, 5 Sep 2012 07:33:28 -0700 (PDT) From: William Mills To: Simon Josefsson , "Cantor, Scott" In-Reply-To: <87bohlotgx.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-1949381511-1346855608=:8694" Cc: "kitten@ietf.org" Subject: Re: [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: Wed, 05 Sep 2012 14:33:31 -0000 --835683298-1949381511-1346855608=:8694 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OK, so it sounds like the proposed text is OK?=0A=0A=0A=0A=0A=0A>__________= ______________________=0A> From: Simon Josefsson =0A>T= o: "Cantor, Scott" =0A>Cc: Nico Williams ; William Mills ; "kitten@ietf.org" =0A>Sent: Tuesday, September 4, 2012 11:48 PM=0A>Subject: Re: [kit= ten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re:= OAuth SASL draft -05=0A> =0A>"Cantor, Scott" writes:=0A= >=0A>> On 9/4/12 4:40 PM, "Nico Williams" wrote:=0A= >>>=0A>>>The question is: which ID is best to report as the authcid: the us= er,=0A>>>or the agent ID?=0A>>=0A>> Almost certainly the user. The OAuth me= chanism should be evaluating the=0A>> suitability of the token, and part of= that involves the policy decision=0A>> about who can wield tokens for some= set of users, I would imagine.=0A>=0A>I agree.=A0 SASL only has the concep= t of clients and servers -- it doesn't=0A>have a concept of agents.=A0 So f= rom the SASL point of view, I believe the=0A>agent could be seen as acting = as a proxy for the user, so the identity=0A>to report should be the user's.= =0A>=0A>/Simon=0A>=0A>=0A> --835683298-1949381511-1346855608=:8694 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OK, so it= sounds like the proposed text is OK?

<= br>
= From: Simon Josefsson <= simon@josefsson.org>
To: "Cantor, Scott" <cantor.2@osu.edu>
Cc: Nico Williams <nico@cryptonector.com>; W= illiam Mills <wmills@yahoo-inc.com>; "kitten@ietf.org" <kitten@iet= f.org>
Sent: Tuesday, September = 4, 2012 11:48 PM
Subject:<= /b> Re: [kitten] -06 posted Re: requirements/context/frustration Re: Comma = vs. %x01 Re: OAuth SASL draft -05

"Cantor, Scott" &l= t;c= antor.2@osu.edu> writes:

> On 9/4/12 4:40 PM, "Nico Willia= ms" <nico@cryptonector.com> wrote:
>>
>>= The question is: which ID is best to report as the authcid: the user,
&g= t;>or the agent ID?
>
> Almost certainly the user. The OAuth= mechanism should be evaluating the
> suitability of the token, and p= art of that involves the policy decision
> about who can wield tokens= for some set of users, I would imagine.

I agree.  SASL only ha= s the concept of clients and servers -- it doesn't
have a concept of agents.&= nbsp; So from the SASL point of view, I believe the
agent could be seen = as acting as a proxy for the user, so the identity
to report should be t= he user's.

/Simon


--835683298-1949381511-1346855608=:8694-- From nico@cryptonector.com Wed Sep 5 09:01: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 8FC7A21F8661 for ; Wed, 5 Sep 2012 09:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 s1Nh6dRNVtpQ for ; Wed, 5 Sep 2012 09:01:40 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 01EC421F865D for ; Wed, 5 Sep 2012 09:01:39 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id A9DC126C07C for ; Wed, 5 Sep 2012 09:01: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=r2652+/7Me5suyD9vqau MuViGpw=; b=fckXxS9lBbEeP73Lpr0mIPKsa9Dp+3Ctu5ElpCkD6HM7mZrzWqJK ylpRusO5jbIgkbW5bo79jgbXY6z5GDLYjVWyEHZsUvvJao2/K0wduBRc57TuYupV vf/VIn0u9fTun6OyTVAN0BaSDeVFVKZ0ke/8256DWqmRHg34FWL0I9w= 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-a87.g.dreamhost.com (Postfix) with ESMTPSA id 97BF826C079 for ; Wed, 5 Sep 2012 09:01:38 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1157462pbb.31 for ; Wed, 05 Sep 2012 09:01:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr53378323pbc.149.1346860898265; Wed, 05 Sep 2012 09:01:38 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 5 Sep 2012 09:01:37 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 5 Sep 2012 09:01:37 -0700 (PDT) In-Reply-To: <87bohlotgx.fsf@latte.josefsson.org> References: <87bohlotgx.fsf@latte.josefsson.org> Date: Wed, 5 Sep 2012 11:01:37 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: multipart/alternative; boundary=e89a8ff256d867299704c8f67db0 Cc: kitten@ietf.org Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 16:01:40 -0000 --e89a8ff256d867299704c8f67db0 Content-Type: text/plain; charset=UTF-8 On Sep 5, 2012 2:49 AM, "Simon Josefsson" wrote: > > "Cantor, Scott" writes: > > > On 9/4/12 4:40 PM, "Nico Williams" wrote: > >> > >>The question is: which ID is best to report as the authcid: the user, > >>or the agent ID? > > > > Almost certainly the user. The OAuth mechanism should be evaluating the > > suitability of the token, and part of that involves the policy decision > > about who can wield tokens for some set of users, I would imagine. > > I agree. SASL only has the concept of clients and servers -- it doesn't > have a concept of agents. So from the SASL point of view, I believe the > agent could be seen as acting as a proxy for the user, so the identity > to report should be the user's. Agreed. My suggestion of using a composite of the two IDs was only in case that William felt quite certain that apps must take both into account, so much so that existing apps must fail when used with this mechanism. But i don't think that's really the case. --e89a8ff256d867299704c8f67db0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sep 5, 2012 2:49 AM, "Simon Josefsson" <simon@josefsson.org> wrote:
>
> "Cantor, Scott" <cant= or.2@osu.edu> writes:
>
> > On 9/4/12 4:40 PM, "Nico Williams" <nico@cryptonector.com> wrote:
> >>
> >>The question is: which ID is best to report as the authcid: th= e user,
> >>or the agent ID?
> >
> > Almost certainly the user. The OAuth mechanism should be evaluati= ng the
> > suitability of the token, and part of that involves the policy de= cision
> > about who can wield tokens for some set of users, I would imagine= .
>
> I agree. =C2=A0SASL only has the concept of clients and servers -- it = doesn't
> have a concept of agents. =C2=A0So from the SASL point of view, I beli= eve the
> agent could be seen as acting as a proxy for the user, so the identity=
> to report should be the user's.

Agreed.=C2=A0 My suggestion of using a composite of the two IDs was only= in case that William felt quite certain that apps must take both into acco= unt, so much so that existing apps must fail when used with this mechanism.= =C2=A0 But i don't think that's really the case.

--e89a8ff256d867299704c8f67db0-- From cantor.2@osu.edu Wed Sep 5 09:04: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 DC8E421F8669 for ; Wed, 5 Sep 2012 09:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.786 X-Spam-Level: X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[AWL=-0.187, 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 IwoN6yW3Llen for ; Wed, 5 Sep 2012 09:04:49 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id CDF8521F8667 for ; Wed, 5 Sep 2012 09:04:44 -0700 (PDT) Received: from mail57-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Sep 2012 16:04:43 +0000 Received: from mail57-va3 (localhost [127.0.0.1]) by mail57-va3-R.bigfish.com (Postfix) with ESMTP id 8DC33100073; Wed, 5 Sep 2012 16:04:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202hzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1151h1155h) Received-SPF: pass (mail57-va3: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail57-va3 (localhost.localdomain [127.0.0.1]) by mail57-va3 (MessageSwitch) id 1346861082626513_6830; Wed, 5 Sep 2012 16:04:42 +0000 (UTC) Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.242]) by mail57-va3.bigfish.com (Postfix) with ESMTP id 928DE60042; Wed, 5 Sep 2012 16:04:42 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Sep 2012 16:04:40 +0000 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, 5 Sep 2012 12:04:37 -0400 From: "Cantor, Scott" To: William Mills , Simon Josefsson Thread-Topic: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 Thread-Index: AQHNirNaDj304+GtZUyptIjTd8k0Mpd6md8A///GkwCAAEU2gP//whkAgABHYwD//873AAAI2AyA///buq2AAEgCgP//vd8AgAEreuGAABjwAA== Date: Wed, 5 Sep 2012 16:04:37 +0000 Message-ID: In-Reply-To: <1346855608.8694.YahooMailNeo@web31804.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 16:04:51 -0000 On 9/5/12 10:33 AM, "William Mills" wrote: > >OK, so it sounds like the proposed text is OK? What I recall looked ok. You could spin a new draft or just drop a pointer to where you ended up. You may want to drop in a reference to the name attributes RFC and just note the possibility of exposing additional OAuth data through that mechanism. -- Scott From internet-drafts@ietf.org Wed Sep 12 23:41: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 8FB2321E8051; Wed, 12 Sep 2012 23:41:11 -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=[AWL=0.000, 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 MzrIjPQE+xLB; Wed, 12 Sep 2012 23:41:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1598421E8040; Wed, 12 Sep 2012 23:41:11 -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: <20120913064111.30988.73947.idtracker@ietfa.amsl.com> Date: Wed, 12 Sep 2012 23:41:11 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.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, 13 Sep 2012 06:41:11 -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-07.txt Pages : 30 Date : 2012-09-12 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wmills@yahoo-inc.com Wed Sep 12 23:46: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 CD5D721F84B9 for ; Wed, 12 Sep 2012 23:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.391 X-Spam-Level: X-Spam-Status: No, score=-16.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 TndAMG0DjxVi for ; Wed, 12 Sep 2012 23:46:52 -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 2C3D421F84B8 for ; Wed, 12 Sep 2012 23:46:52 -0700 (PDT) Received: from [98.139.215.143] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 13 Sep 2012 06:46:49 -0000 Received: from [98.139.212.247] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 13 Sep 2012 06:46:49 -0000 Received: from [127.0.0.1] by omp1056.mail.bf1.yahoo.com with NNFMP; 13 Sep 2012 06:46:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 258537.46318.bm@omp1056.mail.bf1.yahoo.com Received: (qmail 67923 invoked by uid 60001); 13 Sep 2012 06:46:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1347518808; bh=4u9rVjQV4ODWVqt0rIEfKAa6ubtchUwt379Qg2w8f3A=; 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=s3MGzv+UI2UciHlaIDAD0xWXyu1IlcxG4fTAZ7l/7vvLJwQDcn12hVUi9ObiKmgR8pG1qic9vES9v7LcwVnbjoG4Yy4/mC604KaIHpD3ccRVLcrnyL1/20ltpqVjx0393+uDlNRUER/Mx2QN7lwPrXiPCD+JSF7vSwNdUgaq8vQ= 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=sSzZtQDEndmMi34G39F1Z4F492pE9cFJCamZuuKLxMbcYQmu04wp0Ywhli4T+aaIOjri7A7jmCUfYF15I9IXF2EcyzVIvvbmPXUdprYDaKD7/4EcIeE8XMASSFNecWu7jOMnL8kyfm0RikJyrUYhaXxwI1wwkFKgKIfqQm98x0w=; X-YMail-OSG: Us6InJcVM1mitt1buHbdira7Vb7oNarbphU0mlUKWpwhwao 5O9EO885PkSJ2yCot5zLZouO.0mCS02JpWJLJyehQl9gY.ZGA7_.E.ukR8PJ DeYRNMwMDU6989Pb8mqYrInlP4ErSoJyHXzxB9tarv69endA4ZPgxlQG1Mfs cZs33crz8MIFDo2.2TD5bmpWrR936VNLwOQYDM_S59xLbYoYVEB3Fu0Av7rT LkfH6TXDrrloYfC.Pf9ShNrwP_AyearbFkUCQtKi223MbsJ_BEg5HFNxWi7_ lNa3KT6zoH0J_IxtyEFX6qHz23Ds7srMbvGift1WgsJf72nLpLoJ.LSTlJFC QE0r18pYgXTik1AYoa.PjELvto_c0E7StpfU9XhBcT2Vv3KNWI2k09MgS2Mm Nqa7pbEFRBKaYBg.XxsltuSxoR2xw4P0ymPaAh19ZMOjzojeazSlkHJn6qqL Cf3JtcYk- Received: from [209.131.62.115] by web31811.mail.mud.yahoo.com via HTTP; Wed, 12 Sep 2012 23:46:48 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <1346855608.8694.YahooMailNeo@web31804.mail.mud.yahoo.com> Message-ID: <1347518808.65362.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Wed, 12 Sep 2012 23:46:48 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Simon Josefsson In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-1226737660-1347518808=:65362" Cc: "kitten@ietf.org" Subject: [kitten] -07 spun out Re: -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: Thu, 13 Sep 2012 06:46:53 -0000 --764183289-1226737660-1347518808=:65362 Content-Type: text/plain; charset=us-ascii Submitted -07 http://www.ietf.org/id/draft-ietf-kitten-sasl-oauth-07.txt http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ -bill >________________________________ > From: "Cantor, Scott" >To: William Mills ; Simon Josefsson >Cc: Nico Williams ; "kitten@ietf.org" >Sent: Wednesday, September 5, 2012 9:04 AM >Subject: Re: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05 > >On 9/5/12 10:33 AM, "William Mills" wrote: >> >>OK, so it sounds like the proposed text is OK? > >What I recall looked ok. You could spin a new draft or just drop a pointer >to where you ended up. You may want to drop in a reference to the name >attributes RFC and just note the possibility of exposing additional OAuth >data through that mechanism. > >-- Scott > > > > > --764183289-1226737660-1347518808=:65362 Content-Type: text/html; charset=us-ascii
Submitted -07 http://www.ietf.org/id/draft-ietf-kitten-sasl-oauth-07.txt

http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/

-bill

From: "Cantor, Scott" <cantor.2@osu.edu>
To: William Mills <wmills@yahoo-inc.com>; Simon Josefsson <simon@josefsson.org>
Cc: Nico Williams <nico@cryptonector.com>; "kitten@ietf.org" <kitten@ietf.org>
Sent: Wednesday, September 5, 2012 9:04 AM
Subject: Re: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05

On 9/5/12 10:33 AM, "William Mills" <wmills@yahoo-inc.com> wrote:
>
>OK, so it sounds like the proposed text is OK?

What I recall looked ok. You could spin a new draft or just drop a pointer
to where you ended up. You may want to drop in a reference to the name
attributes RFC and just note the possibility of exposing additional OAuth
data through that mechanism.

-- Scott




--764183289-1226737660-1347518808=:65362-- From simon@josefsson.org Thu Sep 13 00:14: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 4C44221F849A for ; Thu, 13 Sep 2012 00:14:37 -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 OUmfEIFmFM2o for ; Thu, 13 Sep 2012 00:14:36 -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 5087821F846C for ; Thu, 13 Sep 2012 00:14: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 q8D7ERas013172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 13 Sep 2012 09:14:28 +0200 From: Simon Josefsson To: kitten@ietf.org References: <20120913064111.30988.73947.idtracker__13304.7408344739$1347518481$gmane$org@ietfa.amsl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120913:kitten@ietf.org::cH5o0B1Vq82Te0Cq:37wn X-Hashcash: 1:22:120913:i-d-announce@ietf.org::NRgQAOddSvlk06mk:7+5L X-Hashcash: 1:22:120913:internet-drafts@ietf.org::SlruLO30OWmXHmEb:RJa6 Date: Thu, 13 Sep 2012 09:14:24 +0200 In-Reply-To: <20120913064111.30988.73947.idtracker__13304.7408344739$1347518481$gmane$org@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Wed, 12 Sep 2012 23:41:11 -0700") Message-ID: <87ehm6qtrj.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-07.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, 13 Sep 2012 07:14:37 -0000 Thanks for update, Quick review of the text that have changed since -07 below. Section 3.2: The authenticated identity reported by the mechanism is the identity which the mechanism has securely established for the client with the OAuth credential. This confuses me, I believe the two uses of the word 'mechanism' refer to different things. Should it be: The authenticated identity reported by the SASL mechanism shall be the identity which the OAuth mechanism has securely established for the client with the OAuth credential. ? I'm still not sure this is unambigious since OAuth may establish two identities, of the user and the proxy. I suspect "the identity" could be qualified to be the user (and OAuth 1.x and 2.x uses different terms here if I recall correctly). Section 3.2.1: Note that the semantics of the authz-id are specified by the SASL framework [RFC4422]. A SASL application is, of course, free to apply mappings of the OAuth authcid to authz-ids as per-SASL, and it is free to apply mappings common to non-SASL OAuth applications. The first sentence is great, but the term 'authz-id' should be explained. The second sentence is confusing. First, there is no such thing as a per-SASL authcid to authzid mapping: those mappings are by definition always mechanism dependent, since the authcid form is mechanism dependent. Second, "authz-id" refer to the authorization identity field, which can be empty, so what you want to map to is not the authz-id but the general concept of the identity to act as. I encourage you to re-read this part from 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). So, I don't think your second sentence above adds any value, at least the current text doesn't do it for me right now. I would simply leave it as: Note that the semantics of the authorization identity is specified by the SASL framework [RFC4422]. You don't have to say anything further than that. Section 3.2.1: If both identities are needed by an application the developer will need to provide a way to communicate that from the SASL mechanism back to the application such as a GS2 [RFC2473] named type like GSS_C_NT_USER_NAME or a comparable newly defined GS2 attribute. RFC 2743 (sic) is called GSS-API not GS2. The final "GS2 attribute" should be "GSS-API name type or name attribute [RFC 6680]". Section 5.2: p,a=user@example.com^A This is wrong, you changed 'y' to 'p' which doesn't conform to the ABNF. Please see my review comment of -06 on this. /Simon From hannes.tschofenig@gmx.net Thu Sep 13 00:24: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 7196021F8468 for ; Thu, 13 Sep 2012 00:24:06 -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 777Jq1Aw+FS3 for ; Thu, 13 Sep 2012 00:24:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 7101421F843A for ; Thu, 13 Sep 2012 00:24:05 -0700 (PDT) Received: (qmail invoked by alias); 13 Sep 2012 07:24:02 -0000 Received: from unknown (EHLO [10.255.128.40]) [194.251.119.201] by mail.gmx.net (mp017) with SMTP; 13 Sep 2012 09:24:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ZAFdrmf7ZvJEIledTZDtN0PQrVZ6eY8CQ6p+fYn K3lfkU8pD49uvn Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <87ehm6qtrj.fsf@latte.josefsson.org> Date: Thu, 13 Sep 2012 10:23:58 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120913064111.30988.73947.idtracker__13304.7408344739$1347518481$gmane$org@ietfa.amsl.com> <87ehm6qtrj.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] I-D Action: draft-ietf-kitten-sasl-oauth-07.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, 13 Sep 2012 07:24:06 -0000 Very quick response only.=20 The term 'identity' is confusing here since we are really only talking = about an identifier instead.=20 OAuth 2.0 has the client authentication as part of the specification. = There is a client identifier that is conveyed as part of that exchange. = The Resource Owner authentication is not part of the specification = itself and also the information about the authenticated Resource Owner, = which would go into the Access Token, is not standardized either.=20 What Bill tries to say in the draft is that there has to be a link = between the identifier used in SASL and the identifier used for = authentication of the Resource Owner in OAuth. (I don't think the client = identifier matters here with respect to the SASL interaction as such.) I don't think it makes sense to require the identifier used for = authentication of the resource owner to be the same as the one in SASL = but I believe we want to make sure that the Access Token contains = information about what the matching identifier in SASL is.=20 Does this make sense? =20 On Sep 13, 2012, at 10:14 AM, Simon Josefsson wrote: > Thanks for update, >=20 > Quick review of the text that have changed since -07 below. >=20 > Section 3.2: >=20 > The authenticated identity reported > by the mechanism is the identity which the mechanism has securely > established for the client with the OAuth credential. >=20 > This confuses me, I believe the two uses of the word 'mechanism' refer > to different things. Should it be: >=20 > The authenticated identity reported by the SASL mechanism shall be > the identity which the OAuth mechanism has securely established for > the client with the OAuth credential. >=20 > ? >=20 > I'm still not sure this is unambigious since OAuth may establish two > identities, of the user and the proxy. I suspect "the identity" could > be qualified to be the user (and OAuth 1.x and 2.x uses different = terms > here if I recall correctly). >=20 From simon@josefsson.org Thu Sep 13 00:49: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 BDD7421F8498 for ; Thu, 13 Sep 2012 00:49:23 -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 QdTQs-d0KUeI for ; Thu, 13 Sep 2012 00:49:23 -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 9089E21F853E for ; Thu, 13 Sep 2012 00:49:17 -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 q8D7n6vc014751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Sep 2012 09:49:08 +0200 From: Simon Josefsson To: Hannes Tschofenig References: <20120913064111.30988.73947.idtracker__13304.7408344739$1347518481$gmane$org@ietfa.amsl.com> <87ehm6qtrj.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120913:kitten@ietf.org::TdrmtMNV5OSsKW5k:0qlH X-Hashcash: 1:22:120913:hannes.tschofenig@gmx.net::5nXf2XgFG0LPRRI8:nhsr Date: Thu, 13 Sep 2012 09:49:04 +0200 In-Reply-To: (Hannes Tschofenig's message of "Thu, 13 Sep 2012 10:23:58 +0300") Message-ID: <87zk4updlb.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] I-D Action: draft-ietf-kitten-sasl-oauth-07.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, 13 Sep 2012 07:49:23 -0000 Hannes Tschofenig writes: > Very quick response only. > > The term 'identity' is confusing here since we are really only talking > about an identifier instead. > > OAuth 2.0 has the client authentication as part of the > specification. There is a client identifier that is conveyed as part > of that exchange. The Resource Owner authentication is not part of the > specification itself and also the information about the authenticated > Resource Owner, which would go into the Access Token, is not > standardized either. This appears to reinforce our earlier agreement that the SASL authcid for the OAuth mechanism should be the OAuth client identifier. > What Bill tries to say in the draft is that there has to be a link > between the identifier used in SASL and the identifier used for > authentication of the Resource Owner in OAuth. (I don't think the > client identifier matters here with respect to the SASL interaction as > such.) Right. This can be achieved by saying: The OAuth client identifier is used as the SASL authentication identity in the OAuth SASL mechanism. > I don't think it makes sense to require the identifier used for > authentication of the resource owner to be the same as the one in SASL > but I believe we want to make sure that the Access Token contains > information about what the matching identifier in SASL is. I'm losing you here... what is the "matching identifier"? Why would you want to include any SASL identity in the OAuth access token? It works the other way around: SASL takes the mechanism identifiers and use that as authcid. The authzid is a SASL thing that mechanisms should integrity protect but not parse. Perhaps Kerberos can work as an analogy. There clients requests a ticket for the service before starting the SASL handshake. However the identity to get the ticket for is determined by things outside of SASL (the server hostname). For good or bad, SASL doesn't do naming. > Does this make sense? Getting there.. /Simon > > On Sep 13, 2012, at 10:14 AM, Simon Josefsson wrote: > >> Thanks for update, >> >> Quick review of the text that have changed since -07 below. >> >> Section 3.2: >> >> The authenticated identity reported >> by the mechanism is the identity which the mechanism has securely >> established for the client with the OAuth credential. >> >> This confuses me, I believe the two uses of the word 'mechanism' refer >> to different things. Should it be: >> >> The authenticated identity reported by the SASL mechanism shall be >> the identity which the OAuth mechanism has securely established for >> the client with the OAuth credential. >> >> ? >> >> I'm still not sure this is unambigious since OAuth may establish two >> identities, of the user and the proxy. I suspect "the identity" could >> be qualified to be the user (and OAuth 1.x and 2.x uses different terms >> here if I recall correctly). >> From wmills@yahoo-inc.com Thu Sep 13 08: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 7095521F85D5 for ; Thu, 13 Sep 2012 08:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.518 X-Spam-Level: X-Spam-Status: No, score=-17.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 e53AYntff+ks for ; Thu, 13 Sep 2012 08:31:43 -0700 (PDT) Received: from nm3-vm0.bullet.mail.ac4.yahoo.com (nm3-vm0.bullet.mail.ac4.yahoo.com [98.139.53.204]) by ietfa.amsl.com (Postfix) with SMTP id E007C21F85C6 for ; Thu, 13 Sep 2012 08:31:42 -0700 (PDT) Received: from [98.139.52.194] by nm3.bullet.mail.ac4.yahoo.com with NNFMP; 13 Sep 2012 15:31:36 -0000 Received: from [98.139.52.168] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 13 Sep 2012 15:31:36 -0000 Received: from [127.0.0.1] by omp1051.mail.ac4.yahoo.com with NNFMP; 13 Sep 2012 15:31:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 822986.13606.bm@omp1051.mail.ac4.yahoo.com Received: (qmail 74847 invoked by uid 60001); 13 Sep 2012 15:31:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1347550296; bh=oriFBPHX1UGFfA4DKJXQbM1M68f9ZTV3zWbqWfUfnTg=; 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=h2iMZEbaPGcL/XSbZOlJyVXSA4yMIBGJehayLnbxikIcPO/0vvL5j7/MX3uayDNBH717dDhJ5j50oNPX+NtgUFNqxnR+UvtaLWCuP4Jn516bomlJmjQSFXRkHBuWd1+z2CVXyurzQW8Iqiard3vrzUJfie+ZmrLjR0bhsHe9MDY= 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=GaqJUXDYm3lXJdcBZdQNAa4s09Ifs5FCMpcnxCPi+bWL+NohJ7Fefr5XbR7E37AG7c4mQ/w+h6eI7BpH5ik4nVsB0HxCIgks7a4ZoGksMyl43XmXzPNt1xz0mUS8drJF3cVjC6PqzlCjjBlK14fWpKvGLhWZmvxJo5k723KhjQ0=; X-YMail-OSG: 6ygF2RIVM1l1KX7.GcGMMMGsfgPFo_Ovw0myI6U7RUYFutx M_Q.7c_Cfj_Ob8oHB2R.VPlH4fne2_Wc3try4CNdL2aWH17jCPawnfSMQ05B HvyF.oK9xTSpyZcuR.w7b3jArZP9iwxbg2DPbWhgS5.O_Q2ni9mzcH0R9EE5 r_HV3Ay4IS2.lW6QVb5LnoO.aBAjgQpAw3yJabXfqB6086mklGixxn1ZBbb7 pqe7tnWj.uj10Q.12Q1LoZBaB91_jnFKA1ZetRr5GeOStRH3aEsh_hNjHqXT DFQek12qzHvTodFBpFe3vQQMHsxrgtW5G9xPk5oLOyiPopKMiTgdH7cz8Vi_ irMHWdGnXvH8s0T3PoGA4CohOu1b4BXstgjwzjDW.xegXf1_9_F0LQ1acgLd gw35DVLVIBCG7i56xbo0BAWSW4_Fyu0DiEQ.uNkrcAqXbGmJnrCsg.jsL7Ba HnNwBlckP6g-- Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Thu, 13 Sep 2012 08:31:35 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <20120913064111.30988.73947.idtracker__13304.7408344739$1347518481$gmane$org@ietfa.amsl.com> <87ehm6qtrj.fsf@latte.josefsson.org> Message-ID: <1347550295.73931.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Thu, 13 Sep 2012 08:31:35 -0700 (PDT) From: William Mills To: Simon Josefsson , "kitten@ietf.org" In-Reply-To: <87ehm6qtrj.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-07.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, 13 Sep 2012 15:31:44 -0000 comment inline...=A0 Thanks for the reading.=0A=0A=0A>_____________________= ___________=0A> From: Simon Josefsson =0A>To: kitten@i= etf.org =0A>Sent: Thursday, September 13, 2012 12:14 AM=0A>Subject: Re: [ki= tten] I-D Action: draft-ietf-kitten-sasl-oauth-07.txt=0A> =0A>Thanks for up= date,=0A>=0A>Quick review of the text that have changed since -07 below.=0A= >=0A>Section 3.2:=0A>=0A>=A0=A0=A0The authenticated identity reported=0A>= =A0=A0=A0by the mechanism is the identity which the mechanism has securely= =0A>=A0=A0=A0established for the client with the OAuth credential.=0A>=0A>T= his confuses me, I believe the two uses of the word 'mechanism' refer=0A>to= different things.=A0 Should it be:=0A>=0A>=A0=A0=A0The authenticated ident= ity reported by the SASL mechanism shall be=0A>=A0=A0=A0the identity which = the OAuth mechanism has securely established for=0A>=A0=A0=A0the client wit= h the OAuth credential.=0A>=0A>?=0A=0ANot my language here, but your langua= ge doesn't do it for me.=A0 How about=0A=0A=A0=A0 The authenticated identit= y reported by the mechanism is the user =0A=0A=A0=A0 identity securely esta= blished for the client with the OAuth credential.=0A=0A=0A>=0A>I'm still no= t sure this is unambigious since OAuth may establish two=0A>identities, of = the user and the proxy.=A0 I suspect "the identity" could=0A>be qualified t= o be the user (and OAuth 1.x and 2.x uses different terms=0A>here if I reca= ll correctly).=0A>=0A>Section 3.2.1:=0A>=0A>=A0=A0=A0Note that the semantic= s of the authz-id are specified by the SASL=0A>=A0=A0=A0framework [RFC4422]= .=A0 A SASL application is, of course, free to apply=0A>=A0=A0=A0mappings o= f the OAuth authcid to authz-ids as per-SASL, and it is=0A>=A0=A0=A0free to= apply mappings common to non-SASL OAuth applications.=0A>=0A>The first sen= tence is great, but the term 'authz-id' should be=0A>explained.=0A>=0A>The = second sentence is confusing.=A0 First, there is no such thing as a=0A>per-= SASL authcid to authzid mapping: those mappings are by definition=0A>always= mechanism dependent, since the authcid form is mechanism=0A>dependent.=A0 = Second, "authz-id" refer to the authorization identity=0A>field, which can = be empty, so what you want to map to is not the=0A>authz-id but the general= concept of the identity to act as.=0A>=0A=0ANot my language, please propos= e text.=0A=0A>I encourage you to re-read this part from RFC 4422:=0A>=0A>= =A0=A0=A0The client provides its credentials (which include or imply an=0A>= =A0=A0=A0authentication identity) and, optionally, a character string=0A>= =A0=A0=A0representing the requested authorization identity as part of the S= ASL=0A>=A0=A0=A0exchange.=A0 When this character string is omitted or empty= , the client=0A>=A0=A0=A0is requesting to act as the identity associated wi= th the credentials=0A>=A0=A0=A0(e.g., the user is requesting to act as the = authentication identity).=0A>=0A>So, I don't think your second sentence abo= ve adds any value, at least=0A>the current text doesn't do it for me right = now.=A0 I would simply leave=0A>it as:=0A>=0A>=A0=A0=A0Note that the semant= ics of the authorization identity is specified by=0A>=A0=A0=A0the SASL fram= ework [RFC4422].=0A>=0A>You don't have to say anything further than that.= =0A>=0A>Section 3.2.1:=0A>=0A>=A0=A0=A0If both identities=0A>=A0=A0=A0are n= eeded by an application the developer will need to provide a way=0A>=A0=A0= =A0to communicate that from the SASL mechanism back to the application=0A>= =A0=A0=A0such as a GS2 [RFC2473] named type like GSS_C_NT_USER_NAME or a=0A= >=A0=A0=A0comparable newly defined GS2 attribute.=0A>=0A>RFC 2743 (sic) is = called GSS-API not GS2.=A0 The final "GS2 attribute"=0A>should be "GSS-API = name type or name attribute [RFC 6680]".=0A=0Afixed, thank you=0A=0A>=0A>Se= ction 5.2:=0A>=0A>=A0=A0=A0p,a=3Duser@example.com^A=0A>=0A>This is wrong, y= ou changed 'y' to 'p' which doesn't conform to the ABNF.=0A>Please see my r= eview comment of -06 on this.=0A=0AI'll change it back, I changed it by req= uest.=0A=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 Thu Sep 13 12:44: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 230B721F85FC for ; Thu, 13 Sep 2012 12:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.692 X-Spam-Level: X-Spam-Status: No, score=-99.692 tagged_above=-999 required=5 tests=[AWL=0.217, 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 3LL6v2FczLzH for ; Thu, 13 Sep 2012 12:44:56 -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 D96B521F8528 for ; Thu, 13 Sep 2012 12:44:54 -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 q8DJimD9020847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Sep 2012 21:44:50 +0200 From: Simon Josefsson To: William Mills References: <20120913064111.30988.73947.idtracker__13304.7408344739$1347518481$gmane$org@ietfa.amsl.com> <87ehm6qtrj.fsf@latte.josefsson.org> <1347550295.73931.YahooMailNeo@web31807.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120913:kitten@ietf.org::oQtDam0x/CHetov3:0fnG X-Hashcash: 1:22:120913:wmills@yahoo-inc.com::M0klZ8QLG03zSpoT:A/b Date: Thu, 13 Sep 2012 21:44:48 +0200 In-Reply-To: <1347550295.73931.YahooMailNeo@web31807.mail.mud.yahoo.com> (William Mills's message of "Thu, 13 Sep 2012 08:31:35 -0700 (PDT)") Message-ID: <87d31pr9lb.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-07.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, 13 Sep 2012 19:44:57 -0000 William Mills writes: > comment inline...  Thanks for the reading. > > >>________________________________ >> From: Simon Josefsson >>To: kitten@ietf.org >>Sent: Thursday, September 13, 2012 12:14 AM >>Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.txt >> >>Thanks for update, >> >>Quick review of the text that have changed since -07 below. >> >>Section 3.2: >> >>   The authenticated identity reported >>   by the mechanism is the identity which the mechanism has securely >>   established for the client with the OAuth credential. >> >>This confuses me, I believe the two uses of the word 'mechanism' refer >>to different things.  Should it be: >> >>   The authenticated identity reported by the SASL mechanism shall be >>   the identity which the OAuth mechanism has securely established for >>   the client with the OAuth credential. >> >>? > > Not my language here, but your language doesn't do it for me.  How about > >    The authenticated identity reported by the mechanism is the user ^^^^^^^^^ Is this the SASL mechanism? >    identity securely established for the client with the OAuth > credential. Works for me, although Hannes indicated that "identity" is the wrong term and "client identifier" would be more correct. >>I'm still not sure this is unambigious since OAuth may establish two >>identities, of the user and the proxy.  I suspect "the identity" could >>be qualified to be the user (and OAuth 1.x and 2.x uses different terms >>here if I recall correctly). >> >>Section 3.2.1: >> >>   Note that the semantics of the authz-id are specified by the SASL >>   framework [RFC4422].  A SASL application is, of course, free to apply >>   mappings of the OAuth authcid to authz-ids as per-SASL, and it is >>   free to apply mappings common to non-SASL OAuth applications. >> >>The first sentence is great, but the term 'authz-id' should be >>explained. >> >>The second sentence is confusing.  First, there is no such thing as a >>per-SASL authcid to authzid mapping: those mappings are by definition >>always mechanism dependent, since the authcid form is mechanism >>dependent.  Second, "authz-id" refer to the authorization identity >>field, which can be empty, so what you want to map to is not the >>authz-id but the general concept of the identity to act as. >> > > Not my language, please propose text. I did propose text further down in my reply: Note that the semantics of the authorization identity is specified by the SASL framework [RFC4422]. And drop the second sentence. >>I encourage you to re-read this part from 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). >> >>So, I don't think your second sentence above adds any value, at least >>the current text doesn't do it for me right now.  I would simply leave >>it as: >> >>   Note that the semantics of the authorization identity is specified by >>   the SASL framework [RFC4422]. >> >>You don't have to say anything further than that. >> >>Section 3.2.1: >> >>   If both identities >>   are needed by an application the developer will need to provide a way >>   to communicate that from the SASL mechanism back to the application >>   such as a GS2 [RFC2473] named type like GSS_C_NT_USER_NAME or a >>   comparable newly defined GS2 attribute. >> >>RFC 2743 (sic) is called GSS-API not GS2.  The final "GS2 attribute" >>should be "GSS-API name type or name attribute [RFC 6680]". > > fixed, thank you > >> >>Section 5.2: >> >>   p,a=user@example.com^A >> >>This is wrong, you changed 'y' to 'p' which doesn't conform to the ABNF. >>Please see my review comment of -06 on this. > > I'll change it back, I changed it by request. Huh? Please read my review comment of -06. The 'y' was even more incorrect. You want 'p', but you must follow the ABNF and describe the cbtype. It could be: p=tls-unique,a=user@example.com but it depends on what you want. /Simon From cantor.2@osu.edu Thu Sep 13 12:54: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 DCF1221F859F for ; Thu, 13 Sep 2012 12:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.775 X-Spam-Level: X-Spam-Status: No, score=-3.775 tagged_above=-999 required=5 tests=[AWL=-0.176, 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 KM8xzyU2EnNN for ; Thu, 13 Sep 2012 12:54:17 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 6A94C21F8587 for ; Thu, 13 Sep 2012 12:54:17 -0700 (PDT) Received: from mail123-co1-R.bigfish.com (10.243.78.252) by CO1EHSOBE006.bigfish.com (10.243.66.69) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Sep 2012 19:54:14 +0000 Received: from mail123-co1 (localhost [127.0.0.1]) by mail123-co1-R.bigfish.com (Postfix) with ESMTP id C331C20010F; Thu, 13 Sep 2012 19:54:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.168; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT05.osuad.osu.edu; RD:cio-tnc-ht05.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202h1d1ah1d2ahzz8275dhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1288h12a5h12a9h12bdh1315h1151h1155h) Received-SPF: pass (mail123-co1: domain of osu.edu designates 164.107.81.168 as permitted sender) client-ip=164.107.81.168; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT05.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail123-co1 (localhost.localdomain [127.0.0.1]) by mail123-co1 (MessageSwitch) id 134756605359522_9473; Thu, 13 Sep 2012 19:54:13 +0000 (UTC) Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.245]) by mail123-co1.bigfish.com (Postfix) with ESMTP id 0806F600103; Thu, 13 Sep 2012 19:54:13 +0000 (UTC) Received: from CIO-TNC-HT05.osuad.osu.edu (164.107.81.168) by CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Sep 2012 19:54:10 +0000 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; Thu, 13 Sep 2012 15:54:06 -0400 From: "Cantor, Scott" To: Simon Josefsson , William Mills Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.txt Thread-Index: AQHNkeg7xiZsm7y+i0abrRgWqxMQQpeIrzoA Date: Thu, 13 Sep 2012 19:54:05 +0000 Message-ID: In-Reply-To: <87d31pr9lb.fsf@latte.josefsson.org> 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-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.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, 13 Sep 2012 19:54:18 -0000 On 9/13/12 3:44 PM, "Simon Josefsson" wrote: > >> identity securely established for the client with the OAuth >> credential. > >Works for me, although Hannes indicated that "identity" is the wrong >term and "client identifier" would be more correct. Hannes can correct me, but I thought (from memory) the client identifier term referred not to the identity of the user as contained in the OAuth token but to the identity presenting the token to the resource service. In a user -> web site -> service flow, for example, I think you'd be identifying the web site as the identity instead of the user, which is not really the best one of the two to pick I wouldn't think. Or I'm just wrong about the term's meaning. -- Scott From simon@josefsson.org Thu Sep 13 13:11: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 AA4F421F859E for ; Thu, 13 Sep 2012 13:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.747 X-Spam-Level: X-Spam-Status: No, score=-99.747 tagged_above=-999 required=5 tests=[AWL=0.162, 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 aKdOsuplqG91 for ; Thu, 13 Sep 2012 13:11:26 -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 CE69E21F8595 for ; Thu, 13 Sep 2012 13:11:25 -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 q8DKBGEV022165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Sep 2012 22:11:18 +0200 From: Simon Josefsson To: "Cantor\, Scott" References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120913:cantor.2@osu.edu::fVKB6MzuYHFdSZ4V:0AeP X-Hashcash: 1:22:120913:kitten@ietf.org::jOMcN5oFVpPo+/V/:3Yos X-Hashcash: 1:22:120913:wmills@yahoo-inc.com::5DKZTX7yr/DP3fzD:LEGb Date: Thu, 13 Sep 2012 22:11:16 +0200 In-Reply-To: (Scott Cantor's message of "Thu, 13 Sep 2012 19:54:05 +0000") Message-ID: <87zk4tptsr.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] I-D Action: draft-ietf-kitten-sasl-oauth-07.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, 13 Sep 2012 20:11:26 -0000 "Cantor, Scott" writes: > On 9/13/12 3:44 PM, "Simon Josefsson" wrote: >> >>> identity securely established for the client with the OAuth >>> credential. >> >>Works for me, although Hannes indicated that "identity" is the wrong >>term and "client identifier" would be more correct. > > Hannes can correct me, but I thought (from memory) the client identifier > term referred not to the identity of the user as contained in the OAuth > token but to the identity presenting the token to the resource service. Right. Sorry, that's clearly not what I intended and I must have misunderstood Hannes. I'm fine with "identity". Possibly "resource owner's identity" is more exact. > In a user -> web site -> service flow, for example, I think you'd be > identifying the web site as the identity instead of the user, which is not > really the best one of the two to pick I wouldn't think. Agreed. /Simon From cantor.2@osu.edu Thu Sep 13 13: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 C9F4421F859E for ; Thu, 13 Sep 2012 13:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.766 X-Spam-Level: X-Spam-Status: No, score=-3.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 44uT8VP7vxjj for ; Thu, 13 Sep 2012 13:14:42 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 193B021F8595 for ; Thu, 13 Sep 2012 13:14:42 -0700 (PDT) Received: from mail144-co1-R.bigfish.com (10.243.78.253) by CO1EHSOBE009.bigfish.com (10.243.66.72) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Sep 2012 20:14:41 +0000 Received: from mail144-co1 (localhost [127.0.0.1]) by mail144-co1-R.bigfish.com (Postfix) with ESMTP id BD335CA00E4; Thu, 13 Sep 2012 20:14:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.168; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT05.osuad.osu.edu; RD:cio-tnc-ht05.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202h1d1ah1d2ahzz8275dhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1288h12a5h12a9h12bdh1315h1155h1151h) Received-SPF: pass (mail144-co1: domain of osu.edu designates 164.107.81.168 as permitted sender) client-ip=164.107.81.168; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT05.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail144-co1 (localhost.localdomain [127.0.0.1]) by mail144-co1 (MessageSwitch) id 1347567280141301_15580; Thu, 13 Sep 2012 20:14:40 +0000 (UTC) Received: from CO1EHSMHS012.bigfish.com (unknown [10.243.78.251]) by mail144-co1.bigfish.com (Postfix) with ESMTP id 16B64C80049; Thu, 13 Sep 2012 20:14:40 +0000 (UTC) Received: from CIO-TNC-HT05.osuad.osu.edu (164.107.81.168) by CO1EHSMHS012.bigfish.com (10.243.66.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Sep 2012 20:14:38 +0000 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; Thu, 13 Sep 2012 16:14:29 -0400 From: "Cantor, Scott" To: Simon Josefsson Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.txt Thread-Index: AQHNkeg7xiZsm7y+i0abrRgWqxMQQpeIrzoAgAAFWqiAAABXAA== Date: Thu, 13 Sep 2012 20:14:29 +0000 Message-ID: In-Reply-To: <87zk4tptsr.fsf@latte.josefsson.org> 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-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.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, 13 Sep 2012 20:14:43 -0000 On 9/13/12 4:11 PM, "Simon Josefsson" wrote: >> >> Hannes can correct me, but I thought (from memory) the client identifier >> term referred not to the identity of the user as contained in the OAuth >> token but to the identity presenting the token to the resource service. > >Right. Sorry, that's clearly not what I intended and I must have >misunderstood Hannes. I'm fine with "identity". Possibly "resource >owner's identity" is more exact. I think so too, but I think Hannes did say he thought the client identifier should be used, so I was seeking clarification myself. Your term would be what I would expect. -- Scott From wmills@yahoo-inc.com Thu Sep 13 14:07: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 EF3C221F84F6 for ; Thu, 13 Sep 2012 14:07:47 -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.076, 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 3lcDjg6lc2sV for ; Thu, 13 Sep 2012 14:07:47 -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 1D97021F84F1 for ; Thu, 13 Sep 2012 14:07:46 -0700 (PDT) Received: from [98.139.52.194] by nm11.bullet.mail.ac4.yahoo.com with NNFMP; 13 Sep 2012 21:07:43 -0000 Received: from [98.139.52.173] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 13 Sep 2012 21:07:43 -0000 Received: from [127.0.0.1] by omp1056.mail.ac4.yahoo.com with NNFMP; 13 Sep 2012 21:07:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 183995.71472.bm@omp1056.mail.ac4.yahoo.com Received: (qmail 15461 invoked by uid 60001); 13 Sep 2012 21:07:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1347570462; bh=oE+0ccyRvbr0hzSWv+A+acI08ljsi5xF1GScKvwBruA=; 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=AccRY4/juVvDf7e2o/fEm6S56gz4Vpx7C26ooJfhd0x9h79DGVIIOtqOH0MMYMdM5zyDzj3hYnZp+BA2EERrElRrO4R3RParncEKscKA0rLH5clvOc3lx2P+zcQEKb+PNlHL+4a0TuHtyqU2C7Zvl4aXoR3p6h6+twklye0T0es= 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=JEavTGptcUvuEp0kw5yFHpPFGbuEwRqWi1pjYy6VszPUb7PFm8OqtDb4Ofs51Il0QZXxCyQ10kecsZ5IhgNNG9uWiI/kH51inaVevGESeopE31Q/ybb36wdPFaHzW4tteRD+p0rzAVgeN77KULGA9fUsnB9rux3S+3l5Er3XTKY=; X-YMail-OSG: zZQN6hgVM1kvYby3x02jJujPgR7PE_D9A1d7JtLGWqQ5L5l j3y4yqBIXm3IbqsIlyD4lm2hOd7tJqdpSbf0DPP2tZczJHZ0p0WKBxV8RBqQ PKemzjO7eStRtbG2JzcfKymqyCgRovL28BTmCzVzijr9PevHVFGl7UcdsV9S RHBRzGN46y9ZjnCQaysRCXs8psXnW44QvgT0S5bkq0LEjO5t11.M_PuFV6Rb MGClYkfWj_qg3dz1XzmdXUig.dW1ekiR3QrybDca5uPdrUxjTPWp4P0ljuWL oMky_CEEWiEs5G8zJBxpyoEDvjYGRLULYhhTL1BVgEZfbUX1DRWMcFnNl7hc CsjBVMb7ytB3hm9MXArlz8cx_Z2hmZTr3p07GM2xBXf83FH.hm_x9YYa1HHz VlbGtfHZE3UVfLKFBe_oJjMRt9kNXDOQJCsbYXT3SvI.3VK80x__nfrtNBxf 0YLA_sQ-- Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Thu, 13 Sep 2012 14:07:42 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <87zk4tptsr.fsf@latte.josefsson.org> Message-ID: <1347570462.86103.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Thu, 13 Sep 2012 14:07:42 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Simon Josefsson In-Reply-To: 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-07.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, 13 Sep 2012 21:07:48 -0000 So is this now:=0A=0A=A0=A0 The authenticated identity reported by the SASL= mechanism is the =0A=A0=A0 resource owner identity securely established fo= r the client with =0A=A0=A0 the OAuth credential.=0A=0A?=0A=0A=0A=0A=0A----= - Original Message -----=0A> From: "Cantor, Scott" =0A> T= o: Simon Josefsson =0A> Cc: William Mills ; "kitten@ietf.org" =0A> Sent: Thursday, Septemb= er 13, 2012 1:14 PM=0A> Subject: Re: [kitten] I-D Action: draft-ietf-kitten= -sasl-oauth-07.txt=0A> =0A> On 9/13/12 4:11 PM, "Simon Josefsson" =0A> wrote:=0A>>> =0A>>> Hannes can correct me, but I thought= (from memory) the client =0A> identifier=0A>>> term referred not to the i= dentity of the user as contained in the OAuth=0A>>> token but to the ident= ity presenting the token to the resource service.=0A>> =0A>> Right.=A0 Sorr= y, that's clearly not what I intended and I must have=0A>> misunderstood Ha= nnes.=A0 I'm fine with "identity".=A0 Possibly =0A> "resource=0A>> owner's = identity" is more exact.=0A> =0A> I think so too, but I think Hannes did sa= y he thought the client=0A> identifier should be used, so I was seeking cla= rification myself. Your=0A> term would be what I would expect.=0A> =0A> -- = Scott=0A> From stpeter@stpeter.im Thu Sep 13 14:25: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 9D1A421F8618 for ; Thu, 13 Sep 2012 14:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 aPJFusKVRWtD for ; Thu, 13 Sep 2012 14:25:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDCC21F860E for ; Thu, 13 Sep 2012 14:25:08 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9E17B40D96 for ; Thu, 13 Sep 2012 15:25:54 -0600 (MDT) Message-ID: <50524F33.5090003@stpeter.im> Date: Thu, 13 Sep 2012 15:25:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "kitten@ietf.org" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [kitten] changing "mapped to nothing" in SASLprep-bis 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, 13 Sep 2012 21:25:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear SASL experts, RFC 4013 states that certain Unicode code points that are commonly mapped to nothing (see Appendix B.1 of RFC 3454) can indeed be so mapped when preparing passwords (and usernames) in SASLprep. In working on draft-melnikov-precis-saslprepbis (which is intended to obsolete RFC 4013), Alexey Melnikov and I have followed the general approach of the PRECIS framework (and before that IDNA2008) by specifying that such code points would simply be disallowed. In Unicode 3.2 there are only 27 code points that are affected by this rule (e.g., U+00AD = SOFT HYPHEN), and since currently they are mapped to nothing they would not be stored in an authentication database. However, users might have included such characters in their usernames or passwords and thus might expect to input those characters when providing usernames or passwords for authentication purposes. Therefore, if we change these code points from "mapped to nothing" to disallowed, it is possible a small number users might experience an error when inputting these characters with updated versions of their software, instead of the smooth operation they experienced in the past. Alexey and I would like to solicit feedback on this issue from participants in the KITTEN WG and especially from those who have implemented and deployed software that uses SASLprep. Please send your feedback to the kitten@ietf.org list or directly to me and Alexey. Thanks! 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/ iEYEARECAAYFAlBSTzMACgkQNL8k5A2w/vzHdACfZ9Pg02SjR/5GdNL37RqEHq7s 6s8An3XkJ9RecPZVFAoiNoVHn9EjRvlw =h82m -----END PGP SIGNATURE----- From simon@josefsson.org Thu Sep 13 15:04: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 D1DCF21F867C for ; Thu, 13 Sep 2012 15:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.765 X-Spam-Level: X-Spam-Status: No, score=-99.765 tagged_above=-999 required=5 tests=[AWL=0.144, 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 4mgyahMAXzsv for ; Thu, 13 Sep 2012 15:04:48 -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 072BE21F867A for ; Thu, 13 Sep 2012 15:04:47 -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 q8DM4gbE028149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 14 Sep 2012 00:04:43 +0200 From: Simon Josefsson To: William Mills References: <87zk4tptsr.fsf@latte.josefsson.org> <1347570462.86103.YahooMailNeo@web31805.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120913:cantor.2@osu.edu::z2/z6d7gJzxti7xf:5a/q X-Hashcash: 1:22:120913:kitten@ietf.org::ezmKDHWVb63fzthw:QrHc X-Hashcash: 1:22:120913:wmills@yahoo-inc.com::AaHoeuexyyUf+/Vs:xU0T Date: Fri, 14 Sep 2012 00:04:41 +0200 In-Reply-To: <1347570462.86103.YahooMailNeo@web31805.mail.mud.yahoo.com> (William Mills's message of "Thu, 13 Sep 2012 14:07:42 -0700 (PDT)") Message-ID: <87fw6lpojq.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-07.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, 13 Sep 2012 22:04:48 -0000 William Mills writes: > So is this now: > >    The authenticated identity reported by the SASL mechanism is the >    resource owner identity securely established for the client with >    the OAuth credential. > > ? This works for me, thank you! /Simon > > > > ----- Original Message ----- >> From: "Cantor, Scott" >> To: Simon Josefsson >> Cc: William Mills ; "kitten@ietf.org" >> Sent: Thursday, September 13, 2012 1:14 PM >> Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.txt >> >> On 9/13/12 4:11 PM, "Simon Josefsson" >> wrote: >>>> >>>> Hannes can correct me, but I thought (from memory) the client >> identifier >>>> term referred not to the identity of the user as contained in the OAuth >>>> token but to the identity presenting the token to the resource service. >>> >>> Right.  Sorry, that's clearly not what I intended and I must have >>> misunderstood Hannes.  I'm fine with "identity".  Possibly >> "resource >>> owner's identity" is more exact. >> >> I think so too, but I think Hannes did say he thought the client >> identifier should be used, so I was seeking clarification myself. Your >> term would be what I would expect. >> >> -- Scott >> From ve7jtb@ve7jtb.com Thu Sep 13 15:31: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 3564921F869F for ; Thu, 13 Sep 2012 15:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 8VOTJ6ybaNcg for ; Thu, 13 Sep 2012 15:31:33 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 388E521F869A for ; Thu, 13 Sep 2012 15:31:33 -0700 (PDT) Received: by ggnh4 with SMTP id h4so839279ggn.31 for ; Thu, 13 Sep 2012 15:31:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=PpzO2nMwpxqZVVoN0dp9YfuuNccLD1DZDEuG5CpJPso=; b=FPjgfzaPanOhrTxamzAo38Q64JAW5tLyn37fodcBZR1h5adHG8wdFAl5sXVuk2PI4L K+FluVJaPhdUn2BX7Ac4qY46HoJ4EHksy9c72e4hl4SwM58slNcJEC59km646L0pk46g gMeOSKh5Afk31JGdHYNmMlx35/FyS3TjjFPZfIZH64bt+y5N3IYf42UiA9wQXozJBr6c br4ovFHE8l5mh9Vof4rXgTurjHNs2bcyE95LaT0d7YZVIAaiKQJeG47LyQeQ+RqAYje5 j/Jc5J0FYHXsGg6faNM/COcJRtnkrvO0ugKNWnGFPTI6FIHOmKw1swgJpT3XdMvyOq8W Nnrg== Received: by 10.236.144.194 with SMTP id n42mr807949yhj.98.1347575492587; Thu, 13 Sep 2012 15:31:32 -0700 (PDT) Received: from [192.168.1.211] (190-20-1-30.baf.movistar.cl. [190.20.1.30]) by mx.google.com with ESMTPS id x4sm43100363yhh.2.2012.09.13.15.31.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Sep 2012 15:31:30 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1E6DBCB0-786F-4DA2-8B07-6C1A65A3D57F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: Date: Thu, 13 Sep 2012 19:30:33 -0300 Message-Id: References: To: "Cantor, Scott" X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQkr7CNX4tbE4l7f5i/bUZsABduFN21oZmC1jRQXD9D3f0QoIfDNdltmOKeX5IHki/At5Bgd Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.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, 13 Sep 2012 22:31:34 -0000 --Apple-Mail=_1E6DBCB0-786F-4DA2-8B07-6C1A65A3D57F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The client identifier (client_id) is like a SAML entityID. The meta data = the Authorization server knows about the client is keyed to that = identifier. =20 Things like the registered redirect URI , client secret and client type = are keyed to it. It is in no way a identifier for the user. =20 OAuth 2 has no Identifier for the user, other than a parameter = (username) it can pass to the token endpoint as a form encoded parameter = in the "Resource Owner Password Grant" request. It is only used for that and otherwise OAuth has no notion of user = identity other than what might be implied by the access token in some = protocols. We extended OAuth in OpenID Connect to add a user_id to the response in = the id_token. Care needs to be taken in that just because you get a access token by = passing in a username and password to the token endpoint that is not a = guarantee that the username input is not a pseudonym or in any other way = useful. Information about the user is typically implicit in the access = token. =20 If I had to pass user info from the Authorization server to a protected = resource (IMAP via sasl) I would send a signed JWT with the user_id to = be used in the token. That may not be what you are looking for however. John B. On 2012-09-13, at 4:54 PM, "Cantor, Scott" wrote: > On 9/13/12 3:44 PM, "Simon Josefsson" wrote: >>=20 >>> identity securely established for the client with the OAuth >>> credential. >>=20 >> Works for me, although Hannes indicated that "identity" is the wrong >> term and "client identifier" would be more correct. >=20 > Hannes can correct me, but I thought (from memory) the client = identifier > term referred not to the identity of the user as contained in the = OAuth > token but to the identity presenting the token to the resource = service. >=20 > In a user -> web site -> service flow, for example, I think you'd be > identifying the web site as the identity instead of the user, which is = not > really the best one of the two to pick I wouldn't think. >=20 > Or I'm just wrong about the term's meaning. >=20 > -- Scott >=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --Apple-Mail=_1E6DBCB0-786F-4DA2-8B07-6C1A65A3D57F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkx MzIyMzA1M1owIwYJKoZIhvcNAQkEMRYEFFhzAV8pcS+A+6oTfo+U8wMxc7H0MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AA6m/3M5gq0rAQAgCZkd8jEd8f9SzwLVvMQoQVDcyhiHUowtXdBXeRc1LAKxDO8anQ5MYTz5hUUo 1CSF6lRPRiCyfGOga0mntWCdP/l3QG4LhOqJpMKrix/nm6/oh8Rm5ME5NvlG3SrrseY0XCAOvbsZ ghm9c0pgFlyuH9jcjTh89s2ZNkxOE57f61/6c+4/5VH6l4J4f37aSNei0fTxiAGEBm2WiAT3kA0L LP2vEKokgd9VhSCIFMI/BgWvEVGbJkuLVdptb3I1bGKu8OxBPhdZUi6tgajANXXWCURjXjwEvpAy POYAnBqozW0KOx34/dBAJF+gDBebmvlZsQDdpVEAAAAAAAA= --Apple-Mail=_1E6DBCB0-786F-4DA2-8B07-6C1A65A3D57F-- From simon@josefsson.org Thu Sep 13 15:34: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 3381C21F86A3 for ; Thu, 13 Sep 2012 15:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.779 X-Spam-Level: X-Spam-Status: No, score=-99.779 tagged_above=-999 required=5 tests=[AWL=0.130, 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 JEgsaw-1+xOr for ; Thu, 13 Sep 2012 15:34:04 -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 62CCA21F869F for ; Thu, 13 Sep 2012 15:34:04 -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 q8DMXwID029505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 14 Sep 2012 00:34:00 +0200 From: Simon Josefsson To: Peter Saint-Andre References: <50524F33.5090003__19414.4675777808$1347571524$gmane$org@stpeter.im> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120913:kitten@ietf.org::a4vimX8P50Ttczvg:4MEE X-Hashcash: 1:22:120913:stpeter@stpeter.im::P6h5e/ZFM5vYFIxu:Hz4v Date: Fri, 14 Sep 2012 00:33:58 +0200 In-Reply-To: <50524F33.5090003__19414.4675777808$1347571524$gmane$org@stpeter.im> (Peter Saint-Andre's message of "Thu, 13 Sep 2012 15:25:07 -0600") Message-ID: <877grxpn6x.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] changing "mapped to nothing" in SASLprep-bis 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, 13 Sep 2012 22:34:05 -0000 I believe we can live with that potential problem. I wouldn't characterise users' current SASLprep experiences as "smooth operation", so adding another potential source of problems will mean little considering the already long list of potential source of problems. /Simon Peter Saint-Andre writes: > Dear SASL experts, > > RFC 4013 states that certain Unicode code points that are commonly > mapped to nothing (see Appendix B.1 of RFC 3454) can indeed be so > mapped when preparing passwords (and usernames) in SASLprep. > > In working on draft-melnikov-precis-saslprepbis (which is intended to > obsolete RFC 4013), Alexey Melnikov and I have followed the general > approach of the PRECIS framework (and before that IDNA2008) by > specifying that such code points would simply be disallowed. In > Unicode 3.2 there are only 27 code points that are affected by this > rule (e.g., U+00AD = SOFT HYPHEN), and since currently they are mapped > to nothing they would not be stored in an authentication database. > However, users might have included such characters in their usernames > or passwords and thus might expect to input those characters when > providing usernames or passwords for authentication purposes. > Therefore, if we change these code points from "mapped to nothing" to > disallowed, it is possible a small number users might experience an > error when inputting these characters with updated versions of their > software, instead of the smooth operation they experienced in the past. > > Alexey and I would like to solicit feedback on this issue from > participants in the KITTEN WG and especially from those who have > implemented and deployed software that uses SASLprep. Please send your > feedback to the kitten@ietf.org list or directly to me and Alexey. > > Thanks! > > Peter From cantor.2@osu.edu Thu Sep 13 16: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 C8BA521F8643 for ; Thu, 13 Sep 2012 16:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 BNRFnn-3FlPV for ; Thu, 13 Sep 2012 16:32:53 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 49B1821F863C for ; Thu, 13 Sep 2012 16:32:53 -0700 (PDT) Received: from mail19-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Sep 2012 23:32:51 +0000 Received: from mail19-co1 (localhost [127.0.0.1]) by mail19-co1-R.bigfish.com (Postfix) with ESMTP id CEC777C0194; Thu, 13 Sep 2012 23:32:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.168; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT05.osuad.osu.edu; RD:cio-tnc-ht05.osuad.osu.edu; EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zzbb2dI98dI9371I1432Id6f1izz1202h1d1ah1d2ahzz8275bhz2fh87h2a8h668h839h944hd25he96hf0ah107ah1220h1288h12a5h12a9h12bdh1315h1155h1151h) Received-SPF: pass (mail19-co1: domain of osu.edu designates 164.107.81.168 as permitted sender) client-ip=164.107.81.168; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT05.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail19-co1 (localhost.localdomain [127.0.0.1]) by mail19-co1 (MessageSwitch) id 1347579169812483_17235; Thu, 13 Sep 2012 23:32:49 +0000 (UTC) Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.241]) by mail19-co1.bigfish.com (Postfix) with ESMTP id C2D4C680042; Thu, 13 Sep 2012 23:32:49 +0000 (UTC) Received: from CIO-TNC-HT05.osuad.osu.edu (164.107.81.168) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Sep 2012 23:32:49 +0000 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; Thu, 13 Sep 2012 19:32:49 -0400 From: "Cantor, Scott" To: John Bradley Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.txt Thread-Index: AQHNkeg7xiZsm7y+i0abrRgWqxMQQpeIrzoAgABuyoD//85FAA== Date: Thu, 13 Sep 2012 23:32:48 +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: <5759AB95BFDD734CA93763141BA1D7C9@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.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, 13 Sep 2012 23:32:53 -0000 On 9/13/12 6:30 PM, "John Bradley" wrote: >The client identifier (client_id) is like a SAML entityID. The meta data >the Authorization server knows about the client is keyed to that >identifier. =20 >Things like the registered redirect URI , client secret and client type >are keyed to it. > >It is in no way a identifier for the user. Right, thus my opinion about (not) using it as the SASL authcid. >OAuth 2 has no Identifier for the user, other than a parameter (username) >it can pass to the token endpoint as a form encoded parameter in the >"Resource Owner Password Grant" request. >It is only used for that and otherwise OAuth has no notion of user >identity other than what might be implied by the access token in some >protocols. Right, which is up to the SASL mech to deal with and turn into a user identity. >Care needs to be taken in that just because you get a access token by >passing in a username and password to the token endpoint that is not a >guarantee that the username input is not a pseudonym or in any other way >useful. Information about the user is typically implicit in the access >token. That would be up to the mech to address by mapping the token to the state associated with it on the server side. >If I had to pass user info from the Authorization server to a protected >resource (IMAP via sasl) I would send a signed JWT with the user_id to be >used in the token. > >That may not be what you are looking for however. As a generic framework, all of that is really beyond the scope of an OAuth mechanism to define. All it can do is make it clear that the mech is responsible in some way to get from the token to an identity. -- Scott From wmills@yahoo-inc.com Fri Sep 14 15:50: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 7D3F621F84F1 for ; Fri, 14 Sep 2012 15:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.528 X-Spam-Level: X-Spam-Status: No, score=-17.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 XmLwXVNV0VIE for ; Fri, 14 Sep 2012 15:50:16 -0700 (PDT) Received: from nm23.bullet.mail.ac4.yahoo.com (nm23.bullet.mail.ac4.yahoo.com [98.139.52.220]) by ietfa.amsl.com (Postfix) with SMTP id 8129621F84E2 for ; Fri, 14 Sep 2012 15:50:16 -0700 (PDT) Received: from [98.139.52.190] by nm23.bullet.mail.ac4.yahoo.com with NNFMP; 14 Sep 2012 22:50:11 -0000 Received: from [98.139.52.137] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 14 Sep 2012 22:50:11 -0000 Received: from [127.0.0.1] by omp1020.mail.ac4.yahoo.com with NNFMP; 14 Sep 2012 22:50:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 318879.66021.bm@omp1020.mail.ac4.yahoo.com Received: (qmail 53099 invoked by uid 60001); 14 Sep 2012 22:50:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1347663010; bh=Im45zCwn8kdzkIzpolCuthmNi1VU2zuz9JRrpF4Aa3Y=; 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=MAMXkcSYC8+t/RiQ+j3Fdl8TgLDe1bAXqfTEf3jw5fKTGx5Fu/kSP4imxWdUp1MT/cFMCjlGjU1feVS2lwlhZW9hTnLUDEOfW0y0COthtIJdSxNERdt+WGIDnYmqpwj7JwnSetSpxUAZsYHY2zyGWL482YNzyiiygPgNWXu70Hw= 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=GSifJRRqtQR3tnB0LBSPVOuxQzW8Em8Z12ryTAlgHAF9/kCKEup6ZrB65BPn2k5QcbdAMyaE+jig2kRslB66BHNXIx/n+saiz+ppjsRJlcUon3xUZPPeXeGyl2yECK6GhgE1VqvKIT6raRdeYTs+ABgUV0lhzKhBMrTNjCKD5hk=; X-YMail-OSG: JW7tDpEVM1kHLqlXbInfbPWLGN51QFhE1an2X_3X6qsFYLE 0gBWQ3bmPJOv8PFniSMYrQzcQHaIV.LnGyIl5g_212daVND1S5CcSNPJ1r3w zwQ2meYwd2o63gALi_R8824jfBllg6lOo4CTIxVApj_aas9Qv.ovVQ6XpAMa kFzAoxXS5QaQdia.JnKnfRd23hsb8QvAA0LDo4TkZhS9h2iTeIywtY_5vAQd arXDS6ltXnCCQQlYWyD1EBaOl2mbTqratY2yK1bvj5VMvbTT7JJ19zUuqzAz pT8Pn0YyKuBuzEA5jeuRsMxsqndKCaaK3L6O0.BSQleZ_JRw2PZizZnlUhgS QD3owvdBcJNVPqcioNnmR2fJgM5sWL3nQ.i55n1LR4g.pFOwX0iDeHazZ1wH epHBikktlsiXyXvGs.LO91LSRhuiE36KIsOVzYsZIEGrDEOJApihSERxcQjV qus0CUjaPhcg- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Fri, 14 Sep 2012 15:50:10 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <20120913064111.30988.73947.idtracker__13304.7408344739$1347518481$gmane$org@ietfa.amsl.com> <87ehm6qtrj.fsf@latte.josefsson.org> <1347550295.73931.YahooMailNeo@web31807.mail.mud.yahoo.com> <87d31pr9lb.fsf@latte.josefsson.org> Message-ID: <1347663010.52373.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Fri, 14 Sep 2012 15:50:10 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <87d31pr9lb.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] Updated text Re: I-D Action: draft-ietf-kitten-sasl-oauth-07.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: Fri, 14 Sep 2012 22:50:17 -0000 OK, I've changed the main paragraphs in question a bit and renamed 3.2.1=A0= the new text is: =0A=0A=0A=0A=A0=A0=A0 The server responds to a successful= ly verified client message by completing =0A=0A=A0=A0=A0 the SASL negotiati= on. The authenticated identity reported by the SASL mechanism =0A=0A=A0=A0= =A0 is the resource owner identity securely established for the client with= the =0A=0A=A0=A0=A0 OAuth credential. The application, not the SASL mechan= ism, based on local access =0A=0A=A0=A0=A0 policy determines whether the id= entity reported by the mechanism is allowed =0A=0A=A0=A0=A0 access to the r= equested resource. Note that the semantics of the authz-id is =0A=0A=A0=A0= =A0 specified by the SASL framework=A0[RFC4422].=0A=0A=A0=A0=A0 3.2.1.=A0OA= uth Identities in the SASL Context=0A=0A=A0=A0=A0 Some OAuth schemes can ca= rry both a resource owner identity and a "proxy" =0A=0A=A0=A0=A0 identity, = for example an OAuth 1.0a=A0[RFC5849]=A0mechanism where the consumer key = =0A=0A=A0=A0=A0 (oauth_consumer_key) identifies the entity using the token = and the token itself =0A=0A=A0=A0=A0 identifies the user. If both identitie= s are needed by an application the =0A=0A=A0=A0=A0 developer will need to p= rovide a way to communicate that from the SASL mechanism =0A=0A=A0=A0=A0 ba= ck to the application such as a GSS-API=A0[RFC2473]=A0named type like =0A= =0A=A0=A0=A0 GSS_C_NT_USER_NAME or a comparable newly defined GSS-API name = type or name =0A=0A=A0=A0=A0 attribute=A0[RFC6680].=0A=0A=0Aand I fixed the= channel binding to include the cbtype.=0A=0A-bill=0A=0A>__________________= ______________=0A> From: Simon Josefsson =0A>To: Willi= am Mills =0A>Cc: "kitten@ietf.org" = =0A>Sent: Thursday, September 13, 2012 12:44 PM=0A>Subject: Re: [kitten] I= -D Action: draft-ietf-kitten-sasl-oauth-07.txt=0A> =0A>William Mills writes:=0A>=0A>> comment inline...=A0 Thanks for the readi= ng.=0A>>=0A>>=0A>>>________________________________=0A>>> From: Simon Josef= sson =0A>>>To: kitten@ietf.org =0A>>>Sent: Thursday, S= eptember 13, 2012 12:14 AM=0A>>>Subject: Re: [kitten] I-D Action: draft-iet= f-kitten-sasl-oauth-07.txt=0A>>> =0A>>>Thanks for update,=0A>>>=0A>>>Quick = review of the text that have changed since -07 below.=0A>>>=0A>>>Section 3.= 2:=0A>>>=0A>>>=A0=A0=A0The authenticated identity reported=0A>>>=A0=A0=A0by= the mechanism is the identity which the mechanism has securely=0A>>>=A0=A0= =A0established for the client with the OAuth credential.=0A>>>=0A>>>This co= nfuses me, I believe the two uses of the word 'mechanism' refer=0A>>>to dif= ferent things.=A0 Should it be:=0A>>>=0A>>>=A0=A0=A0The authenticated ident= ity reported by the SASL mechanism shall be=0A>>>=A0=A0=A0the identity whic= h the OAuth mechanism has securely established for=0A>>>=A0=A0=A0the client= with the OAuth credential.=0A>>>=0A>>>?=0A>>=0A>> Not my language here, bu= t your language doesn't do it for me.=A0 How about=0A>>=0A>> =A0=A0 The aut= henticated identity reported by the mechanism is the user =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 ^^^^^^^^^=0A>=0A>Is this the SASL mechanism?=0A>=0A>> =A0=A0 ident= ity securely established for the client with the OAuth=0A>> credential.=0A>= =0A>Works for me, although Hannes indicated that "identity" is the wrong=0A= >term and "client identifier" would be more correct.=0A>=0A>>>I'm still not= sure this is unambigious since OAuth may establish two=0A>>>identities, of= the user and the proxy.=A0 I suspect "the identity" could=0A>>>be qualifie= d to be the user (and OAuth 1.x and 2.x uses different terms=0A>>>here if I= recall correctly).=0A>>>=0A>>>Section 3.2.1:=0A>>>=0A>>>=A0=A0=A0Note that= the semantics of the authz-id are specified by the SASL=0A>>>=A0=A0=A0fram= ework [RFC4422].=A0 A SASL application is, of course, free to apply=0A>>>= =A0=A0=A0mappings of the OAuth authcid to authz-ids as per-SASL, and it is= =0A>>>=A0=A0=A0free to apply mappings common to non-SASL OAuth applications= .=0A>>>=0A>>>The first sentence is great, but the term 'authz-id' should be= =0A>>>explained.=0A>>>=0A>>>The second sentence is confusing.=A0 First, the= re is no such thing as a=0A>>>per-SASL authcid to authzid mapping: those ma= ppings are by definition=0A>>>always mechanism dependent, since the authcid= form is mechanism=0A>>>dependent.=A0 Second, "authz-id" refer to the autho= rization identity=0A>>>field, which can be empty, so what you want to map t= o is not the=0A>>>authz-id but the general concept of the identity to act a= s.=0A>>>=0A>>=0A>> Not my language, please propose text.=0A>=0A>I did propo= se text further down in my reply:=0A>=0A>=A0=A0=A0Note that the semantics o= f the authorization identity is specified by=0A>=A0=A0=A0the SASL framework= [RFC4422].=0A>=0A>And drop the second sentence.=0A>=0A>>>I encourage you t= o re-read this part from RFC 4422:=0A>>>=0A>>>=A0=A0=A0The client provides = its credentials (which include or imply an=0A>>>=A0=A0=A0authentication ide= ntity) and, optionally, a character string=0A>>>=A0=A0=A0representing the r= equested authorization identity as part of the SASL=0A>>>=A0=A0=A0exchange.= =A0 When this character string is omitted or empty, the client=0A>>>=A0=A0= =A0is requesting to act as the identity associated with the credentials=0A>= >>=A0=A0=A0(e.g., the user is requesting to act as the authentication ident= ity).=0A>>>=0A>>>So, I don't think your second sentence above adds any valu= e, at least=0A>>>the current text doesn't do it for me right now.=A0 I woul= d simply leave=0A>>>it as:=0A>>>=0A>>>=A0=A0=A0Note that the semantics of t= he authorization identity is specified by=0A>>>=A0=A0=A0the SASL framework = [RFC4422].=0A>>>=0A>>>You don't have to say anything further than that.=0A>= >>=0A>>>Section 3.2.1:=0A>>>=0A>>>=A0=A0=A0If both identities=0A>>>=A0=A0= =A0are needed by an application the developer will need to provide a way=0A= >>>=A0=A0=A0to communicate that from the SASL mechanism back to the applica= tion=0A>>>=A0=A0=A0such as a GS2 [RFC2473] named type like GSS_C_NT_USER_NA= ME or a=0A>>>=A0=A0=A0comparable newly defined GS2 attribute.=0A>>>=0A>>>RF= C 2743 (sic) is called GSS-API not GS2.=A0 The final "GS2 attribute"=0A>>>s= hould be "GSS-API name type or name attribute [RFC 6680]".=0A>>=0A>> fixed,= thank you=0A>>=0A>>>=0A>>>Section 5.2:=0A>>>=0A>>>=A0=A0=A0p,a=3Duser@exam= ple.com^A=0A>>>=0A>>>This is wrong, you changed 'y' to 'p' which doesn't co= nform to the ABNF.=0A>>>Please see my review comment of -06 on this.=0A>>= =0A>> I'll change it back, I changed it by request.=0A>=0A>Huh?=A0 Please r= ead my review comment of -06.=A0 The 'y' was even more=0A>incorrect.=A0 You= want 'p', but you must follow the ABNF and describe the=0A>cbtype.=A0 It c= ould be:=0A>=0A>p=3Dtls-unique,a=3Duser@example.com=0A>=0A>but it depends o= n what you want.=0A>=0A>/Simon=0A>=0A>=0A> From ve7jtb@ve7jtb.com Sat Sep 15 06:52: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 DA6E421F8475 for ; Sat, 15 Sep 2012 06:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 0PqwCcZC-O8f for ; Sat, 15 Sep 2012 06:52:39 -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 AC5ED21F8472 for ; Sat, 15 Sep 2012 06:52:38 -0700 (PDT) Received: by qcac10 with SMTP id c10so4056022qca.31 for ; Sat, 15 Sep 2012 06:52:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Zx6xP0YzPZ7eqEw4wn+RmqWqU2cl3XGSN9zVlKjEhIo=; b=RqR0mutgE8tg9G5tuMHXt0TE5zYcTx3L/8dzpAfW2eON3zojeOWYYaFqzrDP9Q/oMq reVav5aB2BZjajTBJgSqdweRkC0EHi4d4v8pTLVqc06cVOkQiDZHRO7F4+UJZur4V4bE UgiCMwaYz+VLlwpUxxD765pZwPas4c+8+1msewhCqq5lXejPBOtG599fN4aqYDyblu8e 94Jdfjz522EDG98j6CoEWBMmGZh9b/5C/PDYUWw81EfpZztnyOT8qRW7HL2U1di/bWMb 4R7+NXGWCxkwni+rjsi8d2pQLFb34RCwMvQQHy5p695Kp6ICMh9SAv5OTdK5mDyN6Me1 B/nw== Received: by 10.224.179.7 with SMTP id bo7mr14496104qab.96.1347717158122; Sat, 15 Sep 2012 06:52:38 -0700 (PDT) Received: from [192.168.1.211] (190-20-20-63.baf.movistar.cl. [190.20.20.63]) by mx.google.com with ESMTPS id eh7sm6642390qab.13.2012.09.15.06.52.27 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Sep 2012 06:52:36 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_47E7C969-CCEA-408B-AEBD-2B51FD4A0C0F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: <1347663010.52373.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Sat, 15 Sep 2012 10:52:07 -0300 Message-Id: <8503B096-0713-4B0A-BB2E-E288B3C8CF3F@ve7jtb.com> References: <20120913064111.30988.73947.idtracker__13304.7408344739$1347518481$gmane$org@ietfa.amsl.com> <87ehm6qtrj.fsf@latte.josefsson.org> <1347550295.73931.YahooMailNeo@web31807.mail.mud.yahoo.com> <87d31pr9lb.fsf@latte.josefsson.org> <1347663010.52373.YahooMailNeo@web31808.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQlTjOiIrZQhAOoU+HzfjQHmajhWrQ7DfZNuPd9F8QT068MqzuNcf3/hlX+KgMYT3L6sEDNn Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Updated text Re: I-D Action: draft-ietf-kitten-sasl-oauth-07.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, 15 Sep 2012 13:52:40 -0000 --Apple-Mail=_47E7C969-CCEA-408B-AEBD-2B51FD4A0C0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I appreciate what thou are trying too get at. However the access_token doesn't identify the user itself. =20 It conveys a access permission for a specific client to a resource = owned by a user. The resource is the thing that may identify the user by inference OAuth. The oauth_consumer_key also doesn't necessarily identify a single = instance of a client, it may only be identifying a software client that = has many instances used by many different users. This may not be a meaning full distinction in the context of SASL, = however I have seen people create security holes by making unwarranted = assumptions about the semantics of those. John B. On 2012-09-14, at 7:50 PM, William Mills wrote: > OK, I've changed the main paragraphs in question a bit and renamed = 3.2.1 the new text is:=20 >=20 >=20 >=20 > The server responds to a successfully verified client message by = completing=20 >=20 > the SASL negotiation. The authenticated identity reported by the = SASL mechanism=20 >=20 > is the resource owner identity securely established for the client = with the=20 >=20 > OAuth credential. The application, not the SASL mechanism, based = on local access=20 >=20 > policy determines whether the identity reported by the mechanism = is allowed=20 >=20 > access to the requested resource. Note that the semantics of the = authz-id is=20 >=20 > specified by the SASL framework [RFC4422]. >=20 > 3.2.1. OAuth Identities in the SASL Context >=20 > Some OAuth schemes can carry both a resource owner identity and a = "proxy"=20 >=20 > identity, for example an OAuth 1.0a [RFC5849] mechanism where the = consumer key=20 >=20 > (oauth_consumer_key) identifies the entity using the token and the = token itself=20 >=20 > identifies the user. If both identities are needed by an = application the=20 >=20 > developer will need to provide a way to communicate that from the = SASL mechanism=20 >=20 > back to the application such as a GSS-API [RFC2473] named type = like=20 >=20 > GSS_C_NT_USER_NAME or a comparable newly defined GSS-API name type = or name=20 >=20 > attribute [RFC6680]. >=20 >=20 > and I fixed the channel binding to include the cbtype. >=20 > -bill >=20 >> ________________________________ >> From: Simon Josefsson >> To: William Mills =20 >> Cc: "kitten@ietf.org" =20 >> Sent: Thursday, September 13, 2012 12:44 PM >> Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.txt >>=20 >> William Mills writes: >>=20 >>> comment inline... Thanks for the reading. >>>=20 >>>=20 >>>> ________________________________ >>>> From: Simon Josefsson >>>> To: kitten@ietf.org=20 >>>> Sent: Thursday, September 13, 2012 12:14 AM >>>> Subject: Re: [kitten] I-D Action: = draft-ietf-kitten-sasl-oauth-07.txt >>>>=20 >>>> Thanks for update, >>>>=20 >>>> Quick review of the text that have changed since -07 below. >>>>=20 >>>> Section 3.2: >>>>=20 >>>> The authenticated identity reported >>>> by the mechanism is the identity which the mechanism has = securely >>>> established for the client with the OAuth credential. >>>>=20 >>>> This confuses me, I believe the two uses of the word 'mechanism' = refer >>>> to different things. Should it be: >>>>=20 >>>> The authenticated identity reported by the SASL mechanism shall = be >>>> the identity which the OAuth mechanism has securely established = for >>>> the client with the OAuth credential. >>>>=20 >>>> ? >>>=20 >>> Not my language here, but your language doesn't do it for me. How = about >>>=20 >>> The authenticated identity reported by the mechanism is the user=20= >> ^^^^^^^^^ >>=20 >> Is this the SASL mechanism? >>=20 >>> identity securely established for the client with the OAuth >>> credential. >>=20 >> Works for me, although Hannes indicated that "identity" is the wrong >> term and "client identifier" would be more correct. >>=20 >>>> I'm still not sure this is unambigious since OAuth may establish = two >>>> identities, of the user and the proxy. I suspect "the identity" = could >>>> be qualified to be the user (and OAuth 1.x and 2.x uses different = terms >>>> here if I recall correctly). >>>>=20 >>>> Section 3.2.1: >>>>=20 >>>> Note that the semantics of the authz-id are specified by the = SASL >>>> framework [RFC4422]. A SASL application is, of course, free to = apply >>>> mappings of the OAuth authcid to authz-ids as per-SASL, and it = is >>>> free to apply mappings common to non-SASL OAuth applications. >>>>=20 >>>> The first sentence is great, but the term 'authz-id' should be >>>> explained. >>>>=20 >>>> The second sentence is confusing. First, there is no such thing as = a >>>> per-SASL authcid to authzid mapping: those mappings are by = definition >>>> always mechanism dependent, since the authcid form is mechanism >>>> dependent. Second, "authz-id" refer to the authorization identity >>>> field, which can be empty, so what you want to map to is not the >>>> authz-id but the general concept of the identity to act as. >>>>=20 >>>=20 >>> Not my language, please propose text. >>=20 >> I did propose text further down in my reply: >>=20 >> Note that the semantics of the authorization identity is specified = by >> the SASL framework [RFC4422]. >>=20 >> And drop the second sentence. >>=20 >>>> I encourage you to re-read this part from RFC 4422: >>>>=20 >>>> 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). >>>>=20 >>>> So, I don't think your second sentence above adds any value, at = least >>>> the current text doesn't do it for me right now. I would simply = leave >>>> it as: >>>>=20 >>>> Note that the semantics of the authorization identity is = specified by >>>> the SASL framework [RFC4422]. >>>>=20 >>>> You don't have to say anything further than that. >>>>=20 >>>> Section 3.2.1: >>>>=20 >>>> If both identities >>>> are needed by an application the developer will need to provide = a way >>>> to communicate that from the SASL mechanism back to the = application >>>> such as a GS2 [RFC2473] named type like GSS_C_NT_USER_NAME or a >>>> comparable newly defined GS2 attribute. >>>>=20 >>>> RFC 2743 (sic) is called GSS-API not GS2. The final "GS2 = attribute" >>>> should be "GSS-API name type or name attribute [RFC 6680]". >>>=20 >>> fixed, thank you >>>=20 >>>>=20 >>>> Section 5.2: >>>>=20 >>>> p,a=3Duser@example.com^A >>>>=20 >>>> This is wrong, you changed 'y' to 'p' which doesn't conform to the = ABNF. >>>> Please see my review comment of -06 on this. >>>=20 >>> I'll change it back, I changed it by request. >>=20 >> Huh? Please read my review comment of -06. The 'y' was even more >> incorrect. You want 'p', but you must follow the ABNF and describe = the >> cbtype. It could be: >>=20 >> p=3Dtls-unique,a=3Duser@example.com >>=20 >> but it depends on what you want. >>=20 >> /Simon >>=20 >>=20 >>=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --Apple-Mail=_47E7C969-CCEA-408B-AEBD-2B51FD4A0C0F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkx NTEzNTIxOFowIwYJKoZIhvcNAQkEMRYEFPDBspWD/wlL+5QGTxxcFmrXENS8MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AB/zFjLPcedRCiLEITvEnBTYLu8X0LgSBAHK5MCX0ADF94oa+ru34msLLnXoLRkHGA6qsSesipM6 RjUa8aBFvRiFAQOq3GaEM+L0C346zghbfHBc1wdaIIFckyxT30RJKagHNKkqd8LVHG7ZSLqbdbt2 ii/oKMyZkOqh8WoXdf7YZZZ/dNbU8Zwv3NoHVJzukYcseafNejVy0CwBAxw37XAffXP51QF/4gNI LP06H5ckbpksAwsrn4MSWz28CcC8epxSNxJGSJeXdylomhCL+qXSQkn+koEzk+r2GH09TWJMNLvZ WoX41c7umGMKMuzqJnx9JU+g+8g1H/AkQIC6BKwAAAAAAAA= --Apple-Mail=_47E7C969-CCEA-408B-AEBD-2B51FD4A0C0F-- From wmills@yahoo-inc.com Sat Sep 15 08: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 E2A2921F84F1 for ; Sat, 15 Sep 2012 08:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.466 X-Spam-Level: X-Spam-Status: No, score=-17.466 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_UNSUB18=0.131, 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 YLdvykAC6lpo for ; Sat, 15 Sep 2012 08:11:33 -0700 (PDT) Received: from nm38-vm6.bullet.mail.bf1.yahoo.com (nm38-vm6.bullet.mail.bf1.yahoo.com [72.30.239.22]) by ietfa.amsl.com (Postfix) with SMTP id A0B2C21F84D6 for ; Sat, 15 Sep 2012 08:11:32 -0700 (PDT) Received: from [98.139.212.146] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 15 Sep 2012 15:11:31 -0000 Received: from [98.139.212.192] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 15 Sep 2012 15:11:31 -0000 Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP; 15 Sep 2012 15:11:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 271992.45461.bm@omp1001.mail.bf1.yahoo.com Received: (qmail 5794 invoked by uid 60001); 15 Sep 2012 15:11:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1347721890; bh=xavOM9BE4XI7lzu2gQSsGksVNBFhAQ44ZjZ498tzpOs=; 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=YqgNKJPvxfHUWPX+fkzPbkbFUMPSJvwIpm/xhR1ywsMmvq13eSIP2MPqE1oKZSew8+NAcEqj7Iu/z/BZ1I9Hc2lx+keMIr/QXWaqFK38B7rp2aeIUEKZTrOsEUDXK9xS2v1LYDc2dg0gxbDXD/jZpMlNbnPSjUNQwEI/v/iPp8M= 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=MJOJZcFLlaK5+MIJMsVHL4XlkwfAog5ROYSmE0WEqUos49i1EAh+EfafgXliQYD36Zx3yJYk77QzFCPJVFG2o9c7uSlfHng+ipRk+2FaZMzfNrAFOASB6Q36B0fhYSthAs9f110r3ObqjPnGvFLPIdBVqNITKh29uP/8j6t0x60=; X-YMail-OSG: hHzeE_UVM1k7Zb_zxt6TIXyybjSNzChn.KRHS.t4HTusljy oSwu2QHn_O_ER5hmoXHA3xMQdQ1oODw1pCq.CB1KuvDCw2ybX9XzYj4CCwRy io6_fF_Pc_onl5IYETE8IIdEQeDs8hsyZ3XbPJ0qZDBySRfe3qEPGZNzjem0 idzYmi7aQAjhhBBhf7xJhBTxlpV8y2mpABoQJUtAhDaVm8vld8P_4HN.7d3F cDlaUXwS1KUM.VA45P_WyjICGQWqdMT7ztrmTx3tWKbn9PXFefBLXdyNHUmT F7xCZiGhr8ho2xNBD.uAnO882.mVsRcbeLFUlJXHoN5MFaW0Z8PwQPJ_r.HF l_IEJaGB9qXGVSYprW4Jr6E2w6Af2jRwbZAlbWRh1zcUS2lJAA6_SE99g9tP sdUAHB8saZsFKcW2pFsVMkX2yqdtB_U2m.78mm8N2zpZAOGQCK30J2eVuY9y 53_rcB8p1eQ-- Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Sat, 15 Sep 2012 08:11:30 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <20120913064111.30988.73947.idtracker__13304.7408344739$1347518481$gmane$org@ietfa.amsl.com> <87ehm6qtrj.fsf@latte.josefsson.org> <1347550295.73931.YahooMailNeo@web31807.mail.mud.yahoo.com> <87d31pr9lb.fsf@latte.josefsson.org> <1347663010.52373.YahooMailNeo@web31808.mail.mud.yahoo.com> <8503B096-0713-4B0A-BB2E-E288B3C8CF3F@ve7jtb.com> Message-ID: <1347721890.2250.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Sat, 15 Sep 2012 08:11:30 -0700 (PDT) From: William Mills To: John Bradley In-Reply-To: <8503B096-0713-4B0A-BB2E-E288B3C8CF3F@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-2083480089-1347721890=:2250" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Updated text Re: I-D Action: draft-ietf-kitten-sasl-oauth-07.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, 15 Sep 2012 15:11:38 -0000 ---551393103-2083480089-1347721890=:2250 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable What the token identifies may indeed be implementation dependent.=A0 I'll s= trike "resource owner", which leaves it up to the app to understand what th= e id is and how to use it.=0A=0AYep, the client ID might be the equivalent = of a user agent string.=A0 It's up to the app to decide if it's interesting= , I thought that was adequatley captured by "If both identities are needed = by an application ...", no?=0A=0ARegards,=0A=0A-bill=0A=0A=0A=0A=0A=0A>____= ____________________________=0A> From: John Bradley =0A>= To: William Mills =0A>Cc: Simon Josefsson ; "kitten@ietf.org" =0A>Sent: Saturday, Septem= ber 15, 2012 6:52 AM=0A>Subject: Re: [kitten] Updated text Re: I-D Action: = draft-ietf-kitten-sasl-oauth-07.txt=0A> =0A>I appreciate what thou are tryi= ng too get at.=0A>=0A>However the access_token doesn't identify the user it= self.=A0 =0A>=0A>It conveys=A0 a access permission for a specific client to= a resource owned by a user.=0A>=0A>The resource is the thing that may iden= tify the user by inference OAuth.=0A>=0A>The oauth_consumer_key also doesn'= t necessarily identify a single instance of a client, it may only be identi= fying a software client that has many instances used by many different user= s.=0A>=0A>This may not be a meaning full distinction in the context of SASL= , however I have seen people create security holes by making unwarranted as= sumptions about the semantics of those.=0A>=0A>John B.=0A>=0A>=0A>=0A>On 20= 12-09-14, at 7:50 PM, William Mills wrote:=0A>=0A>> = OK, I've changed the main paragraphs in question a bit and renamed 3.2.1=A0= the new text is: =0A>> =0A>> =0A>> =0A>>=A0 =A0 The server responds to a = successfully verified client message by completing =0A>> =0A>>=A0 =A0 the = SASL negotiation. The authenticated identity reported by the SASL mechanism= =0A>> =0A>>=A0 =A0 is the resource owner identity securely established fo= r the client with the =0A>> =0A>>=A0 =A0 OAuth credential. The application= , not the SASL mechanism, based on local access =0A>> =0A>>=A0 =A0 policy = determines whether the identity reported by the mechanism is allowed =0A>> = =0A>>=A0 =A0 access to the requested resource. Note that the semantics of = the authz-id is =0A>> =0A>>=A0 =A0 specified by the SASL framework [RFC442= 2].=0A>> =0A>>=A0 =A0 3.2.1. OAuth Identities in the SASL Context=0A>> =0A= >>=A0 =A0 Some OAuth schemes can carry both a resource owner identity and = a "proxy" =0A>> =0A>>=A0 =A0 identity, for example an OAuth 1.0a [RFC5849]= mechanism where the consumer key =0A>> =0A>>=A0 =A0 (oauth_consumer_key) = identifies the entity using the token and the token itself =0A>> =0A>>=A0 = =A0 identifies the user. If both identities are needed by an application t= he =0A>> =0A>>=A0 =A0 developer will need to provide a way to communicate = that from the SASL mechanism =0A>> =0A>>=A0 =A0 back to the application su= ch as a GSS-API [RFC2473] named type like =0A>> =0A>>=A0 =A0 GSS_C_NT_USER= _NAME or a comparable newly defined GSS-API name type or name =0A>> =0A>>= =A0 =A0 attribute [RFC6680].=0A>> =0A>> =0A>> and I fixed the channel bind= ing to include the cbtype.=0A>> =0A>> -bill=0A>> =0A>>> ___________________= _____________=0A>>> From: Simon Josefsson =0A>>> To: W= illiam Mills =0A>>> Cc: "kitten@ietf.org" =0A>>> Sent: Thursday, September 13, 2012 12:44 PM=0A>>> Subject: R= e: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.txt=0A>>> =0A>>> Wi= lliam Mills writes:=0A>>> =0A>>>> comment inline...= =A0 Thanks for the reading.=0A>>>> =0A>>>> =0A>>>>> _______________________= _________=0A>>>>> From: Simon Josefsson =0A>>>>> To: k= itten@ietf.org =0A>>>>> Sent: Thursday, September 13, 2012 12:14 AM=0A>>>>>= Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.txt=0A>>= >>> =0A>>>>> Thanks for update,=0A>>>>> =0A>>>>> Quick review of the text t= hat have changed since -07 below.=0A>>>>> =0A>>>>> Section 3.2:=0A>>>>> =0A= >>>>>=A0 =A0 The authenticated identity reported=0A>>>>>=A0 =A0 by the mech= anism is the identity which the mechanism has securely=0A>>>>>=A0 =A0 estab= lished for the client with the OAuth credential.=0A>>>>> =0A>>>>> This conf= uses me, I believe the two uses of the word 'mechanism' refer=0A>>>>> to di= fferent things.=A0 Should it be:=0A>>>>> =0A>>>>>=A0 =A0 The authenticated = identity reported by the SASL mechanism shall be=0A>>>>>=A0 =A0 the identit= y which the OAuth mechanism has securely established for=0A>>>>>=A0 =A0 the= client with the OAuth credential.=0A>>>>> =0A>>>>> ?=0A>>>> =0A>>>> Not my= language here, but your language doesn't do it for me.=A0 How about=0A>>>>= =0A>>>>=A0 =A0 The authenticated identity reported by the mechanism is the= user =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 ^^^^^^^^^=0A>>> =0A>>> Is this the SASL m= echanism?=0A>>> =0A>>>>=A0 =A0 identity securely established for the client= with the OAuth=0A>>>> credential.=0A>>> =0A>>> Works for me, although Hann= es indicated that "identity" is the wrong=0A>>> term and "client identifier= " would be more correct.=0A>>> =0A>>>>> I'm still not sure this is unambigi= ous since OAuth may establish two=0A>>>>> identities, of the user and the p= roxy.=A0 I suspect "the identity" could=0A>>>>> be qualified to be the user= (and OAuth 1.x and 2.x uses different terms=0A>>>>> here if I recall corre= ctly).=0A>>>>> =0A>>>>> Section 3.2.1:=0A>>>>> =0A>>>>>=A0 =A0 Note that th= e semantics of the authz-id are specified by the SASL=0A>>>>>=A0 =A0 framew= ork [RFC4422].=A0 A SASL application is, of course, free to apply=0A>>>>>= =A0 =A0 mappings of the OAuth authcid to authz-ids as per-SASL, and it is= =0A>>>>>=A0 =A0 free to apply mappings common to non-SASL OAuth application= s.=0A>>>>> =0A>>>>> The first sentence is great, but the term 'authz-id' sh= ould be=0A>>>>> explained.=0A>>>>> =0A>>>>> The second sentence is confusin= g.=A0 First, there is no such thing as a=0A>>>>> per-SASL authcid to authzi= d mapping: those mappings are by definition=0A>>>>> always mechanism depend= ent, since the authcid form is mechanism=0A>>>>> dependent.=A0 Second, "aut= hz-id" refer to the authorization identity=0A>>>>> field, which can be empt= y, so what you want to map to is not the=0A>>>>> authz-id but the general c= oncept of the identity to act as.=0A>>>>> =0A>>>> =0A>>>> Not my language, = please propose text.=0A>>> =0A>>> I did propose text further down in my rep= ly:=0A>>> =0A>>>=A0 =A0 Note that the semantics of the authorization identi= ty is specified by=0A>>>=A0 =A0 the SASL framework [RFC4422].=0A>>> =0A>>> = And drop the second sentence.=0A>>> =0A>>>>> I encourage you to re-read thi= s part from RFC 4422:=0A>>>>> =0A>>>>>=A0 =A0 The client provides its crede= ntials (which include or imply an=0A>>>>>=A0 =A0 authentication identity) a= nd, optionally, a character string=0A>>>>>=A0 =A0 representing the requeste= d authorization identity as part of the SASL=0A>>>>>=A0 =A0 exchange.=A0 Wh= en this character string is omitted or empty, the client=0A>>>>>=A0 =A0 is = requesting to act as the identity associated with the credentials=0A>>>>>= =A0 =A0 (e.g., the user is requesting to act as the authentication identity= ).=0A>>>>> =0A>>>>> So, I don't think your second sentence above adds any v= alue, at least=0A>>>>> the current text doesn't do it for me right now.=A0 = I would simply leave=0A>>>>> it as:=0A>>>>> =0A>>>>>=A0 =A0 Note that the s= emantics of the authorization identity is specified by=0A>>>>>=A0 =A0 the S= ASL framework [RFC4422].=0A>>>>> =0A>>>>> You don't have to say anything fu= rther than that.=0A>>>>> =0A>>>>> Section 3.2.1:=0A>>>>> =0A>>>>>=A0 =A0 If= both identities=0A>>>>>=A0 =A0 are needed by an application the developer = will need to provide a way=0A>>>>>=A0 =A0 to communicate that from the SASL= mechanism back to the application=0A>>>>>=A0 =A0 such as a GS2 [RFC2473] n= amed type like GSS_C_NT_USER_NAME or a=0A>>>>>=A0 =A0 comparable newly defi= ned GS2 attribute.=0A>>>>> =0A>>>>> RFC 2743 (sic) is called GSS-API not GS= 2.=A0 The final "GS2 attribute"=0A>>>>> should be "GSS-API name type or nam= e attribute [RFC 6680]".=0A>>>> =0A>>>> fixed, thank you=0A>>>> =0A>>>>> = =0A>>>>> Section 5.2:=0A>>>>> =0A>>>>>=A0 =A0 p,a=3Duser@example.com^A=0A>>= >>> =0A>>>>> This is wrong, you changed 'y' to 'p' which doesn't conform to= the ABNF.=0A>>>>> Please see my review comment of -06 on this.=0A>>>> =0A>= >>> I'll change it back, I changed it by request.=0A>>> =0A>>> Huh?=A0 Plea= se read my review comment of -06.=A0 The 'y' was even more=0A>>> incorrect.= =A0 You want 'p', but you must follow the ABNF and describe the=0A>>> cbtyp= e.=A0 It could be:=0A>>> =0A>>> p=3Dtls-unique,a=3Duser@example.com=0A>>> = =0A>>> but it depends on what you want.=0A>>> =0A>>> /Simon=0A>>> =0A>>> = =0A>>> =0A>> _______________________________________________=0A>> Kitten ma= iling list=0A>> Kitten@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/= kitten=0A>=0A>=0A>=0A> ---551393103-2083480089-1347721890=:2250 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
What the = token identifies may indeed be implementation dependent.  I'll strike = "resource owner", which leaves it up to the app to understand what the id i= s and how to use it.

Yep, the client ID might be the equivalent of a= user agent string.  It's up to the app to decide if it's interesting,= I thought that was adequatley captured by "If both identities are needed b= y an application ...", no?

Regards,

-bill

<= /span>

From: John Br= adley <ve7jtb@ve7jtb.com>
T= o: William Mills <wmills@yahoo-inc.com>
Cc: Simon Josefsson <simon@josefsson.= org>; "kitten@ietf.org" <kitten@ietf.org>
Sent: Saturday, September 15, 2012 6:52 AM Subject: Re: [kitten] Up= dated text Re: I-D Action: draft-ietf-kitten-sasl-oauth-07.txt
 =

I appreciate what thou are trying too get at.

However the= access_token doesn't identify the user itself. 

It conveys&nb= sp; a access permission for a specific client to a resource owned by a user= .

The resource is the thing that may identify the user by inference = OAuth.

The oauth_consumer_key also doesn't necessarily identify a si= ngle instance of a client, it may only be identifying a software client that ha= s many instances used by many different users.

This may not be a mea= ning full distinction in the context of SASL, however I have seen people cr= eate security holes by making unwarranted assumptions about the semantics o= f those.

John B.



On 2012-09-14, at 7:50 PM, William M= ills <wmills@yahoo-inc.com> wrote:

> OK, I've chan= ged the main paragraphs in question a bit and renamed 3.2.1  the new t= ext is:
>
>
>
>    The server respon= ds to a successfully verified client message by completing
>
>= ;    the SASL negotiation. The authenticated identity reported b= y the SASL mechanism
>
>    is the resource owner = identity securely established for the client with the
>
>    OAuth credential. The application, not the SASL mec= hanism, based on local access
>
>    policy determ= ines whether the identity reported by the mechanism is allowed
> >    access to the requested resource. Note that the semanti= cs of the authz-id is
>
>    specified by the SASL= framework [RFC4422].
>
>    3.2.1. OAuth Identitie= s in the SASL Context
>
>    Some OAuth schemes can= carry both a resource owner identity and a "proxy"
>
> =   identity, for example an OAuth 1.0a [RFC5849] mechanism where the = consumer key
>
>    (oauth_consumer_key) identifie= s the entity using the token and the token itself
>
>  &= nbsp; identifies the user. If both identities are needed by an application= the
>
>    developer will need to provide a way to communicate that from the SASL mechanism
>
>  =   back to the application such as a GSS-API [RFC2473] named type like=
>
>    GSS_C_NT_USER_NAME or a comparable newly d= efined GSS-API name type or name
>
>    attribute = [RFC6680].
>
>
> and I fixed the channel binding to inc= lude the cbtype.
>
> -bill
>
>> ______________= __________________
>> From: Simon Josefsson <simon@josefsson= .org>
>> To: William Mills <wmills@yahoo-inc.com>
>> Cc: "kitten@ietf.org" <kitten@ietf.org>
>>= Sent: Thursday, September 13, 2012 12:44 PM
>> Subject: Re: [kitten] I-= D Action: draft-ietf-kitten-sasl-oauth-07.txt
>>
>> Will= iam Mills <wmills@yahoo-inc.com> writes:
>>
>= ;>> comment inline...  Thanks for the reading.
>>> <= br>>>>
>>>> ________________________________
&g= t;>>> From: Simon Josefsson <simon@josefsson.org>
= >>>> To: kitten@ietf.org
>>>> Sent: Thursday, Se= ptember 13, 2012 12:14 AM
>>>> Subject: Re: [kitten] I-D Act= ion: draft-ietf-kitten-sasl-oauth-07.txt
>>>>
>>&g= t;> Thanks for update,
>>>>
>>>> Quick re= view of the text that have changed since -07 below.
>>>>
>= ;>>> Section 3.2:
>>>>
>>>>  &= nbsp; The authenticated identity reported
>>>>    = by the mechanism is the identity which the mechanism has securely
>&g= t;>>    established for the client with the OAuth credentia= l.
>>>>
>>>> This confuses me, I believe the= two uses of the word 'mechanism' refer
>>>> to different th= ings.  Should it be:
>>>>
>>>>  &n= bsp; The authenticated identity reported by the SASL mechanism shall be
= >>>>    the identity which the OAuth mechanism has se= curely established for
>>>>    the client with the= OAuth credential.
>>>>
>>>> ?
>>&g= t;
>>> Not my language here, but your language doesn't do it for me.  How about
>>>
>>>   = ; The authenticated identity reported by the mechanism is the user
>= >                    &= nbsp;                    =       ^^^^^^^^^
>>
>> Is this the SASL = mechanism?
>>
>>>    identity securely esta= blished for the client with the OAuth
>>> credential.
>&g= t;
>> Works for me, although Hannes indicated that "identity" is = the wrong
>> term and "client identifier" would be more correct.>>
>>>> I'm still not sure this is unambigious sinc= e OAuth may establish two
>>>> identities, of the user and t= he proxy.  I suspect "the identity" could
>>>> be quali= fied to be the user (and OAuth 1.x and 2.x uses different terms
>>>> here if I recall correctly).
>>>>=
>>>> Section 3.2.1:
>>>>
>>>&g= t;    Note that the semantics of the authz-id are specified by th= e SASL
>>>>    framework [RFC4422].  A SASL a= pplication is, of course, free to apply
>>>>    ma= ppings of the OAuth authcid to authz-ids as per-SASL, and it is
>>= >>    free to apply mappings common to non-SASL OAuth appli= cations.
>>>>
>>>> The first sentence is gre= at, but the term 'authz-id' should be
>>>> explained.
>= ;>>>
>>>> The second sentence is confusing.  = First, there is no such thing as a
>>>> per-SASL authcid to = authzid mapping: those mappings are by definition
>>>> alway= s mechanism dependent, since the authcid form is mechanism
>>>> dependent.  Second, "authz-id" refer to= the authorization identity
>>>> field, which can be empty, = so what you want to map to is not the
>>>> authz-id but the = general concept of the identity to act as.
>>>>
>>= >
>>> Not my language, please propose text.
>> >> I did propose text further down in my reply:
>>
>= >    Note that the semantics of the authorization identity is = specified by
>>    the SASL framework [RFC4422].
>= >
>> And drop the second sentence.
>>
>>>= ;> I encourage you to re-read this part from RFC 4422:
>>>&g= t;
>>>>    The client provides its credentials (w= hich include or imply an
>>>>    authentication id= entity) and, optionally, a character string
>>>>    representing the requested authori= zation identity as part of the SASL
>>>>    exchan= ge.  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 re= questing to act as the authentication identity).
>>>>
&g= t;>>> So, I don't think your second sentence above adds any value,= at least
>>>> the current text doesn't do it for me right n= ow.  I would simply leave
>>>> it as:
>>>&g= t;
>>>>    Note that the semantics of the authori= zation identity is specified by
>>>>    the SASL f= ramework [RFC4422].
>>>>
>>>> You don't have= to say anything further than that.
>>>>
>>>> Section 3.2.1:
>>>>
>>>&g= t;    If both identities
>>>>    are nee= ded by an application the developer will need to provide a way
>>&= gt;>    to communicate that from the SASL mechanism back to th= e application
>>>>    such as a GS2 [RFC2473] name= d type like GSS_C_NT_USER_NAME or a
>>>>    compar= able newly defined GS2 attribute.
>>>>
>>>> = RFC 2743 (sic) is called GSS-API not GS2.  The final "GS2 attribute">>>> should be "GSS-API name type or name attribute [RFC 6680= ]".
>>>
>>> fixed, thank you
>>>
&= gt;>>>
>>>> Section 5.2:
>>>>
&= gt;>>>    p,a=3Duser@example.com^A
>>>>
>>>> This is wrong, you changed 'y' to 'p' which doesn't c= onform to the ABNF.
>>>> Please see my review comment of -06= on this.
>>>
>>> I'll change it back, I changed i= t by request.
>>
>> Huh?  Please read my review com= ment of -06.  The 'y' was even more
>> incorrect.  You w= ant 'p', but you must follow the ABNF and describe the
>> cbtype.&= nbsp; It could be:
>>
>> p=3Dtls-unique,a=3Duser@example.= com
>>
>> but it depends on what you want.
>&g= t;
>> /Simon
>>
>>
>>
> _____= __________________________________________
> Kitten mailing list
&= gt; K= itten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten

=

---551393103-2083480089-1347721890=:2250-- From ve7jtb@ve7jtb.com Sat Sep 15 10:24: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 EFE0C21F84F0 for ; Sat, 15 Sep 2012 10:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB18=0.131] 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 0UaSVEjTCS2a for ; Sat, 15 Sep 2012 10:24:29 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3468221F84D9 for ; Sat, 15 Sep 2012 10:24:28 -0700 (PDT) Received: by yhq56 with SMTP id 56so53978yhq.31 for ; Sat, 15 Sep 2012 10:24:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=RDFBr2HcPxzbJKEAmeoPju+vTN5RqqbvWB2KZxGN3Z4=; b=CZjw8Lcw+2dQMI0CAz8/EWvuxOS1HmqqTkUA5tDLWVFo+Rh0/dzdkh6AjYQF/+Nk5c AtK7GjZM15/PCgSBezDOw77KZv9ZPv0YXrv7NJc+6GVoXmicWyoBXJz2RpdJYVHtYMtV GkfKgye67atoZ/EiOq9oMubXohHmS+Zlwy8Eip21RkfMCuV6mWNp1SRIx3N57Pl/PJaj dLsNgaBCKWtWDbDCUU0lmZ5/GevcE3nitSW3azULmXNukSloC7K/LRWKUpe1DF5bBXWH 9dKUDsOKm2/L+wgC+vHKffuqhvmF7HeZm8bjLthNsRUGJ04uHBXepYc1OO911k/KWTss JS4A== Received: by 10.236.191.69 with SMTP id f45mr8084546yhn.8.1347729868552; Sat, 15 Sep 2012 10:24:28 -0700 (PDT) Received: from [192.168.1.211] (190-20-20-63.baf.movistar.cl. [190.20.20.63]) by mx.google.com with ESMTPS id i3sm4945655anl.0.2012.09.15.10.24.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Sep 2012 10:24:27 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4A4A1ED3-9974-4882-B63C-EBD087C2B09C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: <1347721890.2250.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Sat, 15 Sep 2012 14:24:13 -0300 Message-Id: References: <20120913064111.30988.73947.idtracker__13304.7408344739$1347518481$gmane$org@ietfa.amsl.com> <87ehm6qtrj.fsf@latte.josefsson.org> <1347550295.73931.YahooMailNeo@web31807.mail.mud.yahoo.com> <87d31pr9lb.fsf@latte.josefsson.org> <1347663010.52373.YahooMailNeo@web31808.mail.mud.yahoo.com> <8503B096-0713-4B0A-BB2E-E288B3C8CF3F@ve7jtb.com> <1347721890.2250.YahooMailNeo@web31805.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQmvmLKD+pA7QwOSlSb7vgDVLevGnqrN4sad9vkPBfog2FJFc2cfXznNs1E8DeFRg9oqZ5W3 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Updated text Re: I-D Action: draft-ietf-kitten-sasl-oauth-07.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, 15 Sep 2012 17:24:31 -0000 --Apple-Mail=_4A4A1ED3-9974-4882-B63C-EBD087C2B09C Content-Type: multipart/alternative; boundary="Apple-Mail=_DFD1239E-0155-40AD-B043-D709E0F162DA" --Apple-Mail=_DFD1239E-0155-40AD-B043-D709E0F162DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Unless it is a real confidential client, and not just one using the code = flow with a password that can be extracted, then client_id is a hint = about the client software and not much more meaningful than that. That hint is also something that is consumed by the Authorization server = not other things. In OAuth 2 at least the client_id is not explicitly passed to the = Resource server it is just the access_token in bearer or the MAC key = Identifier (id) . The oauth_consumer_key is passed to the resource = server in 1.0a though it should is not typically used for anything other = than calculating the signature. So you have two situations depending on if you are using OAuth 1 or 2. OAuth 1: The oauth_consumer_key might be trivially faked in the message = to the resource owner unless it is checked out of band. OAuth 2: The client_id is not sent as it is assumed that any meaningful = information about the client is in the access_token/id or retrieved out = of band by lookup. In OAuth 1 the protected resource could conceivably be set up to look up = the oauth_token_secret based on the combination of oauth_consumer_key = and oauth_token but that would be implementation specific. I think all you can really say is that what you send for = client_id/oauth_token_secret is a hint and might not be trust worthy and = needs to be confirmed by the resource out of band. In principal you just need oauth_consumer_key in OAuth 1 to verify the = signature. Though I suspect that at the end of the day the client and = protected resource communication over SASL are so different that the = OAuth 1.0a signature mechanism is only similar so you could drop it if = the oauth_token is globally scoped and not per client scoped. I think = that is probably OK though it is really the Authorization part that = needs to be compatible with the spec. John B. On 2012-09-15, at 12:11 PM, William Mills wrote: > What the token identifies may indeed be implementation dependent. = I'll strike "resource owner", which leaves it up to the app to = understand what the id is and how to use it. >=20 > Yep, the client ID might be the equivalent of a user agent string. = It's up to the app to decide if it's interesting, I thought that was = adequatley captured by "If both identities are needed by an application = ...", no? >=20 > Regards, >=20 > -bill >=20 >=20 > From: John Bradley > To: William Mills =20 > Cc: Simon Josefsson ; "kitten@ietf.org" = =20 > Sent: Saturday, September 15, 2012 6:52 AM > Subject: Re: [kitten] Updated text Re: I-D Action: = draft-ietf-kitten-sasl-oauth-07.txt >=20 > I appreciate what thou are trying too get at. >=20 > However the access_token doesn't identify the user itself. =20 >=20 > It conveys a access permission for a specific client to a resource = owned by a user. >=20 > The resource is the thing that may identify the user by inference = OAuth. >=20 > The oauth_consumer_key also doesn't necessarily identify a single = instance of a client, it may only be identifying a software client that = has many instances used by many different users. >=20 > This may not be a meaning full distinction in the context of SASL, = however I have seen people create security holes by making unwarranted = assumptions about the semantics of those. >=20 > John B. >=20 >=20 >=20 > On 2012-09-14, at 7:50 PM, William Mills wrote: >=20 > > OK, I've changed the main paragraphs in question a bit and renamed = 3.2.1 the new text is:=20 > >=20 > >=20 > >=20 > > The server responds to a successfully verified client message by = completing=20 > >=20 > > the SASL negotiation. The authenticated identity reported by the = SASL mechanism=20 > >=20 > > is the resource owner identity securely established for the = client with the=20 > >=20 > > OAuth credential. The application, not the SASL mechanism, based = on local access=20 > >=20 > > policy determines whether the identity reported by the mechanism = is allowed=20 > >=20 > > access to the requested resource. Note that the semantics of the = authz-id is=20 > >=20 > > specified by the SASL framework [RFC4422]. > >=20 > > 3.2.1. OAuth Identities in the SASL Context > >=20 > > Some OAuth schemes can carry both a resource owner identity and a = "proxy"=20 > >=20 > > identity, for example an OAuth 1.0a [RFC5849] mechanism where the = consumer key=20 > >=20 > > (oauth_consumer_key) identifies the entity using the token and = the token itself=20 > >=20 > > identifies the user. If both identities are needed by an = application the=20 > >=20 > > developer will need to provide a way to communicate that from the = SASL mechanism=20 > >=20 > > back to the application such as a GSS-API [RFC2473] named type = like=20 > >=20 > > GSS_C_NT_USER_NAME or a comparable newly defined GSS-API name = type or name=20 > >=20 > > attribute [RFC6680]. > >=20 > >=20 > > and I fixed the channel binding to include the cbtype. > >=20 > > -bill > >=20 > >> ________________________________ > >> From: Simon Josefsson > >> To: William Mills =20 > >> Cc: "kitten@ietf.org" =20 > >> Sent: Thursday, September 13, 2012 12:44 PM > >> Subject: Re: [kitten] I-D Action: = draft-ietf-kitten-sasl-oauth-07.txt > >>=20 > >> William Mills writes: > >>=20 > >>> comment inline... Thanks for the reading. > >>>=20 > >>>=20 > >>>> ________________________________ > >>>> From: Simon Josefsson > >>>> To: kitten@ietf.org=20 > >>>> Sent: Thursday, September 13, 2012 12:14 AM > >>>> Subject: Re: [kitten] I-D Action: = draft-ietf-kitten-sasl-oauth-07.txt > >>>>=20 > >>>> Thanks for update, > >>>>=20 > >>>> Quick review of the text that have changed since -07 below. > >>>>=20 > >>>> Section 3.2: > >>>>=20 > >>>> The authenticated identity reported > >>>> by the mechanism is the identity which the mechanism has = securely > >>>> established for the client with the OAuth credential. > >>>>=20 > >>>> This confuses me, I believe the two uses of the word 'mechanism' = refer > >>>> to different things. Should it be: > >>>>=20 > >>>> The authenticated identity reported by the SASL mechanism = shall be > >>>> the identity which the OAuth mechanism has securely = established for > >>>> the client with the OAuth credential. > >>>>=20 > >>>> ? > >>>=20 > >>> Not my language here, but your language doesn't do it for me. How = about > >>>=20 > >>> The authenticated identity reported by the mechanism is the = user=20 > >> ^^^^^^^^^ > >>=20 > >> Is this the SASL mechanism? > >>=20 > >>> identity securely established for the client with the OAuth > >>> credential. > >>=20 > >> Works for me, although Hannes indicated that "identity" is the = wrong > >> term and "client identifier" would be more correct. > >>=20 > >>>> I'm still not sure this is unambigious since OAuth may establish = two > >>>> identities, of the user and the proxy. I suspect "the identity" = could > >>>> be qualified to be the user (and OAuth 1.x and 2.x uses different = terms > >>>> here if I recall correctly). > >>>>=20 > >>>> Section 3.2.1: > >>>>=20 > >>>> Note that the semantics of the authz-id are specified by the = SASL > >>>> framework [RFC4422]. A SASL application is, of course, free = to apply > >>>> mappings of the OAuth authcid to authz-ids as per-SASL, and it = is > >>>> free to apply mappings common to non-SASL OAuth applications. > >>>>=20 > >>>> The first sentence is great, but the term 'authz-id' should be > >>>> explained. > >>>>=20 > >>>> The second sentence is confusing. First, there is no such thing = as a > >>>> per-SASL authcid to authzid mapping: those mappings are by = definition > >>>> always mechanism dependent, since the authcid form is mechanism > >>>> dependent. Second, "authz-id" refer to the authorization = identity > >>>> field, which can be empty, so what you want to map to is not the > >>>> authz-id but the general concept of the identity to act as. > >>>>=20 > >>>=20 > >>> Not my language, please propose text. > >>=20 > >> I did propose text further down in my reply: > >>=20 > >> Note that the semantics of the authorization identity is = specified by > >> the SASL framework [RFC4422]. > >>=20 > >> And drop the second sentence. > >>=20 > >>>> I encourage you to re-read this part from RFC 4422: > >>>>=20 > >>>> 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). > >>>>=20 > >>>> So, I don't think your second sentence above adds any value, at = least > >>>> the current text doesn't do it for me right now. I would simply = leave > >>>> it as: > >>>>=20 > >>>> Note that the semantics of the authorization identity is = specified by > >>>> the SASL framework [RFC4422]. > >>>>=20 > >>>> You don't have to say anything further than that. > >>>>=20 > >>>> Section 3.2.1: > >>>>=20 > >>>> If both identities > >>>> are needed by an application the developer will need to = provide a way > >>>> to communicate that from the SASL mechanism back to the = application > >>>> such as a GS2 [RFC2473] named type like GSS_C_NT_USER_NAME or = a > >>>> comparable newly defined GS2 attribute. > >>>>=20 > >>>> RFC 2743 (sic) is called GSS-API not GS2. The final "GS2 = attribute" > >>>> should be "GSS-API name type or name attribute [RFC 6680]". > >>>=20 > >>> fixed, thank you > >>>=20 > >>>>=20 > >>>> Section 5.2: > >>>>=20 > >>>> p,a=3Duser@example.com^A > >>>>=20 > >>>> This is wrong, you changed 'y' to 'p' which doesn't conform to = the ABNF. > >>>> Please see my review comment of -06 on this. > >>>=20 > >>> I'll change it back, I changed it by request. > >>=20 > >> Huh? Please read my review comment of -06. The 'y' was even more > >> incorrect. You want 'p', but you must follow the ABNF and describe = the > >> cbtype. It could be: > >>=20 > >> p=3Dtls-unique,a=3Duser@example.com > >>=20 > >> but it depends on what you want. > >>=20 > >> /Simon > >>=20 > >>=20 > >>=20 > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten >=20 >=20 >=20 --Apple-Mail=_DFD1239E-0155-40AD-B043-D709E0F162DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 wmills@yahoo-inc.com> = wrote:

What the token identifies may indeed be = implementation dependent.  I'll strike "resource owner", which = leaves it up to the app to understand what the id is and how to use = it.

Yep, the client ID might be the equivalent of a user agent = string.  It's up to the app to decide if it's interesting, I = thought that was adequatley captured by "If both identities are needed = by an application ...", = no?

Regards,

-bill


<= blockquote style=3D"border-left: 2px solid rgb(16, 16, 255); = margin-left: 5px; margin-top: 5px; padding-left: 5px;">
=
From: John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills@yahoo-inc.com> =
Cc: Simon Josefsson = <simon@josefsson.org>; = "kitten@ietf.org" <kitten@ietf.org>
Sent: Saturday, September 15, = 2012 6:52 AM
Subject: Re: [kitten] Updated text Re: I-D Action: = draft-ietf-kitten-sasl-oauth-07.txt

I appreciate = what thou are trying too get at.

However the access_token doesn't = identify the user itself. 

It conveys  a access = permission for a specific client to a resource owned by a = user.

The resource is the thing that may identify the user by = inference OAuth.

The oauth_consumer_key also doesn't necessarily = identify a single instance of a client, it may only be identifying a software client that = has many instances used by many different users.

This may not be = a meaning full distinction in the context of SASL, however I have seen = people create security holes by making unwarranted assumptions about the = semantics of those.

John B.



On 2012-09-14, at 7:50 = PM, William Mills <wmills@yahoo-inc.com> = wrote:

> OK, I've changed the main paragraphs in question a = bit and renamed 3.2.1  the new text is:
>
>
> =
>    The server responds to a successfully verified = client message by completing
>
>    the SASL = negotiation. The authenticated identity reported by the SASL mechanism =
>
>    is the resource owner identity securely = established for the client with the
>
>    OAuth credential. The application, not the SASL = mechanism, based on local access
>
>    policy = determines whether the identity reported by the mechanism is allowed =
>
>    access to the requested resource. Note = that the semantics of the authz-id is
>
>    = specified by the SASL framework [RFC4422].
>
>    = 3.2.1. OAuth Identities in the SASL Context
>
>  =   Some OAuth schemes can carry both a resource owner identity and = a "proxy"
>
>    identity, for example an OAuth = 1.0a [RFC5849] mechanism where the consumer key
>
>  =   (oauth_consumer_key) identifies the entity using the token and = the token itself
>
>    identifies the user. If = both identities are needed by an application the
>
>  =   developer will need to provide a way to communicate that from the SASL mechanism
> =
>    back to the application such as a GSS-API = [RFC2473] named type like
>
>    = GSS_C_NT_USER_NAME or a comparable newly defined GSS-API name type or = name
>
>    attribute [RFC6680].
> =
>
> and I fixed the channel binding to include the = cbtype.
>
> -bill
>
>> = ________________________________
>> From: Simon Josefsson = <simon@josefsson.org>
>>= ; To: William Mills <wmills@yahoo-inc.com> =
>> Cc: "kitten@ietf.org" <kitten@ietf.org>
>> = Sent: Thursday, September 13, 2012 12:44 PM
>> Subject: Re: [kitten] = I-D Action: draft-ietf-kitten-sasl-oauth-07.txt
>>
>> = William Mills <wmills@yahoo-inc.com> = writes:
>>
>>> comment inline...  Thanks for = the reading.
>>>
>>>
>>>> = ________________________________
>>>> From: Simon = Josefsson <simon@josefsson.org>
>>= ;>> To: kitten@ietf.org
>>>> = Sent: Thursday, September 13, 2012 12:14 AM
>>>> Subject: = Re: [kitten] I-D Action: = draft-ietf-kitten-sasl-oauth-07.txt
>>>> =
>>>> Thanks for update,
>>>> =
>>>> Quick review of the text that have changed since -07 below.
>>>> =
>>>> Section 3.2:
>>>> =
>>>>    The authenticated identity = reported
>>>>    by the mechanism is the = identity which the mechanism has securely
>>>>  =   established for the client with the OAuth = credential.
>>>>
>>>> This confuses me, I = believe the two uses of the word 'mechanism' refer
>>>> = to different things.  Should it be:
>>>> =
>>>>    The authenticated identity reported by = the SASL mechanism shall be
>>>>    the = identity which the OAuth mechanism has securely established = for
>>>>    the client with the OAuth = credential.
>>>>
>>>> ?
>>> =
>>> Not my language here, but your language doesn't do it for me.  How about
>>>
>>>  =   The authenticated identity reported by the mechanism is the user =
>>                =                     =             ^^^^^^^^^
>> =
>> Is this the SASL mechanism?
>> =
>>>    identity securely established for the = client with the OAuth
>>> credential.
>> =
>> Works for me, although Hannes indicated that "identity" is = the wrong
>> term and "client identifier" would be more = correct.
>>
>>>> I'm still not sure this is = unambigious since OAuth may establish two
>>>> = identities, of the user and the proxy.  I suspect "the identity" = could
>>>> be qualified to be the user (and OAuth 1.x and = 2.x uses different terms
>>>> here if I recall = correctly).
>>>>
>>>> Section = 3.2.1:
>>>>
>>>>    Note that = the semantics of the authz-id are specified by the = SASL
>>>>    framework [RFC4422].  A SASL = application is, of course, free to apply
>>>>  =   mappings of the OAuth authcid to authz-ids as per-SASL, and it = is
>>>>    free to apply mappings common to = non-SASL OAuth applications.
>>>>
>>>> = The first sentence is great, but the term 'authz-id' should = be
>>>> explained.
>>>> =
>>>> The second sentence is confusing.  First, = there is no such thing as a
>>>> per-SASL authcid to = authzid mapping: those mappings are by definition
>>>> = always mechanism dependent, since the authcid form is mechanism
>>>> dependent.  Second, "authz-id" refer = to the authorization identity
>>>> field, which can be = empty, so what you want to map to is not the
>>>> = authz-id but the general concept of the identity to act = as.
>>>>
>>>
>>> Not my = language, please propose text.
>>
>> I did propose = text further down in my reply:
>>
>>    = Note that the semantics of the authorization identity is specified = by
>>    the SASL framework [RFC4422].
>> =
>> And drop the second sentence.
>> =
>>>> I encourage you to re-read this part from 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).
>>>>
>>>> So, I don't think = your second sentence above adds any value, at least
>>>> = the current text doesn't do it for me right now.  I would simply = leave
>>>> it as:
>>>> =
>>>>    Note that the semantics of the = authorization identity is specified by
>>>>    = the SASL framework [RFC4422].
>>>>
>>>> = You don't have to say anything further than that.
>>>>
>>>> Section 3.2.1:
>>>> =
>>>>    If both = identities
>>>>    are needed by an application = the developer will need to provide a way
>>>>  =   to communicate that from the SASL mechanism back to the = application
>>>>    such as a GS2 [RFC2473] = named type like GSS_C_NT_USER_NAME or a
>>>>    = comparable newly defined GS2 attribute.
>>>> =
>>>> RFC 2743 (sic) is called GSS-API not GS2.  The = final "GS2 attribute"
>>>> should be "GSS-API name type = or name attribute [RFC 6680]".
>>>
>>> fixed, = thank you
>>>
>>>>
>>>> = Section 5.2:
>>>>
>>>>    = p,a=3Duser@example.com^A
>>>>= ;
>>>> This is wrong, you changed 'y' to 'p' which = doesn't conform to the ABNF.
>>>> Please see my review = comment of -06 on this.
>>>
>>> I'll change it = back, I changed it by request.
>>
>> Huh?  = Please read my review comment of -06.  The 'y' was even = more
>> incorrect.  You want 'p', but you must follow the = ABNF and describe the
>> cbtype.  It could be:
>> =
>> p=3Dtls-unique,a=3Duser@example.com
>> =
>> but it depends on what you want.
>>
>> = /Simon
>>
>>
>>
> = _______________________________________________
> Kitten mailing = list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten

=

=
= --Apple-Mail=_DFD1239E-0155-40AD-B043-D709E0F162DA-- --Apple-Mail=_4A4A1ED3-9974-4882-B63C-EBD087C2B09C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkx NTE3MjQxOFowIwYJKoZIhvcNAQkEMRYEFCjXSVnHY/F/fd38+oTtHN7BbFe9MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AGhlMBhvMKiRR4w+SGw5hEluVtTbeywBwoeEK6rmDqh4ZlBSKzXzn8BqLlCwZY4Bp+WjIIbMseyX btvXsodnL1mufxnK0gZcfpgrqsA2vWodrY3TklgVHMYIofsvcsSxETiz4l73hXe0EMocBa/wK8fM ShT+eO2VcVAHgDx4HSic3vDo1oFgApNv4uYlM1zyAwxyGNJO5hI1c01OyuZuPSDWDaD9m/PnpiRr MDeiZume/Kt+6SGXaUlom0v80t/0Llg5LvbQUzeDhCqRT0CzDib/0iSJoQ6pNM4efwSYQpS8UlnF AqC7tFm+kt0UlzIVmDRLmbyRR5P/WK+iLvd65GMAAAAAAAA= --Apple-Mail=_4A4A1ED3-9974-4882-B63C-EBD087C2B09C-- From wmills@yahoo-inc.com Sat Sep 15 10:44: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 99F0821E8039 for ; Sat, 15 Sep 2012 10:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.533 X-Spam-Level: X-Spam-Status: No, score=-17.533 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_UNSUB18=0.131, 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 cLJXhQnX5NUT for ; Sat, 15 Sep 2012 10:44:53 -0700 (PDT) Received: from nm32-vm7.bullet.mail.ne1.yahoo.com (nm32-vm7.bullet.mail.ne1.yahoo.com [98.138.229.55]) by ietfa.amsl.com (Postfix) with SMTP id 9D39B21E8037 for ; Sat, 15 Sep 2012 10:44:52 -0700 (PDT) Received: from [98.138.90.56] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 15 Sep 2012 17:44:47 -0000 Received: from [98.138.226.164] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 15 Sep 2012 17:44:46 -0000 Received: from [127.0.0.1] by omp1065.mail.ne1.yahoo.com with NNFMP; 15 Sep 2012 17:44:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 900861.6024.bm@omp1065.mail.ne1.yahoo.com Received: (qmail 31976 invoked by uid 60001); 15 Sep 2012 17:44:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1347731086; bh=E+EXZbe6/r8L2kHXJyzccO80Biyrx3TVcd3qa9Xop64=; 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=cXhME3fL8zh6I/FqeqmBwp4XrxfGUGZtbmXrX/zQJxW9nrjLsTtGvPtQg00OcG8W0vyBApYTU6aF15vqDburXyPKcQYi91vbJQ107dXsK1eCkOdu3pPKHQ2+oQYtaF/v4oXePSuUG1zql4XMv2DSSVYNgSQH9Kg1ZP3OBeDXKaQ= 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=Cgx5Ldaj3MlvEoCvAVm1hq9zWB+4BL+OwH6S9dZArmTt5qkp/GHBZUV576XZqPaapaB6zaBoeGN8i29c0u2WatmMfXIVe9p5C5Z4l9OtQ+CjdOqiTH2RwJiKKBGY8WkAK9U0JOLHlwBroNuTsP2Qmxp0dEprUuXjVEq6dTdiFzo=; X-YMail-OSG: .65fGtMVM1mQZ0ZjHf5kS2VHDbR5q8GbbmGSgCEiMtOIx2S ax5XklDW3ix3.izakBJpp7.JCq2l_qVntnlbVH34IGT.VApoz.bYMIZSpSjk o4kq1bzvHOzzWeDMJew6Qmfyr2ls7uoxPPsy2zTHxrgMeGY9lGHgl4lrWgvz kVPHnNza4oOK7jhPn0pfGEkV.xE_4S0egBBVGKmXkwAHuAd.pUtsX.z2H5VD c57tALdN_nSxytJwGn18GWH_n1kAVWkEc_zp77X6oHtk5ahhMWhgaAeNyCwN ngkJx.gQMxEnflrh6XN2vy.zhaclVuvVRozE.QRQfAJMHwrAKQjoFmn4ghgE dvUjywUohh8UEauDym.bzoMOzkboa_TESoLtLlxLYVbg34CbRkh3sa5uGykV CaXN4yhmbJmvLsCiPXCW6twe6GdIunyfpzb0HAqXs_FFaAI4q Received: from [99.31.212.42] by web31809.mail.mud.yahoo.com via HTTP; Sat, 15 Sep 2012 10:44:46 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <20120913064111.30988.73947.idtracker__13304.7408344739$1347518481$gmane$org@ietfa.amsl.com> <87ehm6qtrj.fsf@latte.josefsson.org> <1347550295.73931.YahooMailNeo@web31807.mail.mud.yahoo.com> <87d31pr9lb.fsf@latte.josefsson.org> <1347663010.52373.YahooMailNeo@web31808.mail.mud.yahoo.com> <8503B096-0713-4B0A-BB2E-E288B3C8CF3F@ve7jtb.com> <1347721890.2250.YahooMailNeo@web31805.mail.mud.yahoo.com> Message-ID: <1347731086.21496.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Sat, 15 Sep 2012 10:44:46 -0700 (PDT) From: William Mills To: John Bradley In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-1650296275-1347731086=:21496" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Updated text Re: I-D Action: draft-ietf-kitten-sasl-oauth-07.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, 15 Sep 2012 17:44:54 -0000 ---1395015409-1650296275-1347731086=:21496 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I don't think the language that I have is at odds which what you are saying= .=A0 Yes, the client_id might just be a user agent string that can be faked= , etc.=A0 It's up to the app to decide whether it needs it and what to do w= ith it.=0A=0A=0A=0A=0A>________________________________=0A> From: John Brad= ley =0A>To: William Mills =0A>Cc:= Simon Josefsson ; "kitten@ietf.org" = =0A>Sent: Saturday, September 15, 2012 10:24 AM=0A>Subject: Re: [kitten] U= pdated text Re: I-D Action: draft-ietf-kitten-sasl-oauth-07.txt=0A> =0A>=0A= >Unless it is a real confidential client, and not just one using the code f= low with a password that can be extracted, then client_id is a hint about t= he client software and not much more meaningful than that.=0A>=0A>=0A>That = hint is also something that is consumed by the Authorization server not oth= er things.=0A>=0A>=0A>In OAuth 2 at least the client_id is not explicitly p= assed to the Resource server it is just the access_token in bearer or the M= AC key Identifier (id) . =A0The oauth_consumer_key is passed to the resourc= e server in 1.0a though it should is not typically used for anything other = than calculating the signature.=0A>=0A>=0A>So you have two situations depen= ding on if you are using OAuth 1 or 2.=0A>OAuth 1: =A0The oauth_consumer_ke= y might be trivially faked in the message to the resource owner unless it i= s checked out of band.=0A>OAuth 2: =A0The client_id is not sent as it is as= sumed that any meaningful information about the client is in the access_tok= en/id or retrieved out of band by lookup.=0A>=0A>=0A>In OAuth 1 the protect= ed resource could conceivably be set up to look up the oauth_token_secret b= ased on the combination of oauth_consumer_key and oauth_token but that woul= d be implementation specific.=0A>=0A>=0A>I think all you can really say is = that what you send for client_id/oauth_token_secret=A0is a hint and might n= ot be trust worthy and needs to be confirmed by the resource out of band.= =0A>=0A>=0A>In principal you just need=A0oauth_consumer_key in OAuth 1 to v= erify the signature. =A0Though I suspect that at the end of the day the cli= ent and protected resource communication over SASL are so different that th= e OAuth 1.0a signature mechanism is only similar so you could drop it if th= e oauth_token is globally scoped and not per client scoped. =A0 I think tha= t is probably OK though it is really the Authorization part that needs to b= e compatible with the spec.=0A>=0A>=0A>John B.=0A>=0A>=0A>=0A>=0A>=0A>=0A>= =0A>=0A>On 2012-09-15, at 12:11 PM, William Mills wr= ote:=0A>=0A>What the token identifies may indeed be implementation dependen= t.=A0 I'll strike "resource owner", which leaves it up to the app to unders= tand what the id is and how to use it.=0A>>=0A>>Yep, the client ID might be= the equivalent of a user agent string.=A0 It's up to the app to decide if = it's interesting, I thought that was adequatley captured by "If both identi= ties are needed by an application ...", no?=0A>>=0A>>Regards,=0A>>=0A>>-bil= l=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>>________________________________=0A>>>= From: John Bradley =0A>>>To: William Mills =0A>>>Cc: Simon Josefsson ; "kitten@ietf.or= g" =0A>>>Sent: Saturday, September 15, 2012 6:52 AM=0A>>>= Subject: Re: [kitten] Updated text Re: I-D Action: draft-ietf-kitten-sasl-o= auth-07.txt=0A>>> =0A>>>I appreciate what thou are trying too get at.=0A>>>= =0A>>>However the access_token doesn't identify the user itself.=A0 =0A>>>= =0A>>>It conveys=A0 a access permission for a specific client to a resource= owned by a user.=0A>>>=0A>>>The resource is the thing that may identify th= e user by inference OAuth.=0A>>>=0A>>>The oauth_consumer_key also doesn't n= ecessarily identify a single=0A instance of a client, it may only be identi= fying a software client that has many instances used by many different user= s.=0A>>>=0A>>>This may not be a meaning full distinction in the context of = SASL, however I have seen people create security holes by making unwarrante= d assumptions about the semantics of those.=0A>>>=0A>>>John B.=0A>>>=0A>>>= =0A>>>=0A>>>On 2012-09-14, at 7:50 PM, William Mills = wrote:=0A>>>=0A>>>> OK, I've changed the main paragraphs in question a bit= and renamed 3.2.1=A0 the new text is: =0A>>>> =0A>>>> =0A>>>> =0A>>>>=A0 = =A0 The server responds to a successfully verified client message by compl= eting =0A>>>> =0A>>>>=A0 =A0 the SASL negotiation. The authenticated ident= ity reported by the SASL mechanism =0A>>>> =0A>>>>=A0 =A0 is the resource = owner identity securely established for the client with the =0A>>>> =0A>>>>= =A0 =A0 OAuth credential. The application, not the SASL mechanism, based o= n local access =0A>>>> =0A>>>>=A0 =A0 policy determines whether the identi= ty reported by the mechanism is allowed =0A>>>> =0A>>>>=A0 =A0 access to t= he requested resource. Note that the semantics of the authz-id is =0A>>>> = =0A>>>>=A0 =A0 specified by the SASL framework [RFC4422].=0A>>>> =0A>>>>= =A0 =A0 3.2.1. OAuth Identities in the SASL Context=0A>>>> =0A>>>>=A0 =A0 = Some OAuth schemes can carry both a resource owner identity and a "proxy" = =0A>>>> =0A>>>>=A0 =A0 identity, for example an OAuth 1.0a [RFC5849] mecha= nism where the consumer key =0A>>>> =0A>>>>=A0 =A0 (oauth_consumer_key) id= entifies the entity using the token and the token itself =0A>>>> =0A>>>>=A0= =A0 identifies the user. If both identities are needed by an application = the =0A>>>> =0A>>>>=A0 =A0 developer will need to provide=0A a way to comm= unicate that from the SASL mechanism =0A>>>> =0A>>>>=A0 =A0 back to the ap= plication such as a GSS-API [RFC2473] named type like =0A>>>> =0A>>>>=A0 = =A0 GSS_C_NT_USER_NAME or a comparable newly defined GSS-API name type or = name =0A>>>> =0A>>>>=A0 =A0 attribute [RFC6680].=0A>>>> =0A>>>> =0A>>>> an= d I fixed the channel binding to include the cbtype.=0A>>>> =0A>>>> -bill= =0A>>>> =0A>>>>> ________________________________=0A>>>>> From: Simon Josef= sson =0A>>>>> To: William Mills = =0A>>>>> Cc: "kitten@ietf.org" =0A>>>>> Sent:=0A Thursda= y, September 13, 2012 12:44 PM=0A>>>>> Subject: Re: [kitten] I-D Action: dr= aft-ietf-kitten-sasl-oauth-07.txt=0A>>>>> =0A>>>>> William Mills writes:=0A>>>>> =0A>>>>>> comment inline...=A0 Thanks for the = reading.=0A>>>>>> =0A>>>>>> =0A>>>>>>> ________________________________=0A>= >>>>>> From: Simon Josefsson =0A>>>>>>> To: kitten@iet= f.org =0A>>>>>>> Sent: Thursday, September 13, 2012 12:14 AM=0A>>>>>>> Subj= ect: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-07.txt=0A>>>>>>>= =0A>>>>>>> Thanks for update,=0A>>>>>>> =0A>>>>>>> Quick review=0A of the = text that have changed since -07 below.=0A>>>>>>> =0A>>>>>>> Section 3.2:= =0A>>>>>>> =0A>>>>>>>=A0 =A0 The authenticated identity reported=0A>>>>>>>= =A0 =A0 by the mechanism is the identity which the mechanism has securely= =0A>>>>>>>=A0 =A0 established for the client with the OAuth credential.=0A>= >>>>>> =0A>>>>>>> This confuses me, I believe the two uses of the word 'mec= hanism' refer=0A>>>>>>> to different things.=A0 Should it be:=0A>>>>>>> =0A= >>>>>>>=A0 =A0 The authenticated identity reported by the SASL mechanism sh= all be=0A>>>>>>>=A0 =A0 the identity which the OAuth mechanism has securely= established for=0A>>>>>>>=A0 =A0 the client with the OAuth credential.=0A>= >>>>>> =0A>>>>>>> ?=0A>>>>>> =0A>>>>>> Not my language here, but your langu= age doesn't=0A do it for me.=A0 How about=0A>>>>>> =0A>>>>>>=A0 =A0 The aut= henticated identity reported by the mechanism is the user =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 ^^^^^^^^^=0A>>>>> =0A>>>>> Is this the SASL mechanism?=0A>>>>= > =0A>>>>>>=A0 =A0 identity securely established for the client with the OA= uth=0A>>>>>> credential.=0A>>>>> =0A>>>>> Works for me, although Hannes ind= icated that "identity" is the wrong=0A>>>>> term and "client identifier" wo= uld be more correct.=0A>>>>> =0A>>>>>>> I'm still not sure this is unambigi= ous since OAuth may establish two=0A>>>>>>> identities, of the user and the= proxy.=A0 I suspect "the identity" could=0A>>>>>>> be qualified to be the = user (and OAuth 1.x and 2.x uses different=0A terms=0A>>>>>>> here if I rec= all correctly).=0A>>>>>>> =0A>>>>>>> Section 3.2.1:=0A>>>>>>> =0A>>>>>>>=A0= =A0 Note that the semantics of the authz-id are specified by the SASL=0A>>= >>>>>=A0 =A0 framework [RFC4422].=A0 A SASL application is, of course, free= to apply=0A>>>>>>>=A0 =A0 mappings of the OAuth authcid to authz-ids as pe= r-SASL, and it is=0A>>>>>>>=A0 =A0 free to apply mappings common to non-SAS= L OAuth applications.=0A>>>>>>> =0A>>>>>>> The first sentence is great, but= the term 'authz-id' should be=0A>>>>>>> explained.=0A>>>>>>> =0A>>>>>>> Th= e second sentence is confusing.=A0 First, there is no such thing as a=0A>>>= >>>> per-SASL authcid to authzid mapping: those mappings are by definition= =0A>>>>>>> always mechanism dependent, since the authcid form is=0A mechani= sm=0A>>>>>>> dependent.=A0 Second, "authz-id" refer to the authorization id= entity=0A>>>>>>> field, which can be empty, so what you want to map to is n= ot the=0A>>>>>>> authz-id but the general concept of the identity to act as= .=0A>>>>>>> =0A>>>>>> =0A>>>>>> Not my language, please propose text.=0A>>>= >> =0A>>>>> I did propose text further down in my reply:=0A>>>>> =0A>>>>>= =A0 =A0 Note that the semantics of the authorization identity is specified = by=0A>>>>>=A0 =A0 the SASL framework [RFC4422].=0A>>>>> =0A>>>>> And drop t= he second sentence.=0A>>>>> =0A>>>>>>> I encourage you to re-read this part= from RFC 4422:=0A>>>>>>> =0A>>>>>>>=A0 =A0 The client provides its credent= ials (which include or imply an=0A>>>>>>>=A0 =A0 authentication identity) a= nd, optionally, a character=0A string=0A>>>>>>>=A0 =A0 representing the req= uested authorization identity as part of the SASL=0A>>>>>>>=A0 =A0 exchange= .=A0 When this character string is omitted or empty, the client=0A>>>>>>>= =A0 =A0 is requesting to act as the identity associated with the credential= s=0A>>>>>>>=A0 =A0 (e.g., the user is requesting to act as the authenticati= on identity).=0A>>>>>>> =0A>>>>>>> So, I don't think your second sentence a= bove adds any value, at least=0A>>>>>>> the current text doesn't do it for = me right now.=A0 I would simply leave=0A>>>>>>> it as:=0A>>>>>>> =0A>>>>>>>= =A0 =A0 Note that the semantics of the authorization identity is specified = by=0A>>>>>>>=A0 =A0 the SASL framework [RFC4422].=0A>>>>>>> =0A>>>>>>> You = don't have to say anything further than that.=0A>>>>>>> =0A>>>>>>> Section = 3.2.1:=0A>>>>>>> =0A>>>>>>>=A0 =A0 If both identities=0A>>>>>>>=A0 =A0 are = needed by an application the developer will need to provide a way=0A>>>>>>>= =A0 =A0 to communicate that from the SASL mechanism back to the application= =0A>>>>>>>=A0 =A0 such as a GS2 [RFC2473] named type like GSS_C_NT_USER_NAM= E or a=0A>>>>>>>=A0 =A0 comparable newly defined GS2 attribute.=0A>>>>>>> = =0A>>>>>>> RFC 2743 (sic) is called GSS-API not GS2.=A0 The final "GS2 attr= ibute"=0A>>>>>>> should be "GSS-API name type or name attribute [RFC 6680]"= .=0A>>>>>> =0A>>>>>> fixed, thank you=0A>>>>>> =0A>>>>>>> =0A>>>>>>> Sectio= n 5.2:=0A>>>>>>> =0A>>>>>>>=A0 =A0 p,a=3Duser@example.com^A=0A>>>>>>> =0A>>= >>>>> This is wrong, you changed 'y' to 'p' which doesn't conform to the AB= NF.=0A>>>>>>> Please see my review comment of -06 on this.=0A>>>>>> =0A>>>>= >> I'll change it back, I changed it by request.=0A>>>>> =0A>>>>> Huh?=A0 P= lease read my review comment of -06.=A0 The 'y' was even more=0A>>>>> incor= rect.=A0 You want 'p', but you must follow the ABNF and describe the=0A>>>>= > cbtype.=A0 It could be:=0A>>>>> =0A>>>>> p=3Dtls-unique,a=3Duser@example.= com=0A>>>>> =0A>>>>> but it depends on what you want.=0A>>>>> =0A>>>>> /Sim= on=0A>>>>> =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> ---1395015409-1650296275-1347731086=:21496 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I don't think the language that I have is at odds which what you are sayi= ng.  Yes, the client_id might just be a user agent string that can be = faked, etc.  It's up to the app to decide whether it needs it and what= to do with it.

From: John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills@yahoo-inc.= com>
Cc: Simon Josefsson &= lt;simon@josefsson.org>; "kitten@ietf.org" <kitten@ietf.org>
= Sent: Saturday, September = 15, 2012 10:24 AM
Subject:= Re: [kitten] Updated text Re: I-D Action: draft-ietf-kitten-sasl-oauth= -07.txt

Unless it is a= real confidential client, and not just one using the code flow with a pass= word that can be extracted, then client_id is a hint about the client softw= are and not much more meaningful than that.

That hint is= also something that is consumed by the Authorization server not other thin= gs.

In OAuth 2 at least the client_id is not expli= citly passed to the Resource server it is just the access_token in bearer o= r the MAC key Identifier (id) .  The oauth_consumer_key is passed to the resource server in 1.0a though it should is not typically used for any= thing other than calculating the signature.

So you= have two situations depending on if you are using OAuth 1 or 2.
= OAuth 1:  The oauth_consumer_key might be trivially faked in the messa= ge to the resource owner unless it is checked out of band.
OAuth = 2:  The client_id is not sent as it is assumed that any meaningful inf= ormation about the client is in the access_token/id or retrieved out of ban= d by lookup.

In OAuth 1 the protected resource cou= ld conceivably be set up to look up the oauth_token_secret based on the com= bination of oauth_consumer_key and oauth_token but that would be implementa= tion specific.

I think all you can really say is t= hat what you send for client_id/oauth_token_secret is a hint and might= not be trust worthy and needs to be confirmed by the resource out of band.

In principal you just need oauth_co= nsumer_key in OAuth 1 to verify the signature.  Though I suspect that = at the end of the day the client and protected resource communication over = SASL are so different that the OAuth 1.0a signature mechanism is only simil= ar so you could drop it if the oauth_token is globally scoped and not per c= lient scoped.   I think that is probably OK though it is really the Au= thorization part that needs to be compatible with the spec.

<= /div>
John B.



On 2012-09-15, at 12:11 PM, William Mills <wmills@yahoo-inc.com> wrote:
=
What the token ide= ntifies may indeed be implementation dependent.  I'll strike "resource= owner", which leaves it up to the app to understand what the id is and how= to use it.

Yep, the client ID might be the equivalent of a user age= nt string.  It's up to the app to decide if it's interesting, I though= t that was adequatley captured by "If both identities are needed by an appl= ication ...", no?

Regards,

-bill


= From: John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: Simon Josefsson <simon@josefsson.org>; "= kitten@ietf.org" <kitten@ietf.org&= gt;
Sent: Saturday, Se= ptember 15, 2012 6:52 AM
Subject:<= /span> Re: [kitten] Updated text Re: I-D Action: draft-ietf-kitten-sasl-oauth-07.txt

I a= ppreciate what thou are trying too get at.

However the access_token = doesn't identify the user itself. 

It conveys  a access p= ermission for a specific client to a resource owned by a user.

The r= esource is the thing that may identify the user by inference OAuth.

= The oauth_consumer_key also doesn't necessarily identify a single=0A instan= ce of a client, it may only be identifying a software client that has many = instances used by many different users.

This may not be a meaning fu= ll distinction in the context of SASL, however I have seen people create se= curity holes by making unwarranted assumptions about the semantics of those= .

John B.



On 2012-09-14, at 7:50 PM, William Mills &l= t;wmills@yahoo-inc.com> wrot= e:

> OK, I've changed the main paragraphs in question a bit and r= enamed 3.2.1  the new text is:
>
>
>
>&nbs= p;   The server responds to a successfully verified client message by= completing
>
>    the SASL negotiation. The authe= nticated identity reported by the SASL mechanism
>
>  &n= bsp; is the resource owner identity securely established for the client with the
>=0A
>    OAuth credential. The a= pplication, not the SASL mechanism, based on local access
>
>=     policy determines whether the identity reported by the mecha= nism is allowed
>
>    access to the requested res= ource. Note that the semantics of the authz-id is
>
>  &= nbsp; specified by the SASL framework [RFC4422].
>
>  &n= bsp; 3.2.1. OAuth Identities in the SASL Context
>
>  &n= bsp; Some OAuth schemes can carry both a resource owner identity and a "pr= oxy"
>
>    identity, for example an OAuth 1.0a [R= FC5849] mechanism where the consumer key
>
>    (o= auth_consumer_key) identifies the entity using the token and the token itse= lf
>
>    identifies the user. If both identities = are needed by an application the
>
>    developer = will need to provide=0A a way to communicate that from the SASL mechanism <= br>>
>    back to the application such as a GSS-API [R= FC2473] named type like
>
>    GSS_C_NT_USER_NAME = or a comparable newly defined GSS-API name type or name
>
>&n= bsp;   attribute [RFC6680].
>
>
> and I fixed the= channel binding to include the cbtype.
>
> -bill
>
= >> ________________________________
>> From: Simon Josefsson= <simon@josefsson.org>
&= gt;> To: William Mills <wmill= s@yahoo-inc.com>
>> Cc: "kit= ten@ietf.org" <kitten@ietf.org>
>> Sent:=0A Thursday, Septembe= r 13, 2012 12:44 PM
>> Subject: Re: [kitten] I-D Action: draft-iet= f-kitten-sasl-oauth-07.txt
>>
>> William Mills <wmills@yahoo-inc.com> writes:
= >>
>>> comment inline...  Thanks for the reading.>>>
>>>
>>>> ______________________= __________
>>>> From: Simon Josefsson <simon@josefsson.org>
>>>> To: kitten@ietf.org
>>>> Sent: = Thursday, September 13, 2012 12:14 AM
>>>> Subject: Re: [kit= ten] I-D Action: draft-ietf-kitten-sasl-oauth-07.txt
>>>>
>>>> Thanks for update,
>>>>
>>&g= t;> Quick review=0A of the text that have changed since -07 below.
&g= t;>>>
>>>> Section 3.2:
>>>>
&g= t;>>>    The authenticated identity reported
>>= >>    by the mechanism is the identity which the mechanism = has securely
>>>>    established for the client wi= th the OAuth credential.
>>>>
>>>> This conf= uses me, I believe the two uses of the word 'mechanism' refer
>>&g= t;> to different things.  Should it be:
>>>>
>= ;>>>    The authenticated identity reported by the SASL = mechanism shall be
>>>>    the identity which the = OAuth mechanism has securely established for
>>>>  &nbs= p; the client with the OAuth credential.
>>>>
>>&g= t;> ?
>>>
>>> Not my language here, but your la= nguage doesn't=0A do it for me.  How about
>>>
>>= ;>    The authenticated identity reported by the mechanism is = the user
>>               = ;                     &nb= sp;           ^^^^^^^^^
>>
>> = Is this the SASL mechanism?
>>
>>>    ident= ity securely established for the client with the OAuth
>>> cred= ential.
>>
>> Works for me, although Hannes indicated th= at "identity" is the wrong
>> term and "client identifier" would b= e more correct.
>>
>>>> I'm still not sure this is= unambigious since OAuth may establish two
>>>> identities, = of the user and the proxy.  I suspect "the identity" could
>>= >> be qualified to be the user (and OAuth 1.x and 2.x uses different= =0A terms
>>>> here if I recall correctly).
>>>&= gt;
>>>> Section 3.2.1:
>>>>
>>>= ;>    Note that the semantics of the authz-id are specified by= the SASL
>>>>    framework [RFC4422].  A SAS= L application is, of course, free to apply
>>>>   = mappings of the OAuth authcid to authz-ids as per-SASL, and it is
>&= gt;>>    free to apply mappings common to non-SASL OAuth ap= plications.
>>>>
>>>> The first sentence is = great, but the term 'authz-id' should be
>>>> explained.
= >>>>
>>>> The second sentence is confusing.&nbs= p; First, there is no such thing as a
>>>> per-SASL authcid = to authzid mapping: those mappings are by definition
>>>> al= ways mechanism dependent, since the authcid form is=0A mechanism
>>= ;>> dependent.  Second, "authz-id" refer to the authorization id= entity
>>>> field, which can be empty, so what you want to m= ap to is not the
>>>> authz-id but the general concept of th= e identity to act as.
>>>>
>>>
>>>= Not my language, please propose text.
>>
>> I did propo= se text further down in my reply:
>>
>>    Not= e that the semantics of the authorization identity is specified by
>&= gt;    the SASL framework [RFC4422].
>>
>> And= drop the second sentence.
>>
>>>> I encourage you= to re-read this part from RFC 4422:
>>>>
>>>&g= t;    The client provides its credentials (which include or imply= an
>>>>    authentication identity) and, optional= ly, a character=0A string
>>>>    representing the= requested authorization identity as part of the SASL
>>>>&n= bsp;   exchange.  When this character string is omitted or empty,= the client
>>>>    is requesting to act as the id= entity associated with the credentials
>>>>    (e.= g., the user is requesting to act as the authentication identity).
>&= gt;>>
>>>> So, I don't think your second sentence abo= ve adds any value, at least
>>>> the current text doesn't do= it for me right now.  I would simply leave
>>>> it as:=
>>>>
>>>>    Note that the semant= ics of the authorization identity is specified by
>>>> =   the SASL framework [RFC4422].
>>>>
>>>&= gt; You don't have to say anything further than that.
>>>>= =0A
>>>> Section 3.2.1:
>>>>
>>>= ;>    If both identities
>>>>    are = needed by an application the developer will need to provide a way
>&g= t;>>    to communicate that from the SASL mechanism back to= the application
>>>>    such as a GS2 [RFC2473] n= amed type like GSS_C_NT_USER_NAME or a
>>>>    com= parable newly defined GS2 attribute.
>>>>
>>>&g= t; RFC 2743 (sic) is called GSS-API not GS2.  The final "GS2 attribute= "
>>>> should be "GSS-API name type or name attribute [RFC 6= 680]".
>>>
>>> fixed, thank you
>>> >>>>
>>>> Section 5.2:
>>>> >>>>    p,a=3Duser@example.com^A
>>>>= ;=0A
>>>> This is wrong, you changed 'y' to 'p' which doesn= 't conform to the ABNF.
>>>> Please see my review comment of= -06 on this.
>>>
>>> I'll change it back, I chang= ed it by request.
>>
>> Huh?  Please read my review= comment of -06.  The 'y' was even more
>> incorrect.  Y= ou want 'p', but you must follow the ABNF and describe the
>> cbty= pe.  It could be:
>>
>> p=3Dtls-unique,a=3Duser@example.com
>>
>> but= it depends on what you want.
>>
>> /Simon
>> <= br>>>
>>
> _________________________________________= ______
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten



=



---1395015409-1650296275-1347731086=:21496-- From internet-drafts@ietf.org Sun Sep 16 16:16: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 B187621F84EF; Sun, 16 Sep 2012 16:16:36 -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 mhXVQyp9WTFa; Sun, 16 Sep 2012 16:16:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A7121F8505; Sun, 16 Sep 2012 16:16:36 -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: <20120916231636.28226.58819.idtracker@ietfa.amsl.com> Date: Sun, 16 Sep 2012 16:16:36 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-08.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: Sun, 16 Sep 2012 23:16:36 -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-08.txt Pages : 30 Date : 2012-09-16 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wmills@yahoo-inc.com Sun Sep 16 16:23: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 7078421F84F8 for ; Sun, 16 Sep 2012 16:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.576 X-Spam-Level: X-Spam-Status: No, score=-17.576 tagged_above=-999 required=5 tests=[AWL=0.022, 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 xm+wh1gIHrP5 for ; Sun, 16 Sep 2012 16:23:46 -0700 (PDT) Received: from nm24-vm0.bullet.mail.sp2.yahoo.com (nm24-vm0.bullet.mail.sp2.yahoo.com [98.139.91.226]) by ietfa.amsl.com (Postfix) with SMTP id 703B321F84EC for ; Sun, 16 Sep 2012 16:23:46 -0700 (PDT) Received: from [98.139.91.65] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 16 Sep 2012 23:23:43 -0000 Received: from [98.139.91.21] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 16 Sep 2012 23:23:43 -0000 Received: from [127.0.0.1] by omp1021.mail.sp2.yahoo.com with NNFMP; 16 Sep 2012 23:23:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 880418.36483.bm@omp1021.mail.sp2.yahoo.com Received: (qmail 53619 invoked by uid 60001); 16 Sep 2012 23:23:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1347837823; bh=tXb9PGM+V7KKGH2W9j+vU+Ds6DqX8S7qJJ2H95+zANA=; 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=kjQW5MqlsjoszDgLvih6R/drdFaW+G+i3oLu9E166DKNIu8PQBSFglTgmb1yVXvWb/npED1dtJEFxkQgeFgiFUbo5GO1loWgxqpi5XDs8nKWLsbAm9E0bjeRv/frS92JZJI55kjgG5lrd7WAzcOIcK2okW/yXeVWMaI5EH1OAcE= 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=dJLlOYoO0Wp2mhzclqRDgd71FpAIoIvncEU3r1QM0shzYRiCLaIEN0VnGV3uHAGZDhxkMg6z/hyy1Yp1fkjb1PlRqeMm3CzowH3IcmmCglsbivJt9bjT3mqgL4thf1bDZUb91cDNXhxQsfTXMChAvMnRfzAmeTwLy2ylcg04NSY=; X-YMail-OSG: BtwVVGkVM1nIQeTc_TOCSFpIcd4NMrwuqdzVlSdN__Jv3zo Vu16sScWfy5Bl_Wzo_OgJyrhdgCwGfyP2M4Aw0uosaEfcAbVhb3kNG2ER6tB 88I3IxtwgmQsPKo8S_KzFOkUvkv6Dx05jCQ0tHfSP1YGqY58H2XJ2AEwBgxv aXp1ajedpTaNd.X7fkRGu9_k2YU6jQgdgBnKpM_c0ECllGSoH.nbmexXc84z z8GRc4LexX77VESKhEivzVwOS9SzhlWclJUcHZmqf_m.AmBa7Qd.Ob2Mn_cA IlPeZxHmFYXk9UctRH7ZtDN8DHCAdTmOwxveqDtDSapayePpa3ZLloKBSi3O 8WnDPQ8Wpi81l4Ygmw7KaKH3gW.tvFpTtfLY4hm5D9gcZXkXpzJfVxX9NV6l sxMiwuQoCBQmAn4L0Zku..OA9ZZ5JrDSm94hRfek5LG8- Received: from [99.31.212.42] by web31802.mail.mud.yahoo.com via HTTP; Sun, 16 Sep 2012 16:23:42 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <20120916231636.28226.58819.idtracker@ietfa.amsl.com> Message-ID: <1347837822.41962.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Sun, 16 Sep 2012 16:23:42 -0700 (PDT) From: William Mills To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" In-Reply-To: <20120916231636.28226.58819.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-1180948401-1347837822=:41962" Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-08.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: Sun, 16 Sep 2012 23:23:47 -0000 ---1036955950-1180948401-1347837822=:41962 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This addresses Paul's concern that the identifier might not identify a reso= urce owner, it might just identify the resource itself.=A0 Made this a litt= le more flexible, and I don't think I broke anything.=0A=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: Sunday, September 16, 2012 4:16 PM=0A>Subject: [kitten] I-D Action: = draft-ietf-kitten-sasl-oauth-08.txt=0A> =0A>=0A>A New Internet-Draft is ava= ilable from the on-line Internet-Drafts directories.=0A>This draft is a wor= k item of the Common Authentication Technology Next Generation Working Grou= p of the IETF.=0A>=0A>=A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : A set of SASL a= nd GSS-API Mechanisms for OAuth=0A>=A0=A0=A0 Author(s)=A0 =A0 =A0 : Willia= m Mills=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tim Showalte= r=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-08.txt= =0A>=A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0 : 30=0A>=A0=A0=A0 Date=A0 =A0 =A0 = =A0 =A0 =A0 : 2012-09-16=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 credentials=0A>=A0 obtained via OAuth over the Simple Authenti= cation and Security Layer=0A>=A0 (SASL) or the Generic Security Service Ap= plication Program Interface=0A>=A0 (GSS-API) to access a protected resourc= e at a resource serve.=0A>=A0 Thereby, it enables schemes defined within t= he OAuth framework for=0A>=A0 non-HTTP-based application protocols.=0A>=0A= >=A0 Clients typically store the user's long term credential.=A0 This does= ,=0A>=A0 however, lead to significant security vulnerabilities, for exampl= e,=0A>=A0 when such a credential leaks.=A0 A significant benefit of OAuth = for=0A>=A0 usage in those clients is that the password is replaced by a to= ken.=0A>=A0 Tokens typically provided limited access rights and can be man= aged=0A>=A0 and revoked separately from the user's long-term credential=0A= >=A0 (password).=0A>=0A>=0A>The IETF datatracker status page for this draf= t 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-08=0A>=0A>A diff from the previous versio= n is available at:=0A>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-= sasl-oauth-08=0A>=0A>=0A>Internet-Drafts are also available by anonymous FT= P at:=0A>ftp://ftp.ietf.org/internet-drafts/=0A>=0A>_______________________= ________________________=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https= ://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> ---1036955950-1180948401-1347837822=:41962 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
This addr= esses Paul's concern that the identifier might not identify a resource owne= r, it might just identify the resource itself.  Made this a little mor= e flexible, and I don't think I broke anything.


From: "internet-= drafts@ietf.org" <internet-drafts@ietf.org>
To: i-d-announce@ietf.org
Cc: kitten@ietf.org
Sent: Sunday, September 16, 2012 4:16 PM
Subject: [kitten] I-D Action: draft-ie= tf-kitten-sasl-oauth-08.txt


A New Internet-Draft= is available from the on-line Internet-Drafts directories.
This draft = is a work item of the Common Authentication Technology Next Generation Work= ing Group of the IETF.

    Title      =     : A set of SASL and GSS-API Mechanisms for OAuth
 &n= bsp;  Author(s)      : William Mills
    =                      = ; Tim Showalter
                =           Hannes Tschofenig
    = Filename        : draft-ietf-kitten-sasl-oauth-08.txt
    Pages  &nbs= p;       : 30
    Date     = ;       : 2012-09-16

Abstract:
  OAuth enabl= es a third-party application to obtain limited access to a
  prote= cted resource, either on behalf of a resource owner by
  orchestra= ting an approval interaction, or by allowing the third-party
  app= lication to obtain access on its own behalf.

  This document d= efines how an application client uses credentials
  obtained via O= Auth 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.
  Thereb= y, 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,
  whe= n such a credential leaks.  A significant benefit of OAuth for
&nbs= p; usage in those clients is that the password is replaced by a token.
=   Tokens typically provided limited access rights and can be managed<= br>  and revoked separately from the user's long-term credential
&= nbsp; (password).


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

There's also a htmlized version available at:
<= a href=3D"http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-08" targe= t=3D"_blank">http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-08=

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sa= sl-oauth-08


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

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


---1036955950-1180948401-1347837822=:41962-- From cantor.2@osu.edu Mon Sep 17 08:23: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 9ED4D21F852D for ; Mon, 17 Sep 2012 08:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.757 X-Spam-Level: X-Spam-Status: No, score=-3.757 tagged_above=-999 required=5 tests=[AWL=-0.158, 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 ZjNIQdBWHtLZ for ; Mon, 17 Sep 2012 08:23:05 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 58DDD21F84A5 for ; Mon, 17 Sep 2012 08:23:04 -0700 (PDT) Received: from mail183-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Sep 2012 15:23:03 +0000 Received: from mail183-va3 (localhost [127.0.0.1]) by mail183-va3-R.bigfish.com (Postfix) with ESMTP id 62AF7E00A9 for ; Mon, 17 Sep 2012 15:23:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.174; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT07.osuad.osu.edu; RD:cio-tnc-ht07.osuad.osu.edu; EFVD:NLI X-SpamScore: 1 X-BigFish: VS1(zzd6f1izz1202h1d1ah1d2ahzzz2fh87h2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail183-va3: domain of osu.edu designates 164.107.81.174 as permitted sender) client-ip=164.107.81.174; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT07.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail183-va3 (localhost.localdomain [127.0.0.1]) by mail183-va3 (MessageSwitch) id 134789538165128_4598; Mon, 17 Sep 2012 15:23:01 +0000 (UTC) Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.236]) by mail183-va3.bigfish.com (Postfix) with ESMTP id 03553100050 for ; Mon, 17 Sep 2012 15:23:01 +0000 (UTC) Received: from CIO-TNC-HT07.osuad.osu.edu (164.107.81.174) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 17 Sep 2012 15:22:59 +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; Mon, 17 Sep 2012 11:22:59 -0400 From: "Cantor, Scott" To: "kitten@ietf.org" Thread-Topic: Minting URIs for a draft? Thread-Index: AQHNlOhRqKwlbQtHoEakQFd6UnT4aA== Date: Mon, 17 Sep 2012 15:22:58 +0000 Message-ID: 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-OriginatorOrg: ociotest.osu.edu Subject: [kitten] Minting URIs for a draft? 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, 17 Sep 2012 15:23:05 -0000 Is there any mechanism to mint URIs out of the IETF's namespace for my SAMLEC draft, or is that just left to the final publication step? There's no registry involved, so I wondered if there was an expedited way to do it ahead of time. Or should I not use IETF's domain for this and pick something else? I can't really use OASIS because it's not an OASIS spec, but I could artificially mint some URIs in an OASIS document to get around that. -- Scott From stpeter@stpeter.im Mon Sep 17 08:26: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 5BB2321F8722 for ; Mon, 17 Sep 2012 08:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.641 X-Spam-Level: X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 lezg1zcAqlVQ for ; Mon, 17 Sep 2012 08:26:00 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 69DC421F86FE for ; Mon, 17 Sep 2012 08:26:00 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9DE2A40D96; Mon, 17 Sep 2012 09:26:58 -0600 (MDT) Message-ID: <50574106.9000603@stpeter.im> Date: Mon, 17 Sep 2012 09:25:58 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Cantor, Scott" References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] Minting URIs for a draft? 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, 17 Sep 2012 15:26:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/17/12 9:22 AM, Cantor, Scott wrote: > Is there any mechanism to mint URIs out of the IETF's namespace for > my SAMLEC draft, or is that just left to the final publication > step? You could use the urn:ietf: tree. > There's no registry involved, so I wondered if there was an > expedited way to do it ahead of time. > > Or should I not use IETF's domain for this You should not use http://www.ietf.org/ as the base for generating namespace URIs. > and pick something else? I can't really use OASIS because it's not > an OASIS spec, but I could artificially mint some URIs in an OASIS > document to get around that. I'd recommend IETF URNs. See registration examples here: http://tools.ietf.org/html/rfc6120#section-14 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/ iEYEARECAAYFAlBXQQYACgkQNL8k5A2w/vwLGgCbBpGRAJ8Wg5tLAOUGKgQfukmV JaMAoLPqryuzpDmwAFBiXh7JV82jsRFc =cLP/ -----END PGP SIGNATURE----- From cantor.2@osu.edu Mon Sep 17 08:36: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 74C1921F8667 for ; Mon, 17 Sep 2012 08:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 InpydA1LRm3x for ; Mon, 17 Sep 2012 08:36:36 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id A097521F8658 for ; Mon, 17 Sep 2012 08:36:34 -0700 (PDT) Received: from mail162-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Sep 2012 15:36:33 +0000 Received: from mail162-tx2 (localhost [127.0.0.1]) by mail162-tx2-R.bigfish.com (Postfix) with ESMTP id E1FD94A0156; Mon, 17 Sep 2012 15:36:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.168; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT05.osuad.osu.edu; RD:cio-tnc-ht05.osuad.osu.edu; EFVD:NLI X-SpamScore: -24 X-BigFish: VS-24(zzbb2dI98dI9371I1432I1447Id6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2fh87h2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail162-tx2: domain of osu.edu designates 164.107.81.168 as permitted sender) client-ip=164.107.81.168; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT05.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail162-tx2 (localhost.localdomain [127.0.0.1]) by mail162-tx2 (MessageSwitch) id 1347896192591637_22573; Mon, 17 Sep 2012 15:36:32 +0000 (UTC) Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.248]) by mail162-tx2.bigfish.com (Postfix) with ESMTP id 83A7E100046; Mon, 17 Sep 2012 15:36:32 +0000 (UTC) Received: from CIO-TNC-HT05.osuad.osu.edu (164.107.81.168) by TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 17 Sep 2012 15:36:24 +0000 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, 17 Sep 2012 11:36:16 -0400 From: "Cantor, Scott" To: Peter Saint-Andre Thread-Topic: [kitten] Minting URIs for a draft? Thread-Index: AQHNlOhRqKwlbQtHoEakQFd6UnT4aJeO6rYA//+/zgA= Date: Mon, 17 Sep 2012 15:36:16 +0000 Message-ID: In-Reply-To: <50574106.9000603@stpeter.im> 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: <64A35ADBF175E9478159960C54899C6F@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [kitten] Minting URIs for a draft? 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, 17 Sep 2012 15:36:36 -0000 On 9/17/12 11:25 AM, "Peter Saint-Andre" wrote: > >I'd recommend IETF URNs. See registration examples here: > >http://tools.ietf.org/html/rfc6120#section-14 Thanks for the pointer. The XML REG RFC doesn't actually mention the use case I have, which is for a URI constant, not an XML namespace or any of the other types of identifiers mentioned. Is that a problem? -- Scott From stpeter@stpeter.im Mon Sep 17 08:56: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 3D0EC21F8704 for ; Mon, 17 Sep 2012 08:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 xOuHOSGOv4gJ for ; Mon, 17 Sep 2012 08:56:53 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0C121F86EE for ; Mon, 17 Sep 2012 08:56:53 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0741B40D52; Mon, 17 Sep 2012 09:57:51 -0600 (MDT) Message-ID: <50574844.10500@stpeter.im> Date: Mon, 17 Sep 2012 09:56:52 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: cantor.2@osu.edu References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] Minting URIs for a draft? 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, 17 Sep 2012 15:56:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/17/12 9:38 AM, Cantor, Scott wrote: > On 9/17/12 11:36 AM, "Cantor, Scott" wrote: > >> On 9/17/12 11:25 AM, "Peter Saint-Andre" >> wrote: >>> >>> I'd recommend IETF URNs. See registration examples here: >>> >>> http://tools.ietf.org/html/rfc6120#section-14 >> >> Thanks for the pointer. The XML REG RFC doesn't actually mention >> the use case I have, which is for a URI constant, not an XML >> namespace or any of the other types of identifiers mentioned. Is >> that a problem? > > Answering my own question, it would seem so, since they're trying > to carve out consistent subtrees for the various kinds of > identifiers, and mine don't qualify as any of them. > > (Informationally, they're key derivation algorithm URIs for use > with XML Encryption syntax.) Could you provide a few examples? They might be similar to some identifiers that led me to think we might want a urn:iana: tree. 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/ iEYEARECAAYFAlBXSEMACgkQNL8k5A2w/vx8YgCg4BX9Vlfl6ObYIOcx5u6DXNTp 6hQAoPwFxvIoWIJPAuk81IrFQEyer7pa =mQf8 -----END PGP SIGNATURE----- From cantor.2@osu.edu Mon Sep 17 09:03: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 8F7AC21F84FD for ; Mon, 17 Sep 2012 09:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.813 X-Spam-Level: X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 z93Q9TKlcjSz for ; Mon, 17 Sep 2012 09:03:07 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id A308B21F84F8 for ; Mon, 17 Sep 2012 09:03:07 -0700 (PDT) Received: from mail160-co1-R.bigfish.com (10.243.78.234) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Sep 2012 16:03:06 +0000 Received: from mail160-co1 (localhost [127.0.0.1]) by mail160-co1-R.bigfish.com (Postfix) with ESMTP id 7CA57800121; Mon, 17 Sep 2012 16:03:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.37; KIP:(null); UIP:(null); IPV:NLI; H:CIO-KRC-HT01.osuad.osu.edu; RD:cio-krc-ht01.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202h1d1ah1d2ahzz17326ah8275dhz2fh87h2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail160-co1: domain of osu.edu designates 164.107.81.37 as permitted sender) client-ip=164.107.81.37; envelope-from=cantor.2@osu.edu; helo=CIO-KRC-HT01.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail160-co1 (localhost.localdomain [127.0.0.1]) by mail160-co1 (MessageSwitch) id 1347897784233915_31254; Mon, 17 Sep 2012 16:03:04 +0000 (UTC) Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.238]) by mail160-co1.bigfish.com (Postfix) with ESMTP id 3721EA00047; Mon, 17 Sep 2012 16:03:04 +0000 (UTC) Received: from CIO-KRC-HT01.osuad.osu.edu (164.107.81.37) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 17 Sep 2012 16:03:02 +0000 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, 17 Sep 2012 12:02:50 -0400 From: "Cantor, Scott" To: Peter Saint-Andre Thread-Topic: [kitten] Minting URIs for a draft? Thread-Index: AQHNlOhRqKwlbQtHoEakQFd6UnT4aJeO6rYA//+/zgCAAAC3AIAASB0A//++mAA= Date: Mon, 17 Sep 2012 16:02:50 +0000 Message-ID: In-Reply-To: <50574844.10500@stpeter.im> 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-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [kitten] Minting URIs for a draft? 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, 17 Sep 2012 16:03:08 -0000 On 9/17/12 11:56 AM, "Peter Saint-Andre" wrote: >>Answering my own question, it would seem so, since they're trying >> to carve out consistent subtrees for the various kinds of >> identifiers, and mine don't qualify as any of them. >>=20 >> (Informationally, they're key derivation algorithm URIs for use >> with XML Encryption syntax.) > >Could you provide a few examples? They might be similar to some >identifiers that led me to think we might want a urn:iana: tree. Well, the existing algorithms are limited to: http://www.w3.org/2009/xmlenc11#ConcatKDF http://www.w3.org/2009/xmlenc11#pbkdf2 I'm using the syntax to handle communicating the derivation mechanisms I'm putting into my mechanism for the more common case of bearer tokens, one of which is using the TLS-Exporter mechanism and the other is just a dummy mechanism for the insecure case of generating a client nonce to use as a key. I need that for apps that require GSS session keys even if it's not really secure. Were I using W3C identifiers, they'd be something like http://www.w3.org/2009/xmlenc11#client-generated http://www.w3.org/2009/xmlenc11#tls-exporter -- Scott From internet-drafts@ietf.org Mon Sep 17 12:17: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 D3D8D21F8432; Mon, 17 Sep 2012 12:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 dcluXA2B1oc0; Mon, 17 Sep 2012 12:17:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5984621F842A; Mon, 17 Sep 2012 12:17:44 -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: <20120917191744.27677.4879.idtracker@ietfa.amsl.com> Date: Mon, 17 Sep 2012 12:17:44 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-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, 17 Sep 2012 19:17:45 -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-03.txt Pages : 33 Date : 2012-09-17 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-saml-ec-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cantor.2@osu.edu Mon Sep 17 12:25: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 25B7721F84A5 for ; Mon, 17 Sep 2012 12:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.804 X-Spam-Level: X-Spam-Status: No, score=-3.804 tagged_above=-999 required=5 tests=[AWL=-0.205, 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 dhkMjRlRNN37 for ; Mon, 17 Sep 2012 12:25:19 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 20E4621F8432 for ; Mon, 17 Sep 2012 12:25:18 -0700 (PDT) Received: from mail153-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Sep 2012 19:25:17 +0000 Received: from mail153-ch1 (localhost [127.0.0.1]) by mail153-ch1-R.bigfish.com (Postfix) with ESMTP id A9CCE240361 for ; Mon, 17 Sep 2012 19:25:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.43; KIP:(null); UIP:(null); IPV:NLI; H:CIO-KRC-HT03.osuad.osu.edu; RD:cio-krc-ht03.osuad.osu.edu; EFVD:NLI X-SpamScore: 1 X-BigFish: VS1(zzd6f1izz1202h1d1ah1d2ahzzz2fh87h2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail153-ch1: domain of osu.edu designates 164.107.81.43 as permitted sender) client-ip=164.107.81.43; envelope-from=cantor.2@osu.edu; helo=CIO-KRC-HT03.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail153-ch1 (localhost.localdomain [127.0.0.1]) by mail153-ch1 (MessageSwitch) id 1347909915385294_2108; Mon, 17 Sep 2012 19:25:15 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail153-ch1.bigfish.com (Postfix) with ESMTP id 5B9B6380054 for ; Mon, 17 Sep 2012 19:25:15 +0000 (UTC) Received: from CIO-KRC-HT03.osuad.osu.edu (164.107.81.43) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 17 Sep 2012 19:25:14 +0000 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, 17 Sep 2012 15:25:13 -0400 From: "Cantor, Scott" To: "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-03.txt Thread-Index: AQHNlQkgd3D+REs5e0uwza2nMWocnJeO6jyA Date: Mon, 17 Sep 2012 19:25:13 +0000 Message-ID: In-Reply-To: <20120917191744.27677.4879.idtracker@ietfa.amsl.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: <19215EC1ACCA524A8428C78D91EFE5A6@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-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, 17 Sep 2012 19:25:20 -0000 The changes in this revision are in two areas: I substantially revised the GSS name section to reflect my understand of issues raised by the OAuth discussion and my own preferences. I settled on new language around how the default name types for users and services get used, rules for mapping the authenticated SAML subject to a the user name type, explicit notes about anonymous cases, and a bit more wording on use of naming attributes. I added, at Simon's request of many months ago, a spec for using TLS exported session keys, including defining a new EXPORTER label that will have to be registered. I don't really think most GSS implementations could ever do this, but it doesn't hurt to specify it since it's a heck of a lot stronger than the alternative I'm left with. Pending review by implementers and experts, this is feature complete, and I expect to advance the OASIS drafts this depends on fairly soon now. -- Scott From wmills@yahoo-inc.com Tue Sep 18 09:16: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 B0E2021E80F8 for ; Tue, 18 Sep 2012 09:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.231 X-Spam-Level: X-Spam-Status: No, score=-16.231 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_50=0.001, 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 nhzEisJJbL5a for ; Tue, 18 Sep 2012 09:16:45 -0700 (PDT) Received: from nm24-vm3.bullet.mail.ne1.yahoo.com (nm24-vm3.bullet.mail.ne1.yahoo.com [98.138.91.154]) by ietfa.amsl.com (Postfix) with SMTP id E2FDA21E80EE for ; Tue, 18 Sep 2012 09:16:44 -0700 (PDT) Received: from [98.138.226.179] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 16:16:40 -0000 Received: from [98.138.88.236] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 16:16:40 -0000 Received: from [127.0.0.1] by omp1036.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 16:16:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 259116.99812.bm@omp1036.mail.ne1.yahoo.com Received: (qmail 30768 invoked by uid 60001); 18 Sep 2012 16:16:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1347984999; bh=mWQmrwevppZ7HIJfuLSEyJWeGGw7csoXVpMdekb0CXk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=pM6k4Sasz1mJubnOiorMlYRxAHnPUmIov0pvf9BrWLIfRSBZ/Vw11kQbCy1/bX4maOGz+m7SHWlC2qS9oanJoGlqsIY197NhdZ4OWK6V/uNsixHw7Syj3+a3lU3pq21P4u1fcxAC9NtTaYpofjM4IufmsL+6ppB8yoylZHWPLik= 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=MEadG6Rv6icmJzjvygz6rue6mUauuZ3ACLJPGEGiDpQ/5qCKLPRmTZptWEjkqy9DMhgeprv/y8sL31ZQbkTLdbFKbtJWpXLeYYGGcEg39rbwhI5QukgPy533Gy1K5MEyHs6ffFcSWylpZLauA7N4W7/3UacahfSfTIuBLZZHIng=; X-YMail-OSG: l.lWwhsVM1kUWtQa7p_yDS6YBsaQlFtvYZRMrN57r3fDv00 qRxtroJDfRBJC3DG2f7lTMg.08df5UgHsazi7jh7y0zGmedTeoC8RgRMPEnU BoIWoHsGBLmPClaKHTIWh2xACbrXY5suyzLXbQBNuzquvy8.ThZ7V3Y.OJQe k8g3yy0ArKZ20FBljjMV1DbFY3syrYYp8CS0lfQt8kC9QOMIP6itpThEGdNM hRwmEk04z2fYzgHs__LY_MnZLXNFxa6aQ68bxGjSPTiPH36LQyWkJvP.Fd8i pAG9C2dkMs97tb8IUlVMDvW5LHRmiP82FaL33SThjWg.KQOngUlVH53EEhNb b.0yoA8hPQD7oA98JGjDKQYHsdFT9YRZQWU9IXNrHwbmoV.i2d.PIOxCM75B Pa2Q7EYGMShjjWXOf9KSWITdnJ1lKzvrCm0onIb15p8TCkQJzlK4- Received: from [209.131.62.113] by web31813.mail.mud.yahoo.com via HTTP; Tue, 18 Sep 2012 09:16:39 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 Message-ID: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Tue, 18 Sep 2012 09:16:39 -0700 (PDT) From: William Mills To: Ryan Troll , "kitten@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-1574629422-1347984999=:13150" Subject: [kitten] Google and 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: Tue, 18 Sep 2012 16:16:46 -0000 --767760015-1574629422-1347984999=:13150 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0AGoogle has released XOAUTH2 support which looks like it's based on -0= 3 of the SASL OAuth draft.=A0 Since then the user=3D element has been remov= ed.=A0 At this point user can easily be added back in as an optional KV pai= r.=A0 My question is whether we should do that with a "MAY" just to explici= tly make the changes to XOAUTH2 implementations be minimal (if any).=A0 =0A= =0A=0AI'm leaning toward the "working code" argument here.=A0 Thoughts?=0A= =0AThanks,=0A=0A-bill=0A --767760015-1574629422-1347984999=:13150 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=
Google has released XOAUTH2 support which looks = like it's based on -03 of the SASL OAuth draft.  Since then the user= =3D element has been removed.  At this point user can easily be added = back in as an optional KV pair.  My question is whether we should do t= hat with a "MAY" just to explicitly make the changes to XOAUTH2 implementat= ions be minimal (if any). 

I'm leaning toward the "working code" argument here.&nbs= p; Thoughts?

Thank= s,

-bill
=
--767760015-1574629422-1347984999=:13150-- From nico@cryptonector.com Tue Sep 18 09: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 2B39821F84E2 for ; Tue, 18 Sep 2012 09:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=-0.160, 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 XyeebUWTkEIr for ; Tue, 18 Sep 2012 09:33:06 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2694C21F862A for ; Tue, 18 Sep 2012 09:33:06 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id D3F8926405D for ; Tue, 18 Sep 2012 09:33: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=y1vQ14uOpgCi1rZIE8nS O+tidy0=; b=yAiuNCEn3I3/khTvnMDygRgYxGBTdoFyEgZ83syiJqki0Fic1kr3 +6m70FV1unZ0INUzJoArQzE50ponCQIjZrpN3vpArZtJzwYD00zJYNZ8jdkKSD3Q jF4JcMtDgA0oHOnUg8uAbFQYPJR7GyEkwMnj186y65LCkdbay0y1e0M= 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-a88.g.dreamhost.com (Postfix) with ESMTPSA id B3CB426404E for ; Tue, 18 Sep 2012 09:33:05 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so331274pbb.31 for ; Tue, 18 Sep 2012 09:33:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.77.7 with SMTP id o7mr483313paw.37.1347985985090; Tue, 18 Sep 2012 09:33:05 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 18 Sep 2012 09:33:05 -0700 (PDT) In-Reply-To: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Tue, 18 Sep 2012 11:33:05 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 16:33:07 -0000 On Tue, Sep 18, 2012 at 11:16 AM, William Mills wrote: > Google has released XOAUTH2 support which looks like it's based on -03 of > the SASL OAuth draft. Since then the user= element has been removed. At > this point user can easily be added back in as an optional KV pair. My > question is whether we should do that with a "MAY" just to explicitly make > the changes to XOAUTH2 implementations be minimal (if any). > > I'm leaning toward the "working code" argument here. Thoughts? I would say that unknown KV keys MUST be ignored by the server. Also, the maintainer of that implementation should be informed of this change. Nico -- From nico@cryptonector.com Tue Sep 18 09:37: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 D9CDF21F864A for ; Tue, 18 Sep 2012 09:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=-0.154, 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 0niv6P7ZaswI for ; Tue, 18 Sep 2012 09:37:21 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1B55921F862A for ; Tue, 18 Sep 2012 09:37:21 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id C7DE81DE081 for ; Tue, 18 Sep 2012 09:37:20 -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=GIBC2yctvTthoIQBDWaq VIuIFso=; b=P90SPG2Qi8a2D/J5dhlUKesAppVaKRNwgSJgaaTKH2PQnweQJYJy ZhCMHIK7VsXu3izkYCmpJwD6wwZP7r8pU1KqPzuYgY4Dh6UeJlV2BziMUBxnTZjM 2uOIvx5+ZbLVbm5A3KG2vgX/WxQqmD/IfENiAqwfsUYdRErnI0Fk8b4= 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 A54F61DE086 for ; Tue, 18 Sep 2012 09:37:20 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so339169pbb.31 for ; Tue, 18 Sep 2012 09:37:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.73 with SMTP id ra9mr523744pbc.85.1347986240339; Tue, 18 Sep 2012 09:37:20 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 18 Sep 2012 09:37:20 -0700 (PDT) In-Reply-To: References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Tue, 18 Sep 2012 11:37:20 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 16:37:22 -0000 Also, is that a client-only implementation? Sending an unnecessary KV is not very harmful. Expecting one on the server side is. From hannes.tschofenig@gmx.net Tue Sep 18 10:32: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 A364921E80CB for ; Tue, 18 Sep 2012 10:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.301 X-Spam-Level: X-Spam-Status: No, score=-102.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 lV2P80oLcjoP for ; Tue, 18 Sep 2012 10:32:23 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8276E21E8043 for ; Tue, 18 Sep 2012 10:32:22 -0700 (PDT) Received: (qmail invoked by alias); 18 Sep 2012 17:32:21 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.216.191] by mail.gmx.net (mp031) with SMTP; 18 Sep 2012 19:32:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18kcc5QCN4kGW4lOimkuSdsucTvhVqms2JMez+Pb/ 23e7jyaoNKvMeg Message-ID: <5058B024.4060601@gmx.net> Date: Tue, 18 Sep 2012 20:32:20 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: William Mills References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> In-Reply-To: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 17:32:23 -0000 Hi Bill, I have only seen the info at this page https://developers.google.com/talk/jep_extensions/oauth and it does not give me enough details to judge whether there is similarity to the SASL OAuth draft. Ryan, who is on CC, seems to be the lead developer (as I can understand from http://googledevelopers.blogspot.nl/2012/09/adding-oauth-20-support-for-imapsmtp.html). Ryan, can you shed some light on the relationship to OAuth SASL. Of course it would be good to see that work had been re-used and is deployed in Google. I would also be interested to hear the motivation for omitting the user element. Ciao Hannes On 09/18/2012 07:16 PM, William Mills wrote: > > Google has released XOAUTH2 support which looks like it's based on -03 > of the SASL OAuth draft. Since then the user= element has been > removed. At this point user can easily be added back in as an optional > KV pair. My question is whether we should do that with a "MAY" just to > explicitly make the changes to XOAUTH2 implementations be minimal (if any). > > I'm leaning toward the "working code" argument here. Thoughts? > > Thanks, > > -bill > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From rtroll@google.com Tue Sep 18 10: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 67F6C21E8043 for ; Tue, 18 Sep 2012 10:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 EahNLfE2tZoE for ; Tue, 18 Sep 2012 10:47:04 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3FA21F851C for ; Tue, 18 Sep 2012 10:47:04 -0700 (PDT) Received: by iec9 with SMTP id 9so137665iec.31 for ; Tue, 18 Sep 2012 10:47:04 -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=bYacowBnfxWLKzH8V+vIOU9rrqMiRGNRzCX+K4+e/4I=; b=FNSW22VcMtDtxYrpWvcvM3TDSsEkCpwPVtKd0aAJgzvyKBN7+cmKnnEhVPurr0b3Y/ bxuFRXqFplxs24e/HH+lo2bhxFwM7VQw0vV6oixVE3Y2rfjWMuECmhHv3eCXt4Ld1FIX 0+7MMJGCsC2aBy9BNR/xe5MFVf+/cKQBGMosI= 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=bYacowBnfxWLKzH8V+vIOU9rrqMiRGNRzCX+K4+e/4I=; b=dY8jfHPBwqhHEkOl0NNsUgdGqSbksxN9OdEA9grskc2lzhQLn1pwgFd7W+s6KgpKX2 OvI9uQFEs6y3mJCRxEDCmHQApOzrB3vs/AAVXBoRH/cD5C9CSjtnoGpS490DZySQcdl0 +5CfHzO/xU8idhsuSV/8OHXWg4/LNOxLNHuJT8pmpy5U2wZjQWotDyzKrGPT1GGIT0qQ E3w/0/OXd4Z4LBqd/OoLwZO774lXQ6RG8SIGSAdEpQg4NCkAZTF3pwdHhKLiQ+hcJDFi 4qMIRWjqGQ/7IeYu68DTRcBz/7o+Nf2G8rsfvJWG0WtRGgdrmfPuoEEHHgNKaf+Bv7Vz 9pvw== Received: by 10.50.40.133 with SMTP id x5mr363609igk.57.1347990424100; Tue, 18 Sep 2012 10:47:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.40.133 with SMTP id x5mr363593igk.57.1347990423905; Tue, 18 Sep 2012 10:47:03 -0700 (PDT) Received: by 10.50.36.131 with HTTP; Tue, 18 Sep 2012 10:47:03 -0700 (PDT) In-Reply-To: <5058B024.4060601@gmx.net> References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> Date: Tue, 18 Sep 2012 10:47:03 -0700 Message-ID: From: Ryan Troll To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=14dae93403d960a47604c9fd7a3b X-System-Of-Record: true X-Gm-Message-State: ALoCoQlimUcCmsjjLvu4SdjnBYH8AlqbmDLeaARPagA3sZ3RR6eHK28ge/qY4nP3O8GG2nSNNzOvKv8wxnPdpJ0g/XAY0qRyryAtzfMCU1QcWh/YvpQdbte/ZOnS92YpxtqXNn+UXCp9jC2HWZNFHJw6qZ2o+c6pC5otznUN7uCyU3vo1v34lqI511Cw3FgHE/P3Sec8dj1t Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 17:47:05 -0000 --14dae93403d960a47604c9fd7a3b Content-Type: text/plain; charset=ISO-8859-1 Sure. A little history: - The XMPP implementation has been around for quite a while, and used as part of a larger product. When I started looking at SASL/OAuth, this was already available, documentation ready, and about to be announced publicly. Rather than have separate announcements, we merged their announcement with the IMAP/SMTP announcement. - The IMAP/SMTP implementation was started more recently, and is based on version -03 of the spec. In both cases, the mechanism name does not match the spec. This approach allowed us to launch without waiting for the draft, and provides us a simple way to introduce RFC compliance later without breaking any work previously done. Once the draft moves to RFC status, I'm planning on working with the teams to add support for the RFC-defined mechanism. Now that our systems support dealing with the OAuth 2.0 credential, the work should be minimal. As for omitting the user information, your basically looking at why I had originally asked to add this field as Optional -- not all services benefit from it. I'm not familiar enough with our XMPP service to explain why, while our IMAP and SMTP implementations do use it. Bill: Thanks for considering adding the user= field in order to make the move from XOAUTH2 to this standard easier, but I'm not sure it's worth it. If the GS2 header is required, the data is already there, and clients that wish to add OAUTH support to their XOAUTH2 client will simple reformat the request a bit. -R On Tue, Sep 18, 2012 at 10:32 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Bill, > > I have only seen the info at this page https://developers.google.com/** > talk/jep_extensions/oauthand it does not give me enough details to judge whether there is similarity > to the SASL OAuth draft. > > Ryan, who is on CC, seems to be the lead developer (as I can understand > from http://googledevelopers.**blogspot.nl/2012/09/adding-** > oauth-20-support-for-imapsmtp.**html). > Ryan, can you shed some light on the relationship to OAuth SASL. > > Of course it would be good to see that work had been re-used and is > deployed in Google. I would also be interested to hear the motivation for > omitting the user element. > > Ciao > Hannes > > > On 09/18/2012 07:16 PM, William Mills wrote: > >> >> Google has released XOAUTH2 support which looks like it's based on -03 >> of the SASL OAuth draft. Since then the user= element has been >> removed. At this point user can easily be added back in as an optional >> KV pair. My question is whether we should do that with a "MAY" just to >> explicitly make the changes to XOAUTH2 implementations be minimal (if >> any). >> >> I'm leaning toward the "working code" argument here. Thoughts? >> >> Thanks, >> >> -bill >> >> >> ______________________________**_________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/**listinfo/kitten >> >> > --14dae93403d960a47604c9fd7a3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sure. =A0A little history:

- The XMPP implementation has= been around for quite a while, and used as part of a larger product. =A0Wh= en I started looking at SASL/OAuth, this was already available, documentati= on ready, and about to be announced publicly. =A0Rather than have separate = announcements, we merged their announcement with the IMAP/SMTP announcement= .

- The IMAP/SMTP implementation was started more recentl= y, and is based on version -03 of the spec.

In bot= h cases, the mechanism name does not match the spec. =A0This approach allow= ed us to launch without waiting for the draft, and provides us a simple way= to introduce RFC compliance later without breaking any work previously don= e.

Once the draft moves to RFC status, I'm planning on= working with the teams to add support for the RFC-defined mechanism. =A0No= w that our systems support dealing with the OAuth 2.0 credential, the work = should be minimal.


As for omitting the user information, yo= ur basically looking at why I had originally asked to add this field as Opt= ional -- not all services benefit from it. =A0I'm not familiar enough w= ith our XMPP service to explain why, while our IMAP and SMTP implementation= s do use it.=A0

Bill:

Thanks for considering a= dding the user=3D field in order to make the move from XOAUTH2 to this stan= dard easier, but I'm not sure it's worth it. =A0If the GS2 header i= s required, the data is already there, and clients that wish to add OAUTH s= upport to their XOAUTH2 client will simple reformat the request a bit.

-R


On Tue, Sep 18, 2012 at 10:32 AM, Hannes Tschofenig &= lt;hannes.ts= chofenig@gmx.net> wrote:
Hi Bill,

I have only seen the info at this page https://developers.google= .com/talk/jep_extensions/oauth and it does not give me enough de= tails to judge whether there is similarity to the SASL OAuth draft.

Ryan, who is on CC, seems to be the lead developer (as I can understand fro= m http://googledevelopers.b= logspot.nl/2012/09/adding-oauth-20-support-for-imapsmtp.html<= /a>). Ryan, can you shed some light on the relationship to OAuth SASL.

Of course it would be good to see that work had been re-used and is deploye= d in Google. I would also be interested to hear the motivation for omitting= the user element.

Ciao
Hannes


On 09/18/2012 07:16 PM, William Mills wrote:

Google has released XOAUTH2 support which looks like it's based on -03<= br> of the SASL OAuth draft. =A0Since then the user=3D element has been
removed. =A0At this point user can easily be added back in as an optional KV pair. =A0My question is whether we should do that with a "MAY"= just to
explicitly make the changes to XOAUTH2 implementations be minimal (if any).=

I'm leaning toward the "working code" argument here. =A0Thoug= hts?

Thanks,

-bill


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



--14dae93403d960a47604c9fd7a3b-- From wmills@yahoo-inc.com Tue Sep 18 11:41: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 38A4621E80C1 for ; Tue, 18 Sep 2012 11:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.637 X-Spam-Level: X-Spam-Status: No, score=-16.637 tagged_above=-999 required=5 tests=[AWL=-0.705, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666, 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 d7cyb30kfLqM for ; Tue, 18 Sep 2012 11:41:09 -0700 (PDT) Received: from nm36-vm1.bullet.mail.ne1.yahoo.com (nm36-vm1.bullet.mail.ne1.yahoo.com [98.138.229.113]) by ietfa.amsl.com (Postfix) with SMTP id 1131521E8034 for ; Tue, 18 Sep 2012 11:41:08 -0700 (PDT) Received: from [98.138.226.179] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 18:41:05 -0000 Received: from [98.138.88.239] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 18:41:05 -0000 Received: from [127.0.0.1] by omp1039.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 18:41:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 968514.75930.bm@omp1039.mail.ne1.yahoo.com Received: (qmail 18204 invoked by uid 60001); 18 Sep 2012 18:41:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1347993665; bh=HFjaIlldsCO+PSr7ThY1mohJ1pjoo/yriyKLFclMhJU=; 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=c4p0dH84hQQHenGgFfZDmUNs3CMezZnKJYuMjSm0kmL7+Aw6y1dZplOgs54kZMD6Ia3J52vwDWelqb9AqlqEDWI17fqLoIUu+/8k7+9WflfTdFFvevQfrd3cEsKU8OF3q4cRkz/M+bJPwSbTGYLE/mcbDrZ6feUu6IcYm0tFImk= 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=B13uKkBpoWsO9jCUI1niIdUfEvK7mnFcUNeDL3tDMyBZrrnQxGx7jbD8v4fcud9eA0kgRAwQi5TAgemeBlcpGvUSJyS03T/agY2I60EaJCC/7dlQYZgj5viCcLgEjCoxF8VcRtcoAQbSa+X7aKFTMuN55Z5ba7YAGv0QkJURryo=; X-YMail-OSG: nXnFLeAVM1lA_Ku6ItZw7KLN1Kdjd59R7H5KP1_xGOAFStZ VQvGCSMSl Received: from [209.131.62.113] by web31811.mail.mud.yahoo.com via HTTP; Tue, 18 Sep 2012 11:41:04 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> Message-ID: <1347993664.9147.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Tue, 18 Sep 2012 11:41:04 -0700 (PDT) From: William Mills To: Ryan Troll , Hannes Tschofenig In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-2018279676-1347993664=:9147" Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 18:41:10 -0000 --764183289-2018279676-1347993664=:9147 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Unfortunately the authz-id in the gs2-header is not mandatory according to = the spec, and I'm not allowed to make it mandatory in the mechanism.=A0 I t= hink you will end up needing to document that it is required for integratin= g with Google.=0A=0A=0A-bill=0A=0A=0A=0A=0A>_______________________________= _=0A> From: Ryan Troll =0A>To: Hannes Tschofenig =0A>Cc: William Mills ; "kitte= n@ietf.org" =0A>Sent: Tuesday, September 18, 2012 10:47 A= M=0A>Subject: Re: [kitten] Google and SASL OAuth=0A> =0A>=0A>Sure. =A0A lit= tle history:=0A>=0A>=0A>- The XMPP implementation has been around for quite= a while, and used as part of a larger product. =A0When I started looking a= t SASL/OAuth, this was already available, documentation ready, and about to= be announced publicly. =A0Rather than have separate announcements, we merg= ed their announcement with the IMAP/SMTP announcement.=0A>=0A>=0A>- The IMA= P/SMTP implementation was started more recently, and is based on version -0= 3 of the spec.=0A>=0A>=0A>In both cases, the mechanism name does not match = the spec. =A0This approach allowed us to launch without waiting for the dra= ft, and provides us a simple way to introduce RFC compliance later without = breaking any work previously done.=0A>=0A>=0A>Once the draft moves to RFC s= tatus, I'm planning on working with the teams to add support for the RFC-de= fined mechanism. =A0Now that our systems support dealing with the OAuth 2.0= credential, the work should be minimal.=0A>=0A>=0A>=0A>=0A>As for omitting= the user information, your basically looking at why I had originally asked= to add this field as Optional -- not all services benefit from it. =A0I'm = not familiar enough with our XMPP service to explain why, while our IMAP an= d SMTP implementations do use it.=A0=0A>=0A>=0A>Bill:=0A>=0A>=0A>Thanks for= considering adding the user=3D field in order to make the move from XOAUTH= 2 to this standard easier, but I'm not sure it's worth it. =A0If the GS2 he= ader is required, the data is already there, and clients that wish to add O= AUTH support to their XOAUTH2 client will simple reformat the request a bit= .=0A>=0A>=0A>-R=0A>=0A>=0A>=0A>=0A>On Tue, Sep 18, 2012 at 10:32 AM, Hannes= Tschofenig wrote:=0A>=0A>Hi Bill,=0A>>=0A>>I h= ave only seen the info at this page https://developers.google.com/talk/jep_= extensions/oauth and it does not give me enough details to judge whether th= ere is similarity to the SASL OAuth draft.=0A>>=0A>>Ryan, who is on CC, see= ms to be the lead developer (as I can understand from http://googledevelope= rs.blogspot.nl/2012/09/adding-oauth-20-support-for-imapsmtp.html). Ryan, ca= n you shed some light on the relationship to OAuth SASL.=0A>>=0A>>Of course= it would be good to see that work had been re-used and is deployed in Goog= le. I would also be interested to hear the motivation for omitting the user= element.=0A>>=0A>>Ciao=0A>>Hannes=0A>>=0A>>=0A>>On 09/18/2012 07:16 PM, Wi= lliam Mills wrote:=0A>>=0A>>=0A>>>Google has released XOAUTH2 support which= looks like it's based on -03=0A>>>of the SASL OAuth draft. =A0Since then t= he user=3D element has been=0A>>>removed. =A0At this point user can easily = be added back in as an optional=0A>>>KV pair. =A0My question is whether we = should do that with a "MAY" just to=0A>>>explicitly make the changes to XOA= UTH2 implementations be minimal (if any).=0A>>>=0A>>>I'm leaning toward the= "working code" argument here. =A0Thoughts?=0A>>>=0A>>>Thanks,=0A>>>=0A>>>-= bill=0A>>>=0A>>>=0A>>>=0A_______________________________________________=0A= >>>Kitten mailing list=0A>>>Kitten@ietf.org=0A>>>https://www.ietf.org/mailm= an/listinfo/kitten=0A>>>=0A>>>=0A>>=0A>=0A>=0A> --764183289-2018279676-1347993664=:9147 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Unfortuna= tely the authz-id in the gs2-header is not mandatory according to the spec,= and I'm not allowed to make it mandatory in the mechanism.  I think y= ou will end up needing to document that it is required for integrating with= Google.

-bill

From: Ryan Tr= oll <rtroll@googlers.com>
T= o: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Cc: William Mills <wmills@ya= hoo-inc.com>; "kitten@ietf.org" <kitten@ietf.org>
Sent: Tuesday, September 18, 2012 10:= 47 AM
Subject: Re: [ki= tten] Google and SASL OAuth

Sure.  A little history:

- The XMPP implementatio= n has been around for quite a while, and used as part of a larger product. =  When I started looking at SASL/OAuth, this was already available, doc= umentation ready, and about to be announced publicly.  Rather than hav= e separate announcements, we merged their announcement with the IMAP/SMTP announcement.
=0A

- The IMAP/SMTP implementation w= as started more recently, and is based on version -03 of the spec.

In both cases, the mechanism name does not match the spec.=  This approach allowed us to launch without waiting for the draft, an= d provides us a simple way to introduce RFC compliance later without breaki= ng any work previously done.
=0A

Once the draft mov= es to RFC status, I'm planning on working with the teams to add support for= the RFC-defined mechanism.  Now that our systems support dealing with= the OAuth 2.0 credential, the work should be minimal.
=0A


As for omitting the user information, your basically= looking at why I had originally asked to add this field as Optional -- not= all services benefit from it.  I'm not familiar enough with our XMPP = service to explain why, while our IMAP and SMTP implementations do use it.&= nbsp;
=0A

Bill:

Thanks for= considering adding the user=3D field in order to make the move from XOAUTH= 2 to this standard easier, but I'm not sure it's worth it.  If the GS2= header is required, the data is already there, and clients that wish to ad= d OAUTH support to their XOAUTH2 client will simple reformat the request a = bit.
=0A

-R


On Tue, Sep 18, 2012 at 10:32 AM, Hannes Tsch= ofenig <hannes.tschofenig@gmx.net> wrote:
=0A
Hi Bill,
=0A
=0AI have only seen the info= at this page https://developers.google.com/= talk/jep_extensions/oauth and it does not give me enough details to= judge whether there is similarity to the SASL OAuth draft.
=0A=0A
= =0ARyan, who is on CC, seems to be the lead developer (as I can understand = from http://googl= edevelopers.blogspot.nl/2012/09/adding-oauth-20-support-for-i= mapsmtp.html). Ryan, can you shed some light on the relationship= to OAuth SASL.
=0A=0A
=0AOf course it would be good to see that work= had been re-used and is deployed in Google. I would also be interested to = hear the motivation for omitting the user element.
=0A
=0ACiao
=0A= Hannes

=0A
=0AOn 09/18/2012 07:16= PM, William Mills wrote:
=0A
=0A
=0AGoogle has rele= ased XOAUTH2 support which looks like it's based on -03
=0Aof the SASL O= Auth draft.  Since then the user=3D element has been
=0Aremoved. &n= bsp;At this point user can easily be added back in as an optional
=0AKV = pair.  My question is whether we should do that with a "MAY" just to=0Aexplicitly make the changes to XOAUTH2 implementations be minimal (if = any).
=0A
=0AI'm leaning toward the "working code" argument here. &nb= sp;Thoughts?
=0A
=0AThanks,
=0A
=0A-bill
=0A
=0A
=0A_______________________________________________
=0AKitt= en mailing list
=0AKitten@ietf.org
= =0Ahttps://www.ietf.org/mailman/listinfo/kitten=
=0A
=0A
=0A
=0A

=0A
=

--764183289-2018279676-1347993664=:9147-- From wmills@yahoo-inc.com Tue Sep 18 11:43: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 8DB8121E8034 for ; Tue, 18 Sep 2012 11:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.436 X-Spam-Level: X-Spam-Status: No, score=-17.436 tagged_above=-999 required=5 tests=[AWL=0.162, 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 HS6OJ7X2rAsV for ; Tue, 18 Sep 2012 11:43:21 -0700 (PDT) Received: from nm19-vm0.bullet.mail.sp2.yahoo.com (nm19-vm0.bullet.mail.sp2.yahoo.com [98.139.91.216]) by ietfa.amsl.com (Postfix) with SMTP id E8C0821F84F1 for ; Tue, 18 Sep 2012 11:43:21 -0700 (PDT) Received: from [72.30.22.79] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 18 Sep 2012 18:43:10 -0000 Received: from [98.139.91.47] by tm13.bullet.mail.sp2.yahoo.com with NNFMP; 18 Sep 2012 18:43:10 -0000 Received: from [127.0.0.1] by omp1047.mail.sp2.yahoo.com with NNFMP; 18 Sep 2012 18:43:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 964486.45404.bm@omp1047.mail.sp2.yahoo.com Received: (qmail 30266 invoked by uid 60001); 18 Sep 2012 18:43:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1347993790; bh=8ofGdE0kO+udLGrT/f00NUOx6BYQxtqu5tjc1wpi5do=; 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=KJjdhcxguquKZqUbpok9/rPtH5V5DdhtSkHiy5O9d3d4P6qYStp2lSzDyPHrvWq5LxrYNWzS8TLkMJhdC2T2sRbTmQl8CKfs7niMhXgseQLZ8Ec/Wv2t7AlNeh3vChN7dFmglVbaQ2uDIMrIz9ovUjAqBxE/txCmE0GriJ3G43U= 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=LpXjjwjrz9pszP4VVUivkka+pQGgrqaMoUrU6UTOVRMZIxNuPqJ0ATFiu8Ef2aJ0Ge6g53YI2dvXF/9PgVa8d5nCkl2OHBZBpCGDVu5b8JC325gbjhADs//DT23VHO94qPI6Fbi4Dz1PcLDdG/+9d11DO49OStcmh+jZ0OEbRMk=; X-YMail-OSG: hCQ6li0VM1lm7hWZ504f0EBz39QooXe4d61Gl5WrFN8xwrC ZpD3i2UBZo1LkD0igyZmL8hMIi6oWJbaywWfvewjo7ZitYo0UF0oIBgI18Ut 0gBLN7QuSBfBgHMGWQcUxc_LXQJLQYRAqX9ZpdGmDCmPNez5KhHc5ji4iQRL oLxSXCzeiTHPzSMuUTA2jIXWhCPcmuS7_KAVcUWsYh0k5lSNtX2LvldB9_2e eYZLRRAkdEA7RcWcybSzF_3MwY9ElTu5oI1FQcItlcCb_qTqpr7BeZv4ry28 vVyYlv5Te2gpCCmfPXdW8Tg_FLVqCfstD60Rrq8wtVQDMHhcHy722XG4uaZ5 3suPt2kfxSLPl1Fz3vHq8nrmkuTjRW0rJaV2PMqmNi3uZCrov4I.nTN57UgZ kNzRzxk6r6jepGZ9wh.Pc66I7B1cEfs__4BMKg9bpQ_.q5gdPu2rrUZvyM_4 vIMbM7vAdzJcbYzRzkCjbwizCMGZyukVyoq5YKMJSTHr7HW8dNe01WcATw4N SE4eTNeII5K.WZHIXeaFsTA7awiEBGyIiRQ20iWonrVHOqytauO1U0z6ZM7s eyc.0WUGMmfOwtyvnGn7pcf2WN7PtijxjsGrAcMUtJ0rYWKSVvig0ADefyDa DToxhgfaQeHouMpFUUUGAZ14iaJCjVqgAaSzq1d2ZQt54lciQDk0DNlRypFs T3K50WDapldphPHVQOVjr_noc9YlaxjQ- Received: from [209.131.62.113] by web31808.mail.mud.yahoo.com via HTTP; Tue, 18 Sep 2012 11:43:10 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> Message-ID: <1347993790.16872.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 18 Sep 2012 11:43:10 -0700 (PDT) From: William Mills To: Hannes Tschofenig In-Reply-To: <5058B024.4060601@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-151806725-1347993790=:16872" Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 18:43:22 -0000 --258328648-151806725-1347993790=:16872 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hannes, =0A=0AAre you asking about omitting the user element from the draft= ?=A0 That was done because it's duplicating the data that may be carried in= the gs2-header authz-id and we don't want to have the same data element in= two places because if they disagree it's a problem (among other things).= =0A=0A-bill=0A=0A=0A=0A=0A=0A>________________________________=0A> From: Ha= nnes Tschofenig =0A>To: William Mills =0A>Cc: Ryan Troll ; "kitten@ietf.org" ; hannes.tschofenig@gmx.net =0A>Sent: Tuesday, September 18,= 2012 10:32 AM=0A>Subject: Re: [kitten] Google and SASL OAuth=0A> =0A>Hi Bi= ll,=0A>=0A>I have only seen the info at this page https://developers.google= .com/talk/jep_extensions/oauth and it does not give me enough details to ju= dge whether there is similarity to the SASL OAuth draft.=0A>=0A>Ryan, who i= s on CC, seems to be the lead developer (as I can understand from http://go= ogledevelopers.blogspot.nl/2012/09/adding-oauth-20-support-for-imapsmtp.htm= l). Ryan, can you shed some light on the relationship to OAuth SASL.=0A>=0A= >Of course it would be good to see that work had been re-used and is deploy= ed in Google. I would also be interested to hear the motivation for omittin= g the user element.=0A>=0A>Ciao=0A>Hannes=0A>=0A>On 09/18/2012 07:16 PM, Wi= lliam Mills wrote:=0A>> =0A>> Google has released XOAUTH2 support which loo= ks like it's based on -03=0A>> of the SASL OAuth draft.=A0 Since then the u= ser=3D element has been=0A>> removed.=A0 At this point user can easily be a= dded back in as an optional=0A>> KV pair.=A0 My question is whether we shou= ld do that with a "MAY" just to=0A>> explicitly make the changes to XOAUTH2= implementations be minimal (if any).=0A>> =0A>> I'm leaning toward the "wo= rking code" argument here.=A0 Thoughts?=0A>> =0A>> Thanks,=0A>> =0A>> -bill= =0A>> =0A>> =0A>> _______________________________________________=0A>> Kitt= en mailing list=0A>> Kitten@ietf.org=0A>> https://www.ietf.org/mailman/list= info/kitten=0A>> =0A>=0A>=0A>=0A> --258328648-151806725-1347993790=:16872 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hannes, <= br>
Are you asking about omitting the user element from the draft? = That was done because it's duplicating the data that may be carried in the= gs2-header authz-id and we don't want to have the same data element in two= places because if they disagree it's a problem (among other things).
-bill


From: Hannes Tschofenig <hannes.tschofenig@gmx.net>= ;
To: William Mills <wmi= lls@yahoo-inc.com>
Cc:<= /b> Ryan Troll <rtroll@googlers.com>; "kitten@ietf.org" <kitten@ie= tf.org>; hannes.tschofenig@gmx.net
Sent: Tuesday, September 18, 2012 10:32 AM
Subject: Re: [kitten] Google and SASL= OAuth

Hi Bill,

I have only seen the info at = this page https://developers.google.com/talk/jep_extensions/oaut= h and it does not give me enough details to judge whether there is simi= larity to the SASL OAuth draft.

Ryan, who is on CC, seems to be the = lead developer (as I can understand from http://googledevelopers.blogspot.nl/2012/09/adding-oauth= -20-support-for-imapsmtp.html). Ryan, can you shed some light on the re= lationship to OAuth SASL.

Of course it would be good to see that wor= k had been re-used and is deployed in Google. I would also be interested to= hear the motivation for omitting the user element.

Ciao
Hannes
On 09/18/2012 07:16 PM, William Mills wrote:
>
> Google = has released XOAUTH2 support which looks like it's based on -03
> of = the SASL OAuth draft.  Since then the user=3D element has been
>= removed.  At this point user can easily be added back in as an option= al
> KV pair.  My question is whether we should do that with a "= MAY" just to
> explicitly make the changes to XOAUTH2 implementations= be minimal (if any).
>
> I'm leaning toward the "working code= " argument here.  Thoughts?
>
> Thanks,
>
> -bill
>
>
> _________________________________= ______________
> Kitten mailing list
> Kitten@ietf.org
> <= a href=3D"https://www.ietf.org/mailman/listinfo/kitten" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/kitten
>



--258328648-151806725-1347993790=:16872-- From wmills@yahoo-inc.com Tue Sep 18 11: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 7F2BC21E80C1 for ; Tue, 18 Sep 2012 11:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.443 X-Spam-Level: X-Spam-Status: No, score=-17.443 tagged_above=-999 required=5 tests=[AWL=0.155, 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 I0rD3pBuEJ53 for ; Tue, 18 Sep 2012 11:48:14 -0700 (PDT) Received: from nm3-vm0.bullet.mail.ne1.yahoo.com (nm3-vm0.bullet.mail.ne1.yahoo.com [98.138.91.55]) by ietfa.amsl.com (Postfix) with SMTP id 9966321E8034 for ; Tue, 18 Sep 2012 11:48:14 -0700 (PDT) Received: from [98.138.90.56] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 18:48:10 -0000 Received: from [98.138.88.232] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 18:48:10 -0000 Received: from [127.0.0.1] by omp1032.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 18:48:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 406525.10890.bm@omp1032.mail.ne1.yahoo.com Received: (qmail 49142 invoked by uid 60001); 18 Sep 2012 18:48:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1347994089; bh=qUP6p2Q8GlTLyZjE6VnO5ptUJQ4Aia4Ug7I2cUPBDRo=; 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=jpvA+vDTr56/FRu+UTOhctc3nLpB39ueNnA5jVkSaPV40KylDKS1hsHVbjYVJKru3XA9IoVTZIm05bCtZJOJiPutaXpkv0cAgpsL/zNSpoD/bi6pq4TxKgSyo+MMJyT7BibhbtBaEwY3WhVHYZMARk9R9gK1NRL8DBTyjtz2BiI= 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=pyQ8eZ2ubU0q5oLqreMOWr1krT1SmLZI8Qcdb2Hp2a91nufO8ArB3UQYaMTyvFzCTU2V7OjVI4MfPZ6uuxaNo3ySS66XfxSWmo+r+oUqaOHxxBHQlKyQ/tHzForj7z99sDlpDRgs9b79zXYra+9f4eMEXuaJI6gnd+Ji6GIXaZ0=; X-YMail-OSG: eqDpuT0VM1ng3YZr8AZTHzkxJl9rDZ8trrlL0INI71.09Kg UBK4M2ln8vx19EsTR9wqKM3Gq4uzva6C4m2OR8Efen1_uiFjRU12XbJClmo1 OZIJ_kSK6hu08MNFlY2LeTtZsjX7xAwr.DZXZV0at7DL_4LM2gUbkguVyTQQ luSJMx2JvV8wN6BQDwwMeXZShF5Y348GLEuVvZToPoq7FZ1hewd2IhDyj0Sh DNBq_wgCfrQt_.y0j9uTvUU6sLFvZ5tOxfae3ZRXbEGIyYgjTkily39hZTh7 L1Y4zHEkNs5CqWTXNV5.djdzfacf4AIdf_40JwnHYz9Sx1x1NkNfty_XmO.S gCsTdVlSeI9p0rOr6lSCwpHwyajP4jjZVTWV_gCvAxCquvLgY.QUzmIPBgZh 3ajTj.oNHKCSN0XqcIXTftb9Z6Tl8Kf0pEoP4Efmqj23E_RNpRZkF.n.gb9i sS.0n3WI- Received: from [209.131.62.113] by web31802.mail.mud.yahoo.com via HTTP; Tue, 18 Sep 2012 11:48:09 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> Message-ID: <1347994089.21523.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Tue, 18 Sep 2012 11:48:09 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-945914819-1347994089=:21523" Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 18:48:15 -0000 ---1036955950-945914819-1347994089=:21523 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So leave "user" unregistered and make sure it won't cause conflict?=0A=0AI'= ve added "Unknown key/value pairs MUST be ignored by the server." to sectio= n 3.1.=0A=0A=0A=0A=0A=0A=0A=0A>________________________________=0A> From: N= ico Williams =0A>To: William Mills =0A>Cc: Ryan Troll ; "kitten@ietf.org" =0A>Sent: Tuesday, September 18, 2012 9:33 AM=0A>Subject: Re: [kit= ten] Google and SASL OAuth=0A> =0A>On Tue, Sep 18, 2012 at 11:16 AM, Willia= m Mills wrote:=0A>> Google has released XOAUTH2 supp= ort which looks like it's based on -03 of=0A>> the SASL OAuth draft.=A0 Sin= ce then the user=3D element has been removed.=A0 At=0A>> this point user ca= n easily be added back in as an optional KV pair.=A0 My=0A>> question is wh= ether we should do that with a "MAY" just to explicitly make=0A>> the chang= es to XOAUTH2 implementations be minimal (if any).=0A>>=0A>> I'm leaning to= ward the "working code" argument here.=A0 Thoughts?=0A>=0A>I would say that= unknown KV keys MUST be ignored by the server.=0A>=0A>Also, the maintainer= of that implementation should be informed of this change.=0A>=0A>Nico=0A>-= -=0A>=0A>=0A> ---1036955950-945914819-1347994089=:21523 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
So leave = "user" unregistered and make sure it won't cause conflict?

I've adde= d "Unknown key/value pairs MUST be ignored by the server." to section 3.1.<= br>



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> Sent: Tuesday, September= 18, 2012 9:33 AM
Subject:= Re: [kitten] Google and SASL OAuth

On Tue, Sep = 18, 2012 at 11:16 AM, William Mills <wmills@yahoo-inc.com> w= rote:
> Google has released XOAUTH2 support which looks like it's bas= ed on -03 of
> the SASL OAuth draft.  Since then the user=3D ele= ment has been removed.  At
> this point user can easily be added= back in as an optional KV pair.  My
> question is whether we sh= ould do that with a "MAY" just to explicitly make
> the changes to XO= AUTH2 implementations be minimal (if any).
>
> I'm leaning towa= rd the "working code" argument here.  Thoughts?

I would say tha= t unknown KV keys MUST be ignored by the server.

Also, the maintainer= of that implementation should be informed of this change.

Nico
-= -


---1036955950-945914819-1347994089=:21523-- From nico@cryptonector.com Tue Sep 18 11:57: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 D3D0D21E80C1 for ; Tue, 18 Sep 2012 11:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=-0.148, 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 eIWUqI7N8s9R for ; Tue, 18 Sep 2012 11:57:12 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 648D821E8034 for ; Tue, 18 Sep 2012 11:57: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 29530318065 for ; Tue, 18 Sep 2012 11:57: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=c5IuXjNtIhkbIXQLmdTW meDXqWQ=; b=pIcrhA783ndzg8iEViw5kRHOyRtZb+0eOZ8tX/1ElkUv9BzjTJNc mU42s/dX4vR0uR7rCYHFqThclNwl81fvTGJnHNnmg7S0o8+7gqdYXDhkadH6ug0f 8Ep+0Duo8cwOPpGDIcQDuvhTxEXkfx4R/I4uo7dLemSy/sg3nqYyPj4= 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-a89.g.dreamhost.com (Postfix) with ESMTPSA id 0494731805D for ; Tue, 18 Sep 2012 11:57:11 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so588471pbb.31 for ; Tue, 18 Sep 2012 11:57:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.82.101 with SMTP id h5mr1142747pay.15.1347994631666; Tue, 18 Sep 2012 11:57:11 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 18 Sep 2012 11:57:11 -0700 (PDT) In-Reply-To: <5058B024.4060601@gmx.net> References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> Date: Tue, 18 Sep 2012 13:57:11 -0500 Message-ID: From: Nico Williams To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 18:57:12 -0000 On Tue, Sep 18, 2012 at 12:32 PM, Hannes Tschofenig wrote: > [...] I would also be interested to hear the motivation for omitting > the user element. See the KITTEN WG list archives. Short version: the user element was there as a result of a misunderstanding about SASL, SASL/GS2, and GSS-API semantics. Nico -- From hannes.tschofenig@gmx.net Tue Sep 18 12:05: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 108D021E8108 for ; Tue, 18 Sep 2012 12:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.315 X-Spam-Level: X-Spam-Status: No, score=-102.315 tagged_above=-999 required=5 tests=[AWL=0.284, 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 k4rEQ5+Fcb8Z for ; Tue, 18 Sep 2012 12:05:23 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D9FA421E8106 for ; Tue, 18 Sep 2012 12:05:22 -0700 (PDT) Received: (qmail invoked by alias); 18 Sep 2012 19:05:21 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.216.191] by mail.gmx.net (mp071) with SMTP; 18 Sep 2012 21:05:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/SaR84RBfSzRH9gey/YPydS4zT8PHLASlLtcVU17 n04W3v1IiZ8Dis Message-ID: <5058C5F0.9090201@gmx.net> Date: Tue, 18 Sep 2012 22:05:20 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: William Mills References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> <1347993790.16872.YahooMailNeo@web31808.mail.mud.yahoo.com> In-Reply-To: <1347993790.16872.YahooMailNeo@web31808.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 19:05:24 -0000 Hi Bill, On 09/18/2012 09:43 PM, William Mills wrote: > Hannes, > > Are you asking about omitting the user element from the draft? Sorry, I should have phrased the sentence better. I was mainly interested to hear more from Ryan about his design. Ideally, it would be good to get the two specs in sync but sending duplicate data isn't so useful. Maybe Ryan can change the code at some point in time. Ciao Hannes > > -bill > > > ------------------------------------------------------------------------ > *From:* Hannes Tschofenig > *To:* William Mills > *Cc:* Ryan Troll ; "kitten@ietf.org" > ; hannes.tschofenig@gmx.net > *Sent:* Tuesday, September 18, 2012 10:32 AM > *Subject:* Re: [kitten] Google and SASL OAuth > > Hi Bill, > > I have only seen the info at this page > https://developers.google.com/talk/jep_extensions/oauth and it does > not give me enough details to judge whether there is similarity to > the SASL OAuth draft. > > Ryan, who is on CC, seems to be the lead developer (as I can > understand from > http://googledevelopers.blogspot.nl/2012/09/adding-oauth-20-support-for-imapsmtp.html). > Ryan, can you shed some light on the relationship to OAuth SASL. > > Of course it would be good to see that work had been re-used and is > deployed in Google. I would also be interested to hear the > motivation for omitting the user element. > > Ciao > Hannes > > On 09/18/2012 07:16 PM, William Mills wrote: > > > > Google has released XOAUTH2 support which looks like it's based > on -03 > > of the SASL OAuth draft. Since then the user= element has been > > removed. At this point user can easily be added back in as an > optional > > KV pair. My question is whether we should do that with a "MAY" > just to > > explicitly make the changes to XOAUTH2 implementations be minimal > (if any). > > > > I'm leaning toward the "working code" argument here. Thoughts? > > > > Thanks, > > > > -bill > > > > > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten > > > > > From wmills@yahoo-inc.com Tue Sep 18 12:28: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 4497921F84A0 for ; Tue, 18 Sep 2012 12:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.45 X-Spam-Level: X-Spam-Status: No, score=-17.45 tagged_above=-999 required=5 tests=[AWL=0.148, 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 CNl6c8DeJN72 for ; Tue, 18 Sep 2012 12:28:04 -0700 (PDT) Received: from nm25-vm4.bullet.mail.ne1.yahoo.com (nm25-vm4.bullet.mail.ne1.yahoo.com [98.138.91.185]) by ietfa.amsl.com (Postfix) with SMTP id 1378D21F847D for ; Tue, 18 Sep 2012 12:28:03 -0700 (PDT) Received: from [98.138.90.49] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 19:27:59 -0000 Received: from [98.138.89.174] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 19:27:59 -0000 Received: from [127.0.0.1] by omp1030.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 19:27:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 13874.81963.bm@omp1030.mail.ne1.yahoo.com Received: (qmail 99938 invoked by uid 60001); 18 Sep 2012 19:27:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1347996478; bh=DEBkhROD6+Erz7ikt+rhHUNdonnRdq6topSmXHJraKE=; 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=dB6XZg5/FgSwpYBL7LgxMVDIKAlNmBemNA+YIkW2fyURUoYgD2lORdDmiOn0vGIN7YavRcvJa9wqA3Exa7gL3xlbHXHDHfMoQJU47OM/e1pVt6D2kZvrk5ZoFiMq1R1tOrWFEX1c/kjrOUCnlhuRtd/P2YQzCz+G2tEbc9C+AKE= 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=XDcfISoOl+JhzyWVpa7Ja6v0/XqRQco+wFs9g81Mmvu9DAYUy8Gc98DXDzZzAyh1pAiNKEC8RKG4TtGw4pCocClEnKGnUik9Sq6B+N9ZZP7nOXMUlCd6SRwsgql/DddFvxUWvQO1gQMdFZ301RGMOS1bOaZIY2e2Y6RzlQjeWN8=; X-YMail-OSG: VjPre1kVM1nvOMAaxITj_qp67.A2157kpx0WMNA6jgZa43i 5a_cFputKFtZONf2uGx7HGtGKQT2SjUOcpz36QeXtEVaY1ntQaUQuHt93V4c 6Zj_PEyL2ipE_yirgfKInLNuUhLJWhL9uP71JL97uoQoB0i58gGkT39HIP9I 4thPJz5D42tzSeikaAr26Aq337AHIVMN9w8qlsGM0EH5qsJhatjmf4qAftoh MtltJMPps5P3cnJHKwyyJJXNxv0KOFAxCC2unN1Bi7AWmVQu7XHNmrVQQdLJ IRynb.yUSWVJGEaJeWr_mRf.9AoK.LrZb5tdvkEAktp9W395GGqLknUrlv4o aKhHs7HccVtQToKtpQVlY9hBjQEvjANmKXhRZY9XCoyMQnQ1sZ2oKbbIMvQ. kZ_d7hpbsogZNkPFOFcrszw9bFQ76rtCxOc5_EnQMwhGIjBaRJJ9qdJvU7h9 ThEJPwaipTgDCz4b.7D2x.GGOBqLNwSbDiDG90CPa3rLJ502NryfBQRfgLo7 WgFgTLla1Tw6wnQoj3dhuM9cQ73s0ShhhE6jhaCO4kyLuLSUFoZqLCWZTTko mghPSCQ2uyhvdz0sVF4zj_.g8n4HNhcYGoQUoY70gva5rkse2fOytFLVMXON Nos8h51MEFcK1dc5lwON9ZY9YjFoMD1m1ZLthyaL16.VvPVtM9yBnUy2ISJM MzdCsyRh3sxpZgAGn908Z2pFPQSyrqhDw Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Tue, 18 Sep 2012 12:27:58 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> <1347993790.16872.YahooMailNeo@web31808.mail.mud.yahoo.com> <5058C5F0.9090201@gmx.net> Message-ID: <1347996478.99644.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Tue, 18 Sep 2012 12:27:58 -0700 (PDT) From: William Mills To: Hannes Tschofenig In-Reply-To: <5058C5F0.9090201@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-697295342-1347996478=:99644" Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 19:28:05 -0000 ---1238014912-697295342-1347996478=:99644 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yeah, they intentionally used the mech name XOAUTH2 so they can move to a s= pec compliant implementation on the names from the spec.=A0 Their work, for= m my quick read is compliant with -03 of the spec, and the only significant= change between that and -07 is that the gs2-header authz-id replaces the "= user" kv pair.=0A=0A=0A=0A=0A=0A>________________________________=0A> From:= Hannes Tschofenig =0A>To: William Mills =0A>Cc: Hannes Tschofenig ; Ryan= Troll ; "kitten@ietf.org" =0A>Sent:= Tuesday, September 18, 2012 12:05 PM=0A>Subject: Re: [kitten] Google and S= ASL OAuth=0A> =0A>Hi Bill,=0A>=0A>On 09/18/2012 09:43 PM, William Mills wro= te:=0A>> Hannes,=0A>>=0A>> Are you asking about omitting the user element f= rom the draft?=0A>=0A>Sorry, I should have phrased the sentence better. I w= as mainly =0A>interested to hear more from Ryan about his design.=0A>=0A>Id= eally, it would be good to get the two specs in sync but sending =0A>duplic= ate data isn't so useful. Maybe Ryan can change the code at some =0A>point = in time.=0A>=0A>Ciao=0A>Hannes=0A>=0A>>=0A>> -bill=0A>>=0A>>=0A>>=A0 =A0 -= -----------------------------------------------------------------------=0A>= >=A0 =A0 *From:* Hannes Tschofenig =0A>>=A0 =A0= *To:* William Mills =0A>>=A0 =A0 *Cc:* Ryan Troll = ; "kitten@ietf.org"=0A>>=A0 =A0 ; ha= nnes.tschofenig@gmx.net=0A>>=A0 =A0 *Sent:* Tuesday, September 18, 2012 10= :32 AM=0A>>=A0 =A0 *Subject:* Re: [kitten] Google and SASL OAuth=0A>>=0A>>= =A0 =A0 Hi Bill,=0A>>=0A>>=A0 =A0 I have only seen the info at this page= =0A>>=A0 =A0 https://developers.google.com/talk/jep_extensions/oauth and it= does=0A>>=A0 =A0 not give me enough details to judge whether there is sim= ilarity to=0A>>=A0 =A0 the SASL OAuth draft.=0A>>=0A>>=A0 =A0 Ryan, who i= s on CC, seems to be the lead developer (as I can=0A>>=A0 =A0 understand f= rom=0A>>=A0 =A0 http://googledevelopers.blogspot.nl/2012/09/adding-oauth-20= -support-for-imapsmtp.html).=0A>>=A0 =A0 Ryan, can you shed some light on = the relationship to OAuth SASL.=0A>>=0A>>=A0 =A0 Of course it would be goo= d to see that work had been re-used and is=0A>>=A0 =A0 deployed in Google.= I would also be interested to hear the=0A>>=A0 =A0 motivation for omittin= g the user element.=0A>>=0A>>=A0 =A0 Ciao=0A>>=A0 =A0 Hannes=0A>>=0A>>=A0= =A0 On 09/18/2012 07:16 PM, William Mills wrote:=0A>>=A0 =A0 =A0 >=0A>>= =A0 =A0 =A0 > Google has released XOAUTH2 support which looks like it's bas= ed=0A>>=A0 =A0 on -03=0A>>=A0 =A0 =A0 > of the SASL OAuth draft.=A0 Since = then the user=3D element has been=0A>>=A0 =A0 =A0 > removed.=A0 At this poi= nt user can easily be added back in as an=0A>>=A0 =A0 optional=0A>>=A0 =A0= =A0 > KV pair.=A0 My question is whether we should do that with a "MAY"=0A= >>=A0 =A0 just to=0A>>=A0 =A0 =A0 > explicitly make the changes to XOAUTH2= implementations be minimal=0A>>=A0 =A0 (if any).=0A>>=A0 =A0 =A0 >=0A>>= =A0 =A0 =A0 > I'm leaning toward the "working code" argument here.=A0 Thoug= hts?=0A>>=A0 =A0 =A0 >=0A>>=A0 =A0 =A0 > Thanks,=0A>>=A0 =A0 =A0 >=0A>>=A0 = =A0 =A0 > -bill=0A>>=A0 =A0 =A0 >=0A>>=A0 =A0 =A0 >=0A>>=A0 =A0 =A0 > _____= __________________________________________=0A>>=A0 =A0 =A0 > Kitten mailing= list=0A>>=A0 =A0 =A0 > Kitten@ietf.org =0A>>=A0 = =A0 =A0 > https://www.ietf.org/mailman/listinfo/kitten=0A>>=A0 =A0 =A0 >=0A= >>=0A>>=0A>>=0A>=0A>=0A>=0A> ---1238014912-697295342-1347996478=:99644 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, the= y intentionally used the mech name XOAUTH2 so they can move to a spec compl= iant implementation on the names from the spec.  Their work, form my q= uick read is compliant with -03 of the spec, and the only significant chang= e between that and -07 is that the gs2-header authz-id replaces the "user" = kv pair.


From: Hannes Tschofenig <hannes.tschofenig@gmx.net&g= t;
To: William Mills <wmi= lls@yahoo-inc.com>
Cc:<= /b> Hannes Tschofenig <hannes.tschofenig@gmx.net>; Ryan Troll <rtr= oll@googlers.com>; "kitten@ietf.org" <kitten@ietf.org>
Sent: Tuesday, September 18, 201= 2 12:05 PM
Subject: Re= : [kitten] Google and SASL OAuth

Hi Bill,

On = 09/18/2012 09:43 PM, William Mills wrote:
> Hannes,
>
> A= re you asking about omitting the user element from the draft?

Sorry,= I should have phrased the sentence better. I was mainly
interested to = hear more from Ryan about his design.

Ideally, it would be good to g= et the two specs in sync but sending
duplicate data isn't so useful. Ma= ybe Ryan can change the code at some
point in time.

Ciao
Hannes

>
> -bill
>
>
&= gt;    ---------------------------------------------------------= ---------------
>    *From:* Hannes Tschofenig <hannes.tschofenig@gmx.net>
>    *To:* Willi= am Mills <wmills@yahoo-inc.com>
>    *Cc:* = Ryan Troll <rtroll@googlers.com>; "kitten@ietf.org"
>&nbs= p;   <kitten@ietf.org>; hannes.tschofenig@gmx.net>    *Sent:* Tuesday, September 18, 2012 10:32 AM
>&nb= sp;   *Subject:* Re: [kitten] Google and SASL OAuth
>
>&n= bsp;   Hi Bill,
>
>    I have only seen the in= fo at this page
>    https://developers.google.= com/talk/jep_extensions/oauth and it does
>    not giv= e me enough details to judge whether there is similarity to
>  &= nbsp; the SASL OAuth draft.
>
>    Ryan, who is on = CC, seems to be the lead developer (as I can
>    understa= nd from
>    http://googledevelopers.blogspot.nl/2012/09/adding-oauth= -20-support-for-imapsmtp.html).
>    Ryan, can you she= d some light on the relationship to OAuth SASL.
>
>   = ; Of course it would be good to see that work had been re-used and is
&= gt;    deployed in Google. I would also be interested to hear th= e
>    motivation for omitting the user element.
>>    Ciao
>    Hannes
>
> = ;   On 09/18/2012 07:16 PM, William Mills wrote:
>   =   >
>      > Google has released XOAUTH2 s= upport which looks like it's based
>    on -03
>&nbs= p;     > of the SASL OAuth draft.  Since then the user=3D= element has been
>      > removed.  At this p= oint user can easily be added back in as an
>   =20 optional
>      > KV pair.  My question is wh= ether we should do that with a "MAY"
>    just to
>&= nbsp;     > explicitly make the changes to XOAUTH2 implementat= ions be minimal
>    (if any).
>     = >
>      > I'm leaning toward the "working code= " argument here.  Thoughts?
>      >
>&n= bsp;     > Thanks,
>      >
>&nb= sp;     > -bill
>      >
> =     >
>      > ______________________= _________________________
>      > Kitten mailing l= ist
>      > Kitten@ietf.org <mailto:Kitten@ietf.org>
>  &nbs= p;   > https://www.ietf.org/mailman/listinfo/kitten
>&nbs= p;     >
>
>
>



=
---1238014912-697295342-1347996478=:99644-- From nico@cryptonector.com Tue Sep 18 12:33: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 4C86911E809A for ; Tue, 18 Sep 2012 12:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 LlqOgANUTWf8 for ; Tue, 18 Sep 2012 12:33:29 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id CBB3211E808E for ; Tue, 18 Sep 2012 12:33:29 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 6CCA57E4065 for ; Tue, 18 Sep 2012 12:33: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=v3AeOOvkwvBdorvjQzrP 68Ao6jw=; b=c+tuVtv6lN9ci3+YrxRufIQP2rEFov7WeHwhor+d6Pmqg9ozuLPD ZDdW/9wQok9grovRN0SVJANgmCPJxNUZWSV+B0jVvsZuuGa4zxtdFBjHxKZq01Ao VBM7IbIVsC1WHyDm+O9SY834DNFSbiM3b8Cx8VsMYCbNG79PNWhet70= 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 52F1D7E4062 for ; Tue, 18 Sep 2012 12:33:29 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so650451pbb.31 for ; Tue, 18 Sep 2012 12:33:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.34 with SMTP id ib2mr1228825pbc.164.1347996809026; Tue, 18 Sep 2012 12:33:29 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 18 Sep 2012 12:33:28 -0700 (PDT) In-Reply-To: <1347996478.99644.YahooMailNeo@web31816.mail.mud.yahoo.com> References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> <1347993790.16872.YahooMailNeo@web31808.mail.mud.yahoo.com> <5058C5F0.9090201@gmx.net> <1347996478.99644.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Tue, 18 Sep 2012 14:33:28 -0500 Message-ID: From: Nico Williams To: William Mills Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 19:33:30 -0000 On Tue, Sep 18, 2012 at 2:27 PM, William Mills wrote: > Yeah, they intentionally used the mech name XOAUTH2 so they can move to a > spec compliant implementation on the names from the spec. Their work, form > my quick read is compliant with -03 of the spec, and the only significant > change between that and -07 is that the gs2-header authz-id replaces the > "user" kv pair. OK, given that they used a non-standard mechanism name I think I don't care. We should, however, state what should be done about unknown key/value pairs; I have no opinion on what would be best to say about that. From simon@josefsson.org Tue Sep 18 13:01: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 7392021F84DE for ; Tue, 18 Sep 2012 13:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.809 X-Spam-Level: X-Spam-Status: No, score=-99.809 tagged_above=-999 required=5 tests=[AWL=0.100, 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 xlYNUE6KgbMn for ; Tue, 18 Sep 2012 13:01:56 -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 8E98D21F84D9 for ; Tue, 18 Sep 2012 13:01:54 -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 q8IK1hlY007001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Sep 2012 22:01:45 +0200 From: Simon Josefsson To: Ryan Troll References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120918:rtroll@googlers.com::m+2wMTJSASL9C9x6:53Hd X-Hashcash: 1:22:120918:kitten@ietf.org::TdrMelMDJHoeb1ar:Eewe X-Hashcash: 1:22:120918:hannes.tschofenig@gmx.net::Yp9pTLrjr/ohOYrL:UMxT Date: Tue, 18 Sep 2012 22:01:42 +0200 In-Reply-To: (Ryan Troll's message of "Tue, 18 Sep 2012 10:47:03 -0700") Message-ID: <87r4pzf6c9.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] Google and 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: Tue, 18 Sep 2012 20:01:56 -0000 Ryan Troll writes: > As for omitting the user information, your basically looking at why I had > originally asked to add this field as Optional -- not all services benefit > from it. I'm not familiar enough with our XMPP service to explain why, > while our IMAP and SMTP implementations do use it. > > Bill: > > Thanks for considering adding the user= field in order to make the move > from XOAUTH2 to this standard easier, but I'm not sure it's worth it. If > the GS2 header is required, the data is already there, and clients that > wish to add OAUTH support to their XOAUTH2 client will simple reformat the > request a bit. I'm puzzled -- could you expand on what use you make of the user field? Like Nico, I believe it was only ever there because of a misunderstanding. If you make use of it, and really requires it, I wonder if something is missing. What do clients put in the user field, and how do servers use that information? /Simon From rtroll@google.com Tue Sep 18 13:37: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 F3FE821E8040 for ; Tue, 18 Sep 2012 13:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.417, 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 MsiYo2SlH98n for ; Tue, 18 Sep 2012 13:37:19 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEF221E8041 for ; Tue, 18 Sep 2012 13:37:18 -0700 (PDT) Received: by iabz21 with SMTP id z21so250259iab.31 for ; Tue, 18 Sep 2012 13:37:17 -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=gtpNgDJvMG3iKurfbdqmkpfEgp2b/uA3JgiYOndrZEI=; b=JTJQQjmMHDz4+g4B3KuI2/N2jipfipwo0MryFvCxIivO6/ZkNJ1xw3vDrVEGN960OQ e89POkJah5ShgIerWdBx6atGc0Y1FOG9IG3HRuMgnSIRTEdIp5oGmboqDRdpVUauuid+ 3TW6esa7Oohw4x4Bgt6577v6xFU0E1px7WweI= 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=gtpNgDJvMG3iKurfbdqmkpfEgp2b/uA3JgiYOndrZEI=; b=CHNDhZsXiArNlUso0Jt74o1NEGni8QVtYTI5HxkcOhhNAf7FSVN9LfYfZ7r0Lj8l8B 4lQos+v/dMz0DpPcrJ15YVytltvdVZfbzmuW5fpghm7bF+Flb46ZCr+5AhVuuAYxDyau hxukYifzQ/PBoiIvaA2DlCMCvDuFTN6+9yX1dafxHU+QYAM0YwGDzY/fBDWrdN8WoOLS l7eRAVu9UCHFDBhEFPwwSRdb2kggMZ1CLc314KcoM5znvTtF4wYcqR1BlO4YwiuTl4ia XcZlkIXuTBHl0N3Sx+lfnDfv7a7LyRir7+J8ayoK4+pZm4CoZCF+qt32cbzqjFC6Akjs TwRQ== MIME-Version: 1.0 Received: by 10.50.202.8 with SMTP id ke8mr950188igc.6.1348000637150; Tue, 18 Sep 2012 13:37:17 -0700 (PDT) Received: by 10.50.36.131 with HTTP; Tue, 18 Sep 2012 13:37:17 -0700 (PDT) In-Reply-To: <87r4pzf6c9.fsf@latte.josefsson.org> References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> <87r4pzf6c9.fsf@latte.josefsson.org> Date: Tue, 18 Sep 2012 13:37:17 -0700 Message-ID: From: Ryan Troll To: Simon Josefsson Content-Type: multipart/alternative; boundary=f46d04479ee522672d04c9ffdb14 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkA/fzrt4EImLsvJ3HzdVtQYrbhwTlGChaHjbc0Es8ZTASZHwaZDgJZfp/JvBgRMBoKG61LF7hAAYOzrRNHHqwPq2QdA+93027UYkDxxYVTVaqWs2U89yL3fdSuDHbXx0essL6B4W66307dlbhYYNdKGFDo7aG+XTAA2ly03PP3IF8j1SzS4gRnyknzDsX2LkWwvOR7 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 20:37:20 -0000 --f46d04479ee522672d04c9ffdb14 Content-Type: text/plain; charset=ISO-8859-1 Our IMAP implementation requires the user, such as "example@gmail.com", along with the OAuth credential. This allows us to route the request to the appropriate backend, without the need to perform operations on the opaque OAuth credential. When the request reaches the backend identified by the username, the credential is validated to ensure that the client has been granted permission to access the user's content. If the request reaches "example@gmail.com"'s backend, but the credential is for " other@gmail.com", the request will fail with an authentication failure. Simon: Does this answer your question? Hannes: Yes, once this draft is standardized we will add support for the conformant SASL mechanism. Bill: Agreed. When this draft becomes the law, we'll advertise that we require the documented GS2 header. -R On Tue, Sep 18, 2012 at 1:01 PM, Simon Josefsson wrote: > Ryan Troll writes: > > > As for omitting the user information, your basically looking at why I had > > originally asked to add this field as Optional -- not all services > benefit > > from it. I'm not familiar enough with our XMPP service to explain why, > > while our IMAP and SMTP implementations do use it. > > > > Bill: > > > > Thanks for considering adding the user= field in order to make the move > > from XOAUTH2 to this standard easier, but I'm not sure it's worth it. If > > the GS2 header is required, the data is already there, and clients that > > wish to add OAUTH support to their XOAUTH2 client will simple reformat > the > > request a bit. > > I'm puzzled -- could you expand on what use you make of the user field? > Like Nico, I believe it was only ever there because of a > misunderstanding. If you make use of it, and really requires it, I > wonder if something is missing. What do clients put in the user field, > and how do servers use that information? > > /Simon > --f46d04479ee522672d04c9ffdb14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Our IMAP implementation requires the user, such as "example@gmail.com", along with the OAuth creden= tial. =A0This allows us to route the request to the appropriate backend, wi= thout the need to perform operations on the opaque OAuth credential. =A0Whe= n the request reaches the backend identified by the username, the credentia= l is validated to ensure that the client has been granted permission to acc= ess the user's content. =A0If the request reaches "example@gmail.com"'s backend, but the cr= edential is for "other@gmail.com", the request will fail with an authentication failure.

Simon: =A0Does this answer your question?

Hannes: Yes, once this draft is standardized we will add support for= the=A0conformant=A0SASL mechanism.

Bill: Agreed. = =A0When this draft becomes the law, we'll advertise that we require the= documented GS2 header.

-R


On Tue, Sep 18, 2012 at 1:01 PM, Simon Josefsson <sim= on@josefsson.org> wrote:
Ryan Troll <rtroll@googlers.com> writes:

> As for omitting the user information, your basically looking at why I = had
> originally asked to add this field as Optional -- not all services ben= efit
> from it. =A0I'm not familiar enough with our XMPP service to expla= in why,
> while our IMAP and SMTP implementations do use it.
>
> Bill:
>
> Thanks for considering adding the user=3D field in order to make the m= ove
> from XOAUTH2 to this standard easier, but I'm not sure it's wo= rth it. =A0If
> the GS2 header is required, the data is already there, and clients tha= t
> wish to add OAUTH support to their XOAUTH2 client will simple reformat= the
> request a bit.

I'm puzzled -- could you expand on what use you make of the user = field?
Like Nico, I believe it was only ever there because of a
misunderstanding. =A0If you make use of it, and really requires it, I
wonder if something is missing. =A0What do clients put in the user field, and how do servers use that information?

/Simon

--f46d04479ee522672d04c9ffdb14-- From simon@josefsson.org Tue Sep 18 14:09: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 84B6E11E808D for ; Tue, 18 Sep 2012 14:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.816 X-Spam-Level: X-Spam-Status: No, score=-99.816 tagged_above=-999 required=5 tests=[AWL=0.093, 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 RYfMohw-rBlq for ; Tue, 18 Sep 2012 14:09:53 -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 A2F6121F8589 for ; Tue, 18 Sep 2012 14:09:51 -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 q8IL9h4t009985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Sep 2012 23:09:44 +0200 From: Simon Josefsson To: Ryan Troll References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> <87r4pzf6c9.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120918:rtroll@googlers.com::rPQMxKk2WczrDypZ:IOAH X-Hashcash: 1:22:120918:kitten@ietf.org::7pXkDgB2tzmQI63m:AePH X-Hashcash: 1:22:120918:hannes.tschofenig@gmx.net::NRmyZejlwpQ68f0s:BifO Date: Tue, 18 Sep 2012 23:09:43 +0200 In-Reply-To: (Ryan Troll's message of "Tue, 18 Sep 2012 13:37:17 -0700") Message-ID: <87obl3jaw8.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] Google and 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: Tue, 18 Sep 2012 21:09:53 -0000 Ryan Troll writes: > Our IMAP implementation requires the user, such as "example@gmail.com", > along with the OAuth credential. This allows us to route the request to > the appropriate backend, without the need to perform operations on the > opaque OAuth credential. When the request reaches the backend identified > by the username, the credential is validated to ensure that the client has > been granted permission to access the user's content. If the request > reaches "example@gmail.com"'s backend, but the credential is for " > other@gmail.com", the request will fail with an authentication failure. Thanks for explaining. To be sure I understand completely: you COULD have found out the example@gmail.com identity by looking into the OAuth credential (possibly using some database that eventually map the OAuth credential to the particular user), couldn't you? So this is just a convenience hint for front-ends, and the internal server double-checks whether the supplied hint was indeed the right one. Right? Finally: The backend makes no use of the routing hint except for comparing it with the identity implied by the OAuth credential? What I'm looking for to confirm is that there is never any doubt to the internal server which user identity the OAuth credential belongs to. > Simon: Does this answer your question? Yes. If your use-case is important, there could be a field inside the OAuth mechanism to convey this information so that servers doesn't have to look into the OAuth credential. This routing hint field has nothing whatsoever to do with the SASL authcid or authzid though. But if you are able to implement your system without this routing hint, it is indicative that others will be in the same situation, so I would prefer to drop the field since it adds no information but just require more text in the document to describe. /Simon > Hannes: Yes, once this draft is standardized we will add support for > the conformant SASL mechanism. > > Bill: Agreed. When this draft becomes the law, we'll advertise that we > require the documented GS2 header. > > -R > > > On Tue, Sep 18, 2012 at 1:01 PM, Simon Josefsson wrote: > >> Ryan Troll writes: >> >> > As for omitting the user information, your basically looking at why I had >> > originally asked to add this field as Optional -- not all services >> benefit >> > from it. I'm not familiar enough with our XMPP service to explain why, >> > while our IMAP and SMTP implementations do use it. >> > >> > Bill: >> > >> > Thanks for considering adding the user= field in order to make the move >> > from XOAUTH2 to this standard easier, but I'm not sure it's worth it. If >> > the GS2 header is required, the data is already there, and clients that >> > wish to add OAUTH support to their XOAUTH2 client will simple reformat >> the >> > request a bit. >> >> I'm puzzled -- could you expand on what use you make of the user field? >> Like Nico, I believe it was only ever there because of a >> misunderstanding. If you make use of it, and really requires it, I >> wonder if something is missing. What do clients put in the user field, >> and how do servers use that information? >> >> /Simon >> From rtroll@google.com Tue Sep 18 14:32: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 C08BA11E80AE for ; Tue, 18 Sep 2012 14:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.698 X-Spam-Level: X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=0.278, 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 Hs7UHDOqSKjL for ; Tue, 18 Sep 2012 14:32:39 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id F07BD11E80A6 for ; Tue, 18 Sep 2012 14:32:38 -0700 (PDT) Received: by iabz21 with SMTP id z21so290589iab.31 for ; Tue, 18 Sep 2012 14:32: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=7F7UzcLz80eHTET47dSWp8MAQ51B/+78MJvulLzYBfs=; b=Uvust5KqKFLqWoGDsWilebHjoG6/7aOlO0xheg52JTVwH5Cumqu3PdUjiZD3DPlnsi emPCCiEYOmqjjZqpn1o8xwDq4MWUkBtA61+nHnYdWY6joVf9tC2hiD/EcGdVAgwHDLMp SauS7i7aGAaUvOKknhbFhQ03z6lz8zsIMF8lo= 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=7F7UzcLz80eHTET47dSWp8MAQ51B/+78MJvulLzYBfs=; b=I1LqtlYa37P3lyUWmZYs0FJ+LFzyxNAGuvLP7ZIVqCapDhAzxprtssA9w2XE5vELty PIq63z2CRQFbgMjl1kV4PyFukd2lugA5Dt9qs5XukP2BpFsn/ZrkQpMbM2WTK5+iN31P Y2DAc5zQ++de1qLt8kWGA39PHVDYUbTExwxO9+moxPlUlBPVnPjTT5Ymr/QwMBdMeFIZ iZ7d3qoBmRuKqBs7CLrP8tSSTbcNaamv758ayNy5zzlvcdz73WyDMWOy0an1kynXh9X+ bxPB6L5hbR8HfmXtGXGmOUrs/eb+EG6RbP/YK31h+3XuNCnktiCikW2Lxq2qRx6uR/Ug /qJw== Received: by 10.50.40.133 with SMTP id x5mr914701igk.57.1348003952617; Tue, 18 Sep 2012 14:32:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.40.133 with SMTP id x5mr914688igk.57.1348003952438; Tue, 18 Sep 2012 14:32:32 -0700 (PDT) Received: by 10.50.36.131 with HTTP; Tue, 18 Sep 2012 14:32:32 -0700 (PDT) In-Reply-To: <87obl3jaw8.fsf@latte.josefsson.org> References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> <87r4pzf6c9.fsf@latte.josefsson.org> <87obl3jaw8.fsf@latte.josefsson.org> Date: Tue, 18 Sep 2012 14:32:32 -0700 Message-ID: From: Ryan Troll To: Simon Josefsson Content-Type: multipart/alternative; boundary=14dae93403d9bdadd704ca00a054 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm7nOeISF+mYONLrKP7f2q9kEkfdI6YDY/PJZ1oRLr4627gBaYxgZyaW06OSgcZZeMN3Jse/IIiimTCTc48W5AmzoZyafrCnX6ukUgHlj+g7Dn50ymWKYrNeutfFCvN66lGT30++3TvTQVsTVeg7OML3LcsBS+l7K4aZrl30wECwViHBw7QPIR8IU6eGKvcm6ChVi8y Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 21:32:42 -0000 --14dae93403d9bdadd704ca00a054 Content-Type: text/plain; charset=ISO-8859-1 > Thanks for explaining. To be sure I understand completely: you COULD > have found out the example@gmail.com identity by looking into the OAuth > credential (possibly using some database that eventually map the OAuth > credential to the particular user), couldn't you? Yes, this COULD have been done. > So this is just a > convenience hint for front-ends, and the internal server double-checks > whether the supplied hint was indeed the right one. Right? > Yes. Supplying an incorrect fails. > Finally: The backend makes no use of the routing hint except for > comparing it with the identity implied by the OAuth credential? What > I'm looking for to confirm is that there is never any doubt to the > internal server which user identity the OAuth credential belongs to. > This is my understanding. However, it could be that the backend totally ignores the hint, and only uses the data in the OAuth credential. This would lead to a user having access to his data even if the hint was wrong, if (and only if) the hint mapped to the same backend as the user. Regardless, the identity used for data access is the OAuth credential. The backend does not use the hint as authoritative for anything. > > Simon: Does this answer your question? > > Yes. If your use-case is important, there could be a field inside the > OAuth mechanism to convey this information so that servers doesn't have > to look into the OAuth credential. > This was considered and ruled out. We're keeping our OAuth credentials opaque, which means that frontends would need to perform additional work to break it apart. > This routing hint field has nothing whatsoever to do with the SASL > authcid or authzid though. > > But if you are able to implement your system without this routing hint, > it is indicative that others will be in the same situation, so I would > prefer to drop the field since it adds no information but just require > more text in the document to describe. > Your recommendation is to just have Google document the user field as something it needs outside of the spec? In which case, the only difference between our XOAUTH mechanism, and this draft, is the name of the mechanism (plus our additional field)? I was hoping to get something into this mechanism that would standardize this scenario across service providers, but if the group's consensus is that it doesn't make sense to do so, so be it. -R > > /Simon > > > Hannes: Yes, once this draft is standardized we will add support for > > the conformant SASL mechanism. > > > > Bill: Agreed. When this draft becomes the law, we'll advertise that we > > require the documented GS2 header. > > > > -R > > > > > > On Tue, Sep 18, 2012 at 1:01 PM, Simon Josefsson >wrote: > > > >> Ryan Troll writes: > >> > >> > As for omitting the user information, your basically looking at why I > had > >> > originally asked to add this field as Optional -- not all services > >> benefit > >> > from it. I'm not familiar enough with our XMPP service to explain > why, > >> > while our IMAP and SMTP implementations do use it. > >> > > >> > Bill: > >> > > >> > Thanks for considering adding the user= field in order to make the > move > >> > from XOAUTH2 to this standard easier, but I'm not sure it's worth it. > If > >> > the GS2 header is required, the data is already there, and clients > that > >> > wish to add OAUTH support to their XOAUTH2 client will simple reformat > >> the > >> > request a bit. > >> > >> I'm puzzled -- could you expand on what use you make of the user field? > >> Like Nico, I believe it was only ever there because of a > >> misunderstanding. If you make use of it, and really requires it, I > >> wonder if something is missing. What do clients put in the user field, > >> and how do servers use that information? > >> > >> /Simon > >> > --14dae93403d9bdadd704ca00a054 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for ex= plaining. =A0To be sure I understand completely: you COULD
have found out the example@gmail.com identity by looking into the OAuth
credential (possibly using some database that eventually map the OAuth
credential to the particular user), couldn't you?
=A0So this is just a
convenience hint for front-ends, and the internal server double-checks
whether the supplied hint was indeed the right one. =A0Right?

Yes. =A0Supplying an incorrect fails.

=
=A0
Finally: The backend makes no use of the routing hint except for
comparing it with the identity implied by the OAuth credential? =A0What
I'm looking for to confirm is that there is never any doubt to the
internal server which user identity the OAuth credential belongs to.


This is my understanding. =A0H= owever, it could be that the backend totally ignores the hint, and only use= s the data in the OAuth credential. =A0This would lead to a user having acc= ess to his data even if the hint was wrong, if (and only if) the hint mappe= d to the same backend as the user.

Regardless, the identity used for data access is the OA= uth credential. =A0The backend does not use the hint as authoritative for a= nything.

=A0
> Simon: =A0Does this answer your question?

Yes. =A0If your use-case is important, there could be a field inside = the
OAuth mechanism to convey this information so that servers doesn't have=
to look into the OAuth credential.

This= was considered and ruled out. =A0We're keeping our OAuth credentials o= paque, which means that frontends would need to perform additional work to = break it apart.

=A0
This routing hi= nt field has nothing whatsoever to do with the SASL
authcid or authzid though.

But if you are able to implement your system without this routing hint,
it is indicative that others will be in the same situation, so I would
prefer to drop the field since it adds no information but just require
more text in the document to describe.

= Your recommendation is to just have Google document the user field as somet= hing it needs outside of the spec? =A0In which case, the only difference be= tween our XOAUTH mechanism, and this draft, is the name of the mechanism (p= lus our additional field)?

I was hoping to get something into this mechanism that = would standardize this scenario across service providers, but if the group&= #39;s=A0consensus=A0is that it doesn't make sense to do so, so be it.

-R

=A0

/Simon

> Hannes: Yes, once this draft is standardized we will add support for > the conformant SASL mechanism.
>
> Bill: Agreed. =A0When this draft becomes the law, we'll advertise = that we
> require the documented GS2 header.
>
> -R
>
>
> On Tue, Sep 18, 2012 at 1:01 PM, Simon Josefsson <simon@josefsson.org>wrote:
>
>> Ryan Troll <rtroll@googl= ers.com> writes:
>>
>> > As for omitting the user information, your basically looking = at why I had
>> > originally asked to add this field as Optional -- not all ser= vices
>> benefit
>> > from it. =A0I'm not familiar enough with our XMPP service= to explain why,
>> > while our IMAP and SMTP implementations do use it.
>> >
>> > Bill:
>> >
>> > Thanks for considering adding the user=3D field in order to m= ake the move
>> > from XOAUTH2 to this standard easier, but I'm not sure it= 's worth it. =A0If
>> > the GS2 header is required, the data is already there, and cl= ients that
>> > wish to add OAUTH support to their XOAUTH2 client will simple= reformat
>> the
>> > request a bit.
>>
>> I'm puzzled -- could you expand on what use you make of the us= er field?
>> Like Nico, I believe it was only ever there because of a
>> misunderstanding. =A0If you make use of it, and really requires it= , I
>> wonder if something is missing. =A0What do clients put in the user= field,
>> and how do servers use that information?
>>
>> /Simon
>>

--14dae93403d9bdadd704ca00a054-- From simon@josefsson.org Tue Sep 18 14:45: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 423E421E8037 for ; Tue, 18 Sep 2012 14:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.828 X-Spam-Level: X-Spam-Status: No, score=-99.828 tagged_above=-999 required=5 tests=[AWL=0.081, 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 BVXFvO024J7f for ; Tue, 18 Sep 2012 14:45: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 32C8A11E80AD for ; Tue, 18 Sep 2012 14:45: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 q8ILjNFQ011761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Sep 2012 23:45:24 +0200 From: Simon Josefsson To: Ryan Troll References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> <87r4pzf6c9.fsf@latte.josefsson.org> <87obl3jaw8.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120918:hannes.tschofenig@gmx.net::2Cq8dJIftu+DbIa4:uct X-Hashcash: 1:22:120918:rtroll@googlers.com::4DTEhiRHnjnc07iV:8vkV X-Hashcash: 1:22:120918:kitten@ietf.org::KMBoNjBL0xf66few:B8Bl Date: Tue, 18 Sep 2012 23:45:23 +0200 In-Reply-To: (Ryan Troll's message of "Tue, 18 Sep 2012 14:32:32 -0700") Message-ID: <87fw6fj98s.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] Google and 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: Tue, 18 Sep 2012 21:45:32 -0000 Ryan Troll writes: >> Thanks for explaining. To be sure I understand completely: you COULD >> have found out the example@gmail.com identity by looking into the OAuth >> credential (possibly using some database that eventually map the OAuth >> credential to the particular user), couldn't you? > > > Yes, this COULD have been done. Good, that matches my understanding. I understand doing so leads to extra work that is always good to reduce. >> So this is just a >> convenience hint for front-ends, and the internal server double-checks >> whether the supplied hint was indeed the right one. Right? >> > > Yes. Supplying an incorrect fails. Good. >> Finally: The backend makes no use of the routing hint except for >> comparing it with the identity implied by the OAuth credential? What >> I'm looking for to confirm is that there is never any doubt to the >> internal server which user identity the OAuth credential belongs to. > > This is my understanding. However, it could be that the backend totally > ignores the hint, and only uses the data in the OAuth credential. This > would lead to a user having access to his data even if the hint was wrong, > if (and only if) the hint mapped to the same backend as the user. Sure. However a spec might demand that a comparison is always made. > Regardless, the identity used for data access is the OAuth credential. The > backend does not use the hint as authoritative for anything. Right. Although the specification could demand certain behaviour here, like saying that if there is a mismatch between the routing hint and the OAuth credential identity, authentication fails even if the OAuth credential would otherwise be valid. >> > Simon: Does this answer your question? >> >> Yes. If your use-case is important, there could be a field inside the >> OAuth mechanism to convey this information so that servers doesn't have >> to look into the OAuth credential. >> > > This was considered and ruled out. We're keeping our OAuth credentials > opaque, which means that frontends would need to perform additional work to > break it apart. Ok. If everyone will have to go through additional implementation pains due to this, that would warrant putting a routing hint back in. However, if you are able to make it work, likely others will as well, and then it is better to leave it out. >> This routing hint field has nothing whatsoever to do with the SASL >> authcid or authzid though. >> >> But if you are able to implement your system without this routing hint, >> it is indicative that others will be in the same situation, so I would >> prefer to drop the field since it adds no information but just require >> more text in the document to describe. >> > > Your recommendation is to just have Google document the user field as > something it needs outside of the spec? In which case, the only difference > between our XOAUTH mechanism, and this draft, is the name of the mechanism > (plus our additional field)? I would recommend/hope that you implement the draft that eventually comes out of this WG and phase out your experimental XOAUTH* stuff at that point. > I was hoping to get something into this mechanism that would standardize > this scenario across service providers, but if the group's consensus is > that it doesn't make sense to do so, so be it. Your input is part of the consensus process. What I'm not getting now is whether you can & will adapt to a design without a routing hint and change your implementation, or if you'd rather publish a separate document describing your variation of the mechanism and deploy that under a different SASL name? If the latter, I think we are having a WG failure and need to reconsider what changes to the document would make you happier. /Simon > -R > > > >> >> /Simon >> >> > Hannes: Yes, once this draft is standardized we will add support for >> > the conformant SASL mechanism. >> > >> > Bill: Agreed. When this draft becomes the law, we'll advertise that we >> > require the documented GS2 header. >> > >> > -R >> > >> > >> > On Tue, Sep 18, 2012 at 1:01 PM, Simon Josefsson > >wrote: >> > >> >> Ryan Troll writes: >> >> >> >> > As for omitting the user information, your basically looking at why I >> had >> >> > originally asked to add this field as Optional -- not all services >> >> benefit >> >> > from it. I'm not familiar enough with our XMPP service to explain >> why, >> >> > while our IMAP and SMTP implementations do use it. >> >> > >> >> > Bill: >> >> > >> >> > Thanks for considering adding the user= field in order to make the >> move >> >> > from XOAUTH2 to this standard easier, but I'm not sure it's worth it. >> If >> >> > the GS2 header is required, the data is already there, and clients >> that >> >> > wish to add OAUTH support to their XOAUTH2 client will simple reformat >> >> the >> >> > request a bit. >> >> >> >> I'm puzzled -- could you expand on what use you make of the user field? >> >> Like Nico, I believe it was only ever there because of a >> >> misunderstanding. If you make use of it, and really requires it, I >> >> wonder if something is missing. What do clients put in the user field, >> >> and how do servers use that information? >> >> >> >> /Simon >> >> >> From wmills@yahoo-inc.com Tue Sep 18 14: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 72D8421E8047 for ; Tue, 18 Sep 2012 14:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.457 X-Spam-Level: X-Spam-Status: No, score=-17.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 IX0LnB2ByEIs for ; Tue, 18 Sep 2012 14:52:39 -0700 (PDT) Received: from nm22-vm0.bullet.mail.ac4.yahoo.com (nm22-vm0.bullet.mail.ac4.yahoo.com [98.139.53.218]) by ietfa.amsl.com (Postfix) with SMTP id D5A9B21E8037 for ; Tue, 18 Sep 2012 14:52:38 -0700 (PDT) Received: from [98.139.52.194] by nm22.bullet.mail.ac4.yahoo.com with NNFMP; 18 Sep 2012 21:52:34 -0000 Received: from [98.139.52.163] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 18 Sep 2012 21:52:34 -0000 Received: from [127.0.0.1] by omp1046.mail.ac4.yahoo.com with NNFMP; 18 Sep 2012 21:52:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 846539.94026.bm@omp1046.mail.ac4.yahoo.com Received: (qmail 58460 invoked by uid 60001); 18 Sep 2012 21:52:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348005154; bh=h4OUbYhHc1as/P6EGPAXyBQTF3ouWHvr4xCWkIfKnV4=; 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=na+lNjE5Kn8Fx7PmfRD8zxTNBwN9eCsr64jNReEAQWoMYkW0MsDftV/GowTvdgycSkl3FY5hsd1DfIS0tMv7YPfqrM91GF//6KdwS4oC/PEqQ5DGierdGkJWGww8Y3q9SrZSRKP8mvhdqKIzQtOq0RUuwqEnjskt1dfo8a7rJcI= 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=BsX3NNd3wDaPskGB96lKPIIYXhiesLxj71G2TEF+2oq/clb0X+B6J86YNT5GcfpFO8ZNH1ySYhs5bXbckdRz1CzL2aM2ha9H8wwyZcv2sBFRfBR2YEdfarJtTl0JWSRZS8WGwdMSn5v/eLzZAj25g5HSLXm8w480dGFSkTSvpTA=; X-YMail-OSG: wzSlndgVM1mmuavNXINikFV756Kwn_Cq5OwKO5kaEgyhsb. IPVhCuQr_NFV3rvnEvrkgJcrAGr5hhlZaRLu5CFJ0X9vZ378UPgjdYxpAjts wIMQUVa4n5Y0aqwrU21uDKBow0cvptWlzIb.TnQgbDXAEX.HHyTztPO_OL9H bLG7fCMDm1AkyXnFifime3tXwzXaCE_7c8e9CX12CA8OVWu7NgTqjxryS4TD l_MyuWgs8WiutKad.j25tyCi6XMmKELlHJOnDB13RLDiiQsWQV5bQZsRJ2hT Me7Np_.K5Il3cUxB1qlbhTFiYAAiFueNMC.7EavPBM1fYYE9kltrDd6M7sve yVsRTC6Gcgt1iC87avpL_XTHo7yW2TEhrnm222Fxse90uwdrYW8ptc12Wrfy 81MNi_74NXg5z9EYvnz2zQ4luaes5oZGcTC9_RSphgnKzq_DgWwBvpTsV.1k iFFh7OCU- Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Tue, 18 Sep 2012 14:52:34 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> <87r4pzf6c9.fsf@latte.josefsson.org> <87obl3jaw8.fsf@latte.josefsson.org> Message-ID: <1348005154.32177.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Tue, 18 Sep 2012 14:52:34 -0700 (PDT) From: William Mills To: Ryan Troll , Simon Josefsson In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 21:52:42 -0000 =0A>I was hoping to get something into this mechanism that would =0Astandar= dize this scenario across service providers, but if the =0Agroup's=A0consen= sus=A0is that it doesn't make sense to do so, so be it.=0A=0AAuthz-id can s= erve this purpose but it's not mandatory.=A0 You can make it mandatory in y= our service documentation, that's as easy as making an optional field in th= e SASL data that you require.=0A=0A=0A=0A=0A=0A=0A>________________________= ________=0A> From: Ryan Troll =0A>To: Simon Josefsson = =0A>Cc: "kitten@ietf.org" =0A>Sent:= Tuesday, September 18, 2012 2:32 PM=0A>Subject: Re: [kitten] Google and SA= SL OAuth=0A> =0A>=0A>=0A>=0A>Thanks for explaining. =A0To be sure I underst= and completely: you COULD=0A>>have found out the example@gmail.com identity= by looking into the OAuth=0A>>credential (possibly using some database tha= t eventually map the OAuth=0A>>credential to the particular user), couldn't= you? =0A>=0A>=0A>Yes, this COULD have been done.=0A>=A0=0A>=A0So this is j= ust a=0A>>convenience hint for front-ends, and the internal server double-c= hecks=0A>>whether the supplied hint was indeed the right one. =A0Right?=0A>= >=0A>=0A>=0A>Yes. =A0Supplying an incorrect fails.=0A>=0A>=0A>=A0=0A>Finall= y: The backend makes no use of the routing hint except for=0A>>comparing it= with the identity implied by the OAuth credential? =A0What=0A>>I'm looking= for to confirm is that there is never any doubt to the=0A>>internal server= which user identity the OAuth credential belongs to.=0A>>=0A>=0A>=0A>=0A>= =0A>This is my understanding. =A0However, it could be that the backend tota= lly ignores the hint, and only uses the data in the OAuth credential. =A0Th= is would lead to a user having access to his data even if the hint was wron= g, if (and only if) the hint mapped to the same backend as the user.=0A>=0A= >=0A>Regardless, the identity used for data access is the OAuth credential.= =A0The backend does not use the hint as authoritative for anything.=0A>=0A= >=0A>=A0=0A>> Simon: =A0Does this answer your question?=0A>>=0A>>Yes. =A0If= your use-case is important, there could be a field inside the=0A>>OAuth me= chanism to convey this information so that servers doesn't have=0A>>to look= into the OAuth credential.=0A>>=0A>=0A>=0A>This was considered and ruled o= ut. =A0We're keeping our OAuth credentials opaque, which means that fronten= ds would need to perform additional work to break it apart.=0A>=0A>=0A>=A0= =0A>This routing hint field has nothing whatsoever to do with the SASL=0A>>= authcid or authzid though.=0A>>=0A>>But if you are able to implement your s= ystem without this routing hint,=0A>>it is indicative that others will be i= n the same situation, so I would=0A>>prefer to drop the field since it adds= no information but just require=0A>>more text in the document to describe.= =0A>>=0A>=0A>=0A>Your recommendation is to just have Google document the us= er field as something it needs outside of the spec? =A0In which case, the o= nly difference between our XOAUTH mechanism, and this draft, is the name of= the mechanism (plus our additional field)?=0A>=0A>=0A>I was hoping to get = something into this mechanism that would standardize this scenario across s= ervice providers, but if the group's=A0consensus=A0is that it doesn't make = sense to do so, so be it.=0A>=0A>=0A>-R=0A>=0A>=0A>=A0=0A>=0A>>/Simon=0A>>= =0A>>=0A>>> Hannes: Yes, once this draft is standardized we will add suppor= t for=0A>>> the conformant SASL mechanism.=0A>>>=0A>>> Bill: Agreed. =A0Whe= n this draft becomes the law, we'll advertise that we=0A>>> require the doc= umented GS2 header.=0A>>>=0A>>> -R=0A>>>=0A>>>=0A>>> On Tue, Sep 18, 2012 a= t 1:01 PM, Simon Josefsson wrote:=0A>>>=0A>>>> Ryan Tr= oll writes:=0A>>>>=0A>>>> > As for omitting the user = information, your basically looking at why I had=0A>>>> > originally asked = to add this field as Optional -- not all services=0A>>>> benefit=0A>>>> > f= rom it. =A0I'm not familiar enough with our XMPP service to explain why,=0A= >>>> > while our IMAP and SMTP implementations do use it.=0A>>>> >=0A>>>> >= Bill:=0A>>>> >=0A>>>> > Thanks for considering adding the user=3D field in= order to make the move=0A>>>> > from XOAUTH2 to this standard easier, but = I'm not sure it's worth it. =A0If=0A>>>> > the GS2 header is required, the = data is already there, and clients that=0A>>>> > wish to add OAUTH support = to their XOAUTH2 client will simple reformat=0A>>>> the=0A>>>> > request a = bit.=0A>>>>=0A>>>> I'm puzzled -- could you expand on what use you make of = the user field?=0A>>>> Like Nico, I believe it was only ever there because = of a=0A>>>> misunderstanding. =A0If you make use of it, and really requires= it, I=0A>>>> wonder if something is missing. =A0What do clients put in the= user field,=0A>>>> and how do servers use that information?=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> From simon@josefsson.org Tue Sep 18 15:09: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 B371D11E80B8 for ; Tue, 18 Sep 2012 15:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.833 X-Spam-Level: X-Spam-Status: No, score=-99.833 tagged_above=-999 required=5 tests=[AWL=0.076, 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 8lCzVy2oXX-D for ; Tue, 18 Sep 2012 15:09:34 -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 9634C11E80BA for ; Tue, 18 Sep 2012 15:09: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 q8IM9PrL012727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Sep 2012 00:09:27 +0200 From: Simon Josefsson To: William Mills References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> <87r4pzf6c9.fsf@latte.josefsson.org> <87obl3jaw8.fsf@latte.josefsson.org> <1348005154.32177.YahooMailNeo@web31806.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120918:rtroll@googlers.com::wjh9RYd0KVjinYIk:6LMu X-Hashcash: 1:22:120918:wmills@yahoo-inc.com::VzELNFI3tcnQbds6:701a X-Hashcash: 1:22:120918:kitten@ietf.org::T141NxAgjlW7vcil:JKxL Date: Wed, 19 Sep 2012 00:09:25 +0200 In-Reply-To: <1348005154.32177.YahooMailNeo@web31806.mail.mud.yahoo.com> (William Mills's message of "Tue, 18 Sep 2012 14:52:34 -0700 (PDT)") Message-ID: <871uhzj84q.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] Google and 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: Tue, 18 Sep 2012 22:09:34 -0000 William Mills writes: >>I was hoping to get something into this mechanism that would > standardize this scenario across service providers, but if the > group's consensus is that it doesn't make sense to do so, so be it. > > Authz-id can serve this purpose but it's not mandatory.  You can make > it mandatory in your service documentation, that's as easy as making > an optional field in the SASL data that you require. No, the authzid cannot serve this purpose even if it were mandatory. This is a misunderstanding. Ryan wants the identity of the OAuth credential owner as a routing hint to find a server that can verify the OAuth credential for that user. The authzid has nothing to do with that. I believe the routing hint and the SASL authentication identity will always be the same for a successful authentication though. However, the authcid is implied from the OAuth credential, and since the routing hint is not integrity protected, you couldn't say that the authentication identity is always the routing hint. Some mechanisms (PLAIN, SCRAM) transfer the authentication identity in the clear and the OAuth mechanism could as well if people think it is useful. /Simon > > > > > >>________________________________ >> From: Ryan Troll >>To: Simon Josefsson >>Cc: "kitten@ietf.org" >>Sent: Tuesday, September 18, 2012 2:32 PM >>Subject: Re: [kitten] Google and SASL OAuth >> >> >> >> >>Thanks for explaining.  To be sure I understand completely: you COULD >>>have found out the example@gmail.com identity by looking into the OAuth >>>credential (possibly using some database that eventually map the OAuth >>>credential to the particular user), couldn't you? >> >> >>Yes, this COULD have been done. >>  >> So this is just a >>>convenience hint for front-ends, and the internal server double-checks >>>whether the supplied hint was indeed the right one.  Right? >>> >> >> >>Yes.  Supplying an incorrect fails. >> >> >>  >>Finally: The backend makes no use of the routing hint except for >>>comparing it with the identity implied by the OAuth credential?  What >>>I'm looking for to confirm is that there is never any doubt to the >>>internal server which user identity the OAuth credential belongs to. >>> >> >> >> >> >>This is my understanding.  However, it could be that the backend >> totally ignores the hint, and only uses the data in the OAuth >> credential.  This would lead to a user having access to his data >> even if the hint was wrong, if (and only if) the hint mapped to the >> same backend as the user. >> >> >>Regardless, the identity used for data access is the OAuth >> credential.  The backend does not use the hint as authoritative for >> anything. >> >> >>  >>> Simon:  Does this answer your question? >>> >>>Yes.  If your use-case is important, there could be a field inside the >>>OAuth mechanism to convey this information so that servers doesn't have >>>to look into the OAuth credential. >>> >> >> >>This was considered and ruled out.  We're keeping our OAuth >> credentials opaque, which means that frontends would need to perform >> additional work to break it apart. >> >> >>  >>This routing hint field has nothing whatsoever to do with the SASL >>>authcid or authzid though. >>> >>>But if you are able to implement your system without this routing hint, >>>it is indicative that others will be in the same situation, so I would >>>prefer to drop the field since it adds no information but just require >>>more text in the document to describe. >>> >> >> >>Your recommendation is to just have Google document the user field as >> something it needs outside of the spec?  In which case, the only >> difference between our XOAUTH mechanism, and this draft, is the name >> of the mechanism (plus our additional field)? >> >> >>I was hoping to get something into this mechanism that would >> standardize this scenario across service providers, but if the >> group's consensus is that it doesn't make sense to do so, so be it. >> >> >>-R >> >> >>  >> >>>/Simon >>> >>> >>>> Hannes: Yes, once this draft is standardized we will add support for >>>> the conformant SASL mechanism. >>>> >>>> Bill: Agreed.  When this draft becomes the law, we'll advertise that we >>>> require the documented GS2 header. >>>> >>>> -R >>>> >>>> >>>> On Tue, Sep 18, 2012 at 1:01 PM, Simon Josefsson wrote: >>>> >>>>> Ryan Troll writes: >>>>> >>>>> > As for omitting the user information, your basically looking at why I had >>>>> > originally asked to add this field as Optional -- not all services >>>>> benefit >>>>> > from it.  I'm not familiar enough with our XMPP service to explain why, >>>>> > while our IMAP and SMTP implementations do use it. >>>>> > >>>>> > Bill: >>>>> > >>>>> > Thanks for considering adding the user= field in order to make the move >>>>> > from XOAUTH2 to this standard easier, but I'm not sure it's worth it.  If >>>>> > the GS2 header is required, the data is already there, and clients that >>>>> > wish to add OAUTH support to their XOAUTH2 client will simple reformat >>>>> the >>>>> > request a bit. >>>>> >>>>> I'm puzzled -- could you expand on what use you make of the user field? >>>>> Like Nico, I believe it was only ever there because of a >>>>> misunderstanding.  If you make use of it, and really requires it, I >>>>> wonder if something is missing.  What do clients put in the user field, >>>>> and how do servers use that information? >>>>> >>>>> /Simon >>>>> >>> >> >>_______________________________________________ >>Kitten mailing list >>Kitten@ietf.org >>https://www.ietf.org/mailman/listinfo/kitten >> >> >> From wmills@yahoo-inc.com Tue Sep 18 15:32: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 49DD221F849A for ; Tue, 18 Sep 2012 15:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.462 X-Spam-Level: X-Spam-Status: No, score=-17.462 tagged_above=-999 required=5 tests=[AWL=0.136, 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 BmhY1o4s7TJx for ; Tue, 18 Sep 2012 15:32:27 -0700 (PDT) Received: from nm3-vm0.bullet.mail.ac4.yahoo.com (nm3-vm0.bullet.mail.ac4.yahoo.com [98.139.53.204]) by ietfa.amsl.com (Postfix) with SMTP id C637721F8516 for ; Tue, 18 Sep 2012 15:32:26 -0700 (PDT) Received: from [98.139.52.190] by nm3.bullet.mail.ac4.yahoo.com with NNFMP; 18 Sep 2012 22:32:18 -0000 Received: from [98.139.52.166] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 18 Sep 2012 22:32:18 -0000 Received: from [127.0.0.1] by omp1049.mail.ac4.yahoo.com with NNFMP; 18 Sep 2012 22:32:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 289406.85463.bm@omp1049.mail.ac4.yahoo.com Received: (qmail 83194 invoked by uid 60001); 18 Sep 2012 22:32:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348007537; bh=emJb5/DRMg69S8JvGjf56N8d93N6YHdGO8xByN0kNIc=; 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=NnAN2ioIb+ad0wg1+qqZSdHzh9lPDktXxsGT2I1F963c8M/v1g+aB/zaGy0GD5IVSlOCgpIIw/OTrQtaU90aNZztojawfKE/qKWUYcQ1RbgjhVrMaIXdYeHYC45aihukAt7lwZeMHzoHJ7vtGllTof4cpk5aK2b46Hwr9V9emOI= 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=Xq3Ub+IiQnBXTgO35Z0uoO2AaH74nuhDtBG5dL8juKZmAG5rCEEH4BJJltwaiGNK6GPX+UfBu426iAlmx8E0sq4TFIdrSdDufHy24XKKQdQO0w5SiBKMqchMKy+mPxwWocKJQhb9Avdc4v4CHJTIIBdtujq/PffOeeAHNuju954=; X-YMail-OSG: DriPoV8VM1lYWJ..uGoYKyI6xf2OSb9CMhEa3jkqQ.lrCMN NEBzGyLpOP6w5UTmeiiA9_Z4ezpZeB5wSMA1G2TgpVabL76ZBbBxu4lZSVwL 3KmH_SJ8pYhp8IYmscurDaIwZPIcmT3T6Cr66xX_5uIGZABU.UhaTQppOojS 8rqLPey7KMxyP4zxM4UhyNgyVXil5EQJtCJt91_j3voloyVLzENzgxYFXIRJ kFHzuQAxA5JbnAJAA8jaoaR8HDJMwaVdHNOsHczVVWaBeDI2h75yl0mlXOG4 iwnu9GEx6Ue111DdPhemBPamQlHdEvFv5yFZOnuknq2pBe9aZhTfQsxCW1YH utcRYer0joC1GBj1Ei9XfV3eyTpfKqMNZT9C4eKgjN8FLG7jt9RDFP8S73Ov _7jA5tCydzl3eYmmL4Vxio19Z0TpY.v9d.yIPbBg5CkgEitH1Y.e0Ll24._y .m1sDGdY- Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Tue, 18 Sep 2012 15:32:17 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> <87r4pzf6c9.fsf@latte.josefsson.org> <87obl3jaw8.fsf@latte.josefsson.org> <1348005154.32177.YahooMailNeo@web31806.mail.mud.yahoo.com> <871uhzj84q.fsf@latte.josefsson.org> Message-ID: <1348007537.59848.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Tue, 18 Sep 2012 15:32:17 -0700 (PDT) From: William Mills To: Simon Josefsson In-Reply-To: <871uhzj84q.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-1426771130-1348007537=:59848" Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 22:32:33 -0000 ---1055047407-1426771130-1348007537=:59848 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OK, so is it then reasonable to provide the user key/value as "A hint to th= e server that MAY be used as a routing hint for the server to find the corr= ect credential authenticator.=A0 The server MAY fail the authentication if = the hint indicates the wrong authenticator for the credential."?=0A=0A=0A= =0A=0A=0A>________________________________=0A> From: Simon Josefsson =0A>To: William Mills =0A>Cc: Ryan Tr= oll ; "kitten@ietf.org" =0A>Sent: Tu= esday, September 18, 2012 3:09 PM=0A>Subject: Re: [kitten] Google and SASL = OAuth=0A> =0A>William Mills writes:=0A>=0A>>>I was h= oping to get something into this mechanism that would =0A>> standardize thi= s scenario across service providers, but if the =0A>> group's=A0consensus= =A0is that it doesn't make sense to do so, so be it.=0A>>=0A>> Authz-id can= serve this purpose but it's not mandatory.=A0 You can make=0A>> it mandato= ry in your service documentation, that's as easy as making=0A>> an optional= field in the SASL data that you require.=0A>=0A>No, the authzid cannot ser= ve this purpose even if it were mandatory.=0A>This is a misunderstanding.= =A0 Ryan wants the identity of the OAuth=0A>credential owner as a routing h= int to find a server that can verify the=0A>OAuth credential for that user.= =A0 The authzid has nothing to do with=0A>that.=0A>=0A>I believe the routin= g hint and the SASL authentication identity will=0A>always be the same for = a successful authentication though.=A0 However, the=0A>authcid is implied f= rom the OAuth credential, and since the routing hint=0A>is not integrity pr= otected, you couldn't say that the authentication=0A>identity is always the= routing hint.=0A>=0A>Some mechanisms (PLAIN, SCRAM) transfer the authentic= ation identity in=0A>the clear and the OAuth mechanism could as well if peo= ple think it is=0A>useful.=0A>=0A>/Simon=0A>=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>>= ________________________________=0A>>> From: Ryan Troll =0A>>>To: Simon Josefsson =0A>>>Cc: "kitten@ietf.or= g" =0A>>>Sent: Tuesday, September 18, 2012 2:32 PM=0A>>>S= ubject: Re: [kitten] Google and SASL OAuth=0A>>> =0A>>>=0A>>>=0A>>>=0A>>>Th= anks for explaining. =A0To be sure I understand completely: you COULD=0A>>>= >have found out the example@gmail.com identity by looking into the OAuth=0A= >>>>credential (possibly using some database that eventually map the OAuth= =0A>>>>credential to the particular user), couldn't you? =0A>>>=0A>>>=0A>>>= Yes, this COULD have been done.=0A>>>=A0=0A>>>=A0So this is just a=0A>>>>co= nvenience hint for front-ends, and the internal server double-checks=0A>>>>= whether the supplied hint was indeed the right one. =A0Right?=0A>>>>=0A>>>= =0A>>>=0A>>>Yes. =A0Supplying an incorrect fails.=0A>>>=0A>>>=0A>>>=A0=0A>>= >Finally: The backend makes no use of the routing hint except for=0A>>>>com= paring it with the identity implied by the OAuth credential? =A0What=0A>>>>= I'm looking for to confirm is that there is never any doubt to the=0A>>>>in= ternal server which user identity the OAuth credential belongs to.=0A>>>>= =0A>>>=0A>>>=0A>>>=0A>>>=0A>>>This is my understanding. =A0However, it coul= d be that the backend=0A>>> totally ignores the hint, and only uses the dat= a in the OAuth=0A>>> credential. =A0This would lead to a user having access= to his data=0A>>> even if the hint was wrong, if (and only if) the hint ma= pped to the=0A>>> same backend as the user.=0A>>>=0A>>>=0A>>>Regardless, th= e identity used for data access is the OAuth=0A>>> credential. =A0The backe= nd does not use the hint as authoritative for=0A>>> anything.=0A>>>=0A>>>= =0A>>>=A0=0A>>>> Simon: =A0Does this answer your question?=0A>>>>=0A>>>>Yes= . =A0If your use-case is important, there could be a field inside the=0A>>>= >OAuth mechanism to convey this information so that servers doesn't have=0A= >>>>to look into the OAuth credential.=0A>>>>=0A>>>=0A>>>=0A>>>This was con= sidered and ruled out. =A0We're keeping our OAuth=0A>>> credentials opaque,= which means that frontends would need to perform=0A>>> additional work to = break it apart.=0A>>>=0A>>>=0A>>>=A0=0A>>>This routing hint field has nothi= ng whatsoever to do with the SASL=0A>>>>authcid or authzid though.=0A>>>>= =0A>>>>But if you are able to implement your system without this routing hi= nt,=0A>>>>it is indicative that others will be in the same situation, so I = would=0A>>>>prefer to drop the field since it adds no information but just = require=0A>>>>more text in the document to describe.=0A>>>>=0A>>>=0A>>>=0A>= >>Your recommendation is to just have Google document the user field as=0A>= >> something it needs outside of the spec? =A0In which case, the only=0A>>>= difference between our XOAUTH mechanism, and this draft, is the name=0A>>>= of the mechanism (plus our additional field)?=0A>>>=0A>>>=0A>>>I was hopin= g to get something into this mechanism that would=0A>>> standardize this sc= enario across service providers, but if the=0A>>> group's=A0consensus=A0is = that it doesn't make sense to do so, so be it.=0A>>>=0A>>>=0A>>>-R=0A>>>=0A= >>>=0A>>>=A0=0A>>>=0A>>>>/Simon=0A>>>>=0A>>>>=0A>>>>> Hannes: Yes, once thi= s draft is standardized we will add support for=0A>>>>> the conformant SASL= mechanism.=0A>>>>>=0A>>>>> Bill: Agreed. =A0When this draft becomes the la= w, we'll advertise that we=0A>>>>> require the documented GS2 header.=0A>>>= >>=0A>>>>> -R=0A>>>>>=0A>>>>>=0A>>>>> On Tue, Sep 18, 2012 at 1:01 PM, Simo= n Josefsson wrote:=0A>>>>>=0A>>>>>> Ryan Troll writes:=0A>>>>>>=0A>>>>>> > As for omitting the user informa= tion, your basically looking at why I had=0A>>>>>> > originally asked to ad= d this field as Optional -- not all services=0A>>>>>> benefit=0A>>>>>> > fr= om it. =A0I'm not familiar enough with our XMPP service to explain why,=0A>= >>>>> > while our IMAP and SMTP implementations do use it.=0A>>>>>> >=0A>>>= >>> > Bill:=0A>>>>>> >=0A>>>>>> > Thanks for considering adding the user=3D= field in order to make the move=0A>>>>>> > from XOAUTH2 to this standard e= asier, but I'm not sure it's worth it. =A0If=0A>>>>>> > the GS2 header is r= equired, the data is already there, and clients that=0A>>>>>> > wish to add= OAUTH support to their XOAUTH2 client will simple reformat=0A>>>>>> the=0A= >>>>>> > request a bit.=0A>>>>>>=0A>>>>>> I'm puzzled -- could you expand o= n what use you make of the user field?=0A>>>>>> Like Nico, I believe it was= only ever there because of a=0A>>>>>> misunderstanding. =A0If you make use= of it, and really requires it, I=0A>>>>>> wonder if something is missing. = =A0What do clients put in the user field,=0A>>>>>> and how do servers use t= hat information?=0A>>>>>>=0A>>>>>> /Simon=0A>>>>>>=0A>>>>=0A>>>=0A>>>______= _________________________________________=0A>>>Kitten mailing list=0A>>>Kit= ten@ietf.org=0A>>>https://www.ietf.org/mailman/listinfo/kitten=0A>>>=0A>>>= =0A>>>=0A>=0A>=0A> ---1055047407-1426771130-1348007537=:59848 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OK, so is= it then reasonable to provide the user key/value as "A hint to the server = that MAY be used as a routing hint for the server to find the correct crede= ntial authenticator.  The server MAY fail the authentication if the hi= nt indicates the wrong authenticator for the credential."?

From:= Simon Josefsson <simon@josefsson.org>
To: William Mills <wmills@yahoo-inc.com>
Cc: Ryan Troll <rtroll@googl= ers.com>; "kitten@ietf.org" <kitten@ietf.org>
Sent: Tuesday, September 18, 2012 3:09 P= M
Subject: Re: [kitten= ] Google and SASL OAuth

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

>>I was hoping to get somethin= g into this mechanism that would
> standardize this scenario across = service providers, but if the
> group's consensus is that = it doesn't make sense to do so, so be it.
>
> Authz-id can serv= e this purpose but it's not mandatory.  You can make
> it mandat= ory in your service documentation, that's as easy as making
> an opti= onal field in the SASL data that you require.

No, the authzid cannot ser= ve this purpose even if it were mandatory.
This is a misunderstanding.&n= bsp; Ryan wants the identity of the OAuth
credential owner as a routing = hint to find a server that can verify the
OAuth credential for that user= .  The authzid has nothing to do with
that.

I believe the ro= uting hint and the SASL authentication identity will
always be the same = for a successful authentication though.  However, the
authcid is im= plied from the OAuth credential, and since the routing hint
is not integ= rity protected, you couldn't say that the authentication
identity is alw= ays the routing hint.

Some mechanisms (PLAIN, SCRAM) transfer the au= thentication identity in
the clear and the OAuth mechanism could as well= if people think it is
useful.

/Simon

>
>
>
>
>>>________________________________
>> From: Ryan Troll <= rtroll@googlers.com>
>>To: Simon Josefsson <simon@= josefsson.org>
>>Cc: "kitten@ietf.org" <kitten@ietf.org&g= t;
>>Sent: Tuesday, September 18, 2012 2:32 PM
>>Subject= : Re: [kitten] Google and SASL OAuth
>>
>>
>>>>
>>Thanks for explaining.  To be sure I understand = completely: you COULD
>>>have found out the example@gmail.com identity by looking into the OAuth
>>>credential (possibly using some data= base that eventually map the OAuth
>>>credential to the particu= lar user), couldn't you?
>>
>>
>>Yes, this COUL= D have been done.
>> 
>> So this is just a
&= gt;>>convenience hint for front-ends, and the internal server double-= checks
>>>whether the supplied hint was indeed the right one. &= nbsp;Right?
>>>
>>
>>
>>Yes.  S= upplying an incorrect fails.
>>
>>
>> 
&= gt;>Finally: The backend makes no use of the routing hint except for
= >>>comparing it with the identity implied by the OAuth credential?=  What
>>>I'm looking for to confirm is that there is neve= r any doubt to the
>>>internal server which user identity the O= Auth credential belongs to.
>>>
>>
>>
>>
>>
>= ;>This is my understanding.  However, it could be that the backend<= br>>> totally ignores the hint, and only uses the data in the OAuth>> credential.  This would lead to a user having access to his= data
>> even if the hint was wrong, if (and only if) the hint map= ped to the
>> same backend as the user.
>>
>>>>Regardless, the identity used for data access is the OAuth
>= > credential.  The backend does not use the hint as authoritative f= or
>> anything.
>>
>>
>> 
>&= gt;> Simon:  Does this answer your question?
>>>
>= ;>>Yes.  If your use-case is important, there could be a field i= nside the
>>>OAuth mechanism to convey this information so that= servers doesn't have
>>>to look into the OAuth credential.
>>>
>>
>>
>>This was co= nsidered and ruled out.  We're keeping our OAuth
>> credentia= ls opaque, which means that frontends would need to perform
>> add= itional work to break it apart.
>>
>>
>> >>This routing hint field has nothing whatsoever to do with the SAS= L
>>>authcid or authzid though.
>>>
>>>= But if you are able to implement your system without this routing hint,
= >>>it is indicative that others will be in the same situation, so = I would
>>>prefer to drop the field since it adds no informatio= n but just require
>>>more text in the document to describe.>>>
>>
>>
>>Your recommendation is to = just have Google document the user field as
>> something it needs = outside of the spec?  In which case, the only
>> difference between our XOAUTH mechanism, and this draft, is the name
&g= t;> of the mechanism (plus our additional field)?
>>
>>= ;
>>I was hoping to get something into this mechanism that would>> standardize this scenario across service providers, but if the>> group's consensus is that it doesn't make sense to do = so, so be it.
>>
>>
>>-R
>>
>>=
>> 
>>
>>>/Simon
>>>
>= ;>>
>>>> Hannes: Yes, once this draft is standardized = we will add support for
>>>> the conformant SASL mechanism.<= br>>>>>
>>>> Bill: Agreed.  When this draft= becomes the law, we'll advertise that we
>>>> require the d= ocumented GS2 header.
>>>>
>>>> -R
>>= ;>>
>>>>
>>>> On Tue, Sep 18, 2012 at 1:01 PM, Simon Josefsson <simon@josefsson.org>wrote:<= br>>>>>
>>>>> Ryan Troll <rtroll@google= rs.com> writes:
>>>>>
>>>>> >= As for omitting the user information, your basically looking at why I had<= br>>>>>> > originally asked to add this field as Optional= -- not all services
>>>>> benefit
>>>>>= ; > from it.  I'm not familiar enough with our XMPP service to expl= ain why,
>>>>> > while our IMAP and SMTP implementatio= ns do use it.
>>>>> >
>>>>> > Bil= l:
>>>>> >
>>>>> > Thanks for con= sidering adding the user=3D field in order to make the move
>>>>> > from XOAUTH2 to this standard easier, bu= t I'm not sure it's worth it.  If
>>>>> > the GS2= header is required, the data is already there, and clients that
>>= ;>>> > wish to add OAUTH support to their XOAUTH2 client will s= imple reformat
>>>>> the
>>>>> > req= uest a bit.
>>>>>
>>>>> I'm puzzled -- = could you expand on what use you make of the user field?
>>>>= ;> Like Nico, I believe it was only ever there because of a
>>&= gt;>> misunderstanding.  If you make use of it, and really requi= res it, I
>>>>> wonder if something is missing.  Wha= t do clients put in the user field,
>>>>> and how do serv= ers use that information?
>>>>>
>>>>> /Simon
>>>>>
>>>
>>
>>____= ___________________________________________
>>Kitten mailing list<= br>>>Kitten@ietf.org
>>https://www.ietf.org/mailman/listinfo/= kitten
>>
>>
>>


---1055047407-1426771130-1348007537=:59848-- From rtroll@google.com Tue Sep 18 15:36: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 C53DC11E80A6 for ; Tue, 18 Sep 2012 15:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.768 X-Spam-Level: X-Spam-Status: No, score=-102.768 tagged_above=-999 required=5 tests=[AWL=0.208, 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 EtHZ7Zh6GiQq for ; Tue, 18 Sep 2012 15:36:20 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6A221F8522 for ; Tue, 18 Sep 2012 15:36:20 -0700 (PDT) Received: by iabz21 with SMTP id z21so329019iab.31 for ; Tue, 18 Sep 2012 15:36: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=3DSIudQviZIJURCkB6jRgPw5n6o7HEyF58/O0XHtzRM=; b=EHa6/77JhAaSssRE2P+j33ffFlYYsU2ScD6q5uOXVB7Ovsb3f9mqjNBH+NBt8jsblH 2ZLz+CBvlx7ppRQnYHVGvneMu5dLa2KUaYVR3qLNrpsuMuy4rUpNUfa3XlKKNrjKqG1T ae0wbRSYE/Ifp86iLoDba0M2ODaObD/bys3n4= 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=3DSIudQviZIJURCkB6jRgPw5n6o7HEyF58/O0XHtzRM=; b=bc2Uqtal+h5bPz2Qw/70wezOTU29wRImaorCuzACFtgUwtTu2zOA/Qv7SpS4o2BXoV F4cIJlr6du1hZN7NBcxw8RWZxUA3sjM1inCJTwiwCm8LVPb1UWIzKG51lZG9mRazmUt9 voZGz3cT4+L4YJgCgFXSvOqkTcdqjZnqrKWRf8SZ3GErjOjFFDNmbMyaCR3qIojjg6kL fdqyGTfESVB6D38QhsbyOriumkfUrpaYecXhd4vUnbhLFj7qx37S1YI7+GaLM2oJ+MeX bHjLq4KceIWrTqXr662yI12WflSmKIv2H3lzTGHBJAlnSw0n54mPtIxk/x5toNQy2N4X 1IXg== Received: by 10.50.195.193 with SMTP id ig1mr1380890igc.19.1348007780227; Tue, 18 Sep 2012 15:36:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.195.193 with SMTP id ig1mr1380878igc.19.1348007780033; Tue, 18 Sep 2012 15:36:20 -0700 (PDT) Received: by 10.50.36.131 with HTTP; Tue, 18 Sep 2012 15:36:19 -0700 (PDT) In-Reply-To: <87fw6fj98s.fsf@latte.josefsson.org> References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> <87r4pzf6c9.fsf@latte.josefsson.org> <87obl3jaw8.fsf@latte.josefsson.org> <87fw6fj98s.fsf@latte.josefsson.org> Date: Tue, 18 Sep 2012 15:36:19 -0700 Message-ID: From: Ryan Troll To: Simon Josefsson Content-Type: multipart/alternative; boundary=14dae9340c79e2259804ca0184fc X-System-Of-Record: true X-Gm-Message-State: ALoCoQk2+OIw0jSAzjgnAKoQn+Dtmz5PQ0/0XyikP+iH44NgNtJH8cMmNPqa84RofpuXq0a/FjfTDGwMI7E5S39Cm1JtxWGbAQ2qGcWiL7NH1v+/aPCTXJSELSAg6LLEdkN/4H9iZ30qtGygYPHbAriZ6eyQgvY/EmFeyBIhBA1Q7XORt/m6YikoJFSOW3cA7djjAzKSzGVh Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 22:36:21 -0000 --14dae9340c79e2259804ca0184fc Content-Type: text/plain; charset=ISO-8859-1 > > Your recommendation is to just have Google document the user field as > > something it needs outside of the spec? In which case, the only > difference > > between our XOAUTH mechanism, and this draft, is the name of the > mechanism > > (plus our additional field)? > > I would recommend/hope that you implement the draft that eventually > comes out of this WG and phase out your experimental XOAUTH* stuff at > that point. > I've already been telling folks here that we should implement this draft once finalized. Never had pushback, so I expect it will happen. Removing the experimental stuff will depend on how many folks actually use it. If there's significant usage, there's no compelling reason for us to work to move folks off of it, to something that is essentially a re-ordering of the bits in the request. We don't want to put developers through busy-work. > > I was hoping to get something into this mechanism that would standardize > > this scenario across service providers, but if the group's consensus is > > that it doesn't make sense to do so, so be it. > > Your input is part of the consensus process. What I'm not getting now > is whether you can & will adapt to a design without a routing hint and > change your implementation, or if you'd rather publish a separate > document describing your variation of the mechanism and deploy that > under a different SASL name? If the latter, I think we are having a WG > failure and need to reconsider what changes to the document would make > you happier. > This came up back when I was describing this scenario to Nico. No, we will not be changing to a design without a routing hint. The Google IMAP and SMTP services will continue to require it. Making the routing hint a cleartext part of the OAuth token is something we've considered and ruled out -- we're endeavoring to keep the token 100% opaque, removing the ability for abusers to glean any information about an account from a token. And we don't want to have a special token just for IMAP/SMTP. I'm not plannong on publishing another SASL mechanism with this single addition - that would not be beneficial to anybody. If there is no place to store this information in what's in the SASL/OAuth RFC, when we publish a mechanism that is compliant with it, we'll document the additional item we require (routing hint) in our developer documentation. And endeavor to have the failure error message enable developers to quickly identify this difference. I'd love to see a hint of sorts be part of the SASL/OAuth negotiation, as we are likely not the only service provider with this requirement. The list has been great at listening and helping try to solve how to do this; if it turns out this doesn't wind up in the standard, it's certainly not for lack of trying. -R > > /Simon > > > > -R > > > > > > > >> > >> /Simon > >> > >> > Hannes: Yes, once this draft is standardized we will add support for > >> > the conformant SASL mechanism. > >> > > >> > Bill: Agreed. When this draft becomes the law, we'll advertise that > we > >> > require the documented GS2 header. > >> > > >> > -R > >> > > >> > > >> > On Tue, Sep 18, 2012 at 1:01 PM, Simon Josefsson >> >wrote: > >> > > >> >> Ryan Troll writes: > >> >> > >> >> > As for omitting the user information, your basically looking at > why I > >> had > >> >> > originally asked to add this field as Optional -- not all services > >> >> benefit > >> >> > from it. I'm not familiar enough with our XMPP service to explain > >> why, > >> >> > while our IMAP and SMTP implementations do use it. > >> >> > > >> >> > Bill: > >> >> > > >> >> > Thanks for considering adding the user= field in order to make the > >> move > >> >> > from XOAUTH2 to this standard easier, but I'm not sure it's worth > it. > >> If > >> >> > the GS2 header is required, the data is already there, and clients > >> that > >> >> > wish to add OAUTH support to their XOAUTH2 client will simple > reformat > >> >> the > >> >> > request a bit. > >> >> > >> >> I'm puzzled -- could you expand on what use you make of the user > field? > >> >> Like Nico, I believe it was only ever there because of a > >> >> misunderstanding. If you make use of it, and really requires it, I > >> >> wonder if something is missing. What do clients put in the user > field, > >> >> and how do servers use that information? > >> >> > >> >> /Simon > >> >> > >> > --14dae9340c79e2259804ca0184fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Your recommendation is to just have Google document the user field as<= br> > something it needs outside of the spec? =A0In which case, the only dif= ference
> between our XOAUTH mechanism, and this draft, is the name of the mecha= nism
> (plus our additional field)?

I would recommend/hope that you implement the draft that eventually comes out of this WG and phase out your experimental XOAUTH* stuff at
that point.

I've already been telli= ng folks here that we should implement this draft once finalized. =A0Never = had pushback, so I expect it will happen.

Removing= the experimental stuff will depend on how many folks actually use it. =A0I= f there's significant usage, there's no compelling reason for us to= work to move folks off of it, to something that is essentially a re-orderi= ng of the bits in the request. =A0We don't want to put developers throu= gh busy-work.

=A0
> I was hoping to get something into this mechanism th= at would standardize
> this scenario across service providers, but if the group's consens= us is
> that it doesn't make sense to do so, so be it.

Your input is part of the consensus process. =A0What I'm not gett= ing now
is whether you can & will adapt to a design without a routing hint and<= br> change your implementation, or if you'd rather publish a separate
document describing your variation of the mechanism and deploy that
under a different SASL name? =A0If the latter, I think we are having a WG failure and need to reconsider what changes to the document would make
you happier.

This came up back when I w= as describing this scenario to Nico.

No, we will n= ot be changing to a design without a routing hint. =A0The Google IMAP and S= MTP services will continue to require it. =A0Making the routing hint a clea= rtext part of the OAuth token is something we've considered and ruled o= ut -- we're endeavoring to keep the token 100% opaque, removing the abi= lity for abusers to glean any information about an account from a token. = =A0And we don't want to have a special token just for IMAP/SMTP.

I'm not plannong on publishing another SASL mechani= sm with this single addition - that would not be beneficial to anybody. =A0= If there is no place to store this information in what's in the SASL/OA= uth RFC, when we publish a mechanism that is compliant with it, we'll d= ocument the additional item we require (routing hint) in our developer docu= mentation. =A0And endeavor to have the failure error message enable develop= ers to quickly identify this difference.

I'd love to see a hint of sorts be part of the SASL= /OAuth negotiation, as we are likely not the only service provider with thi= s requirement. =A0The list has been great at listening and helping try to s= olve how to do this; if it turns out this doesn't wind up in the standa= rd, it's certainly not for lack of trying.

-R
=A0

/Simon


> -R
>
>
>
>>
>> /Simon
>>
>> > Hannes: Yes, once this draft is standardized we will add supp= ort for
>> > the conformant SASL mechanism.
>> >
>> > Bill: Agreed. =A0When this draft becomes the law, we'll a= dvertise that we
>> > require the documented GS2 header.
>> >
>> > -R
>> >
>> >
>> > On Tue, Sep 18, 2012 at 1:01 PM, Simon Josefsson <simon@josefsson.org
>> >wrote:
>> >
>> >> Ryan Troll <rtr= oll@googlers.com> writes:
>> >>
>> >> > As for omitting the user information, your basically= looking at why I
>> had
>> >> > originally asked to add this field as Optional -- no= t all services
>> >> benefit
>> >> > from it. =A0I'm not familiar enough with our XMP= P service to explain
>> why,
>> >> > while our IMAP and SMTP implementations do use it. >> >> >
>> >> > Bill:
>> >> >
>> >> > Thanks for considering adding the user=3D field in o= rder to make the
>> move
>> >> > from XOAUTH2 to this standard easier, but I'm no= t sure it's worth it.
>> =A0If
>> >> > the GS2 header is required, the data is already ther= e, and clients
>> that
>> >> > wish to add OAUTH support to their XOAUTH2 client wi= ll simple reformat
>> >> the
>> >> > request a bit.
>> >>
>> >> I'm puzzled -- could you expand on what use you make = of the user field?
>> >> Like Nico, I believe it was only ever there because of a<= br> >> >> misunderstanding. =A0If you make use of it, and really re= quires it, I
>> >> wonder if something is missing. =A0What do clients put in= the user field,
>> >> and how do servers use that information?
>> >>
>> >> /Simon
>> >>
>>

--14dae9340c79e2259804ca0184fc-- From cantor.2@osu.edu Tue Sep 18 16:05: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 9262E11E809A for ; Tue, 18 Sep 2012 16:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 OEEzw-+k-iHv for ; Tue, 18 Sep 2012 16:05:50 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id F062611E80A3 for ; Tue, 18 Sep 2012 16:05:49 -0700 (PDT) Received: from mail113-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Sep 2012 23:05:38 +0000 Received: from mail113-ch1 (localhost [127.0.0.1]) by mail113-ch1-R.bigfish.com (Postfix) with ESMTP id 7B5DE1C022E; Tue, 18 Sep 2012 23:05:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.37; KIP:(null); UIP:(null); IPV:NLI; H:CIO-KRC-HT01.osuad.osu.edu; RD:cio-krc-ht01.osuad.osu.edu; EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zzbb2dI98dI9371I1432Id6f1izz1202h1d1ah1d2ahzz8275dhz2fh87h2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail113-ch1: domain of osu.edu designates 164.107.81.37 as permitted sender) client-ip=164.107.81.37; envelope-from=cantor.2@osu.edu; helo=CIO-KRC-HT01.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail113-ch1 (localhost.localdomain [127.0.0.1]) by mail113-ch1 (MessageSwitch) id 1348009537270747_8967; Tue, 18 Sep 2012 23:05:37 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.243]) by mail113-ch1.bigfish.com (Postfix) with ESMTP id 3DFA12A004E; Tue, 18 Sep 2012 23:05:37 +0000 (UTC) Received: from CIO-KRC-HT01.osuad.osu.edu (164.107.81.37) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Sep 2012 23:05:37 +0000 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; Tue, 18 Sep 2012 19:05:35 -0400 From: "Cantor, Scott" To: Simon Josefsson Thread-Topic: [kitten] Google and SASL OAuth Thread-Index: AQHNlepDvUDtSOgX70WW0RrYcbNMvJeQuHuA Date: Tue, 18 Sep 2012 23:05:34 +0000 Message-ID: In-Reply-To: <871uhzj84q.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.52] Content-Type: text/plain; charset="us-ascii" Content-ID: <27E5C8C6700B91499071FD0EC2C85069@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Tue, 18 Sep 2012 23:05:50 -0000 On 9/18/12 6:09 PM, "Simon Josefsson" wrote: >> >> Authz-id can serve this purpose but it's not mandatory. You can make >> it mandatory in your service documentation, that's as easy as making >> an optional field in the SASL data that you require. > >No, the authzid cannot serve this purpose even if it were mandatory. >This is a misunderstanding. Ryan wants the identity of the OAuth >credential owner as a routing hint to find a server that can verify the >OAuth credential for that user. The authzid has nothing to do with >that. I thought from the earlier description that the purpose of the hint was to identify the server hosting the mailbox of the "effective" identity involved, which to me seemed an awful lot like authzid. For my own SASL understanding, how is it different? And where would authzid or the routing hint here come from if not from the username entered by the user into the client? And if so, how can they not be one and the same? -- Scott From lukeh@padl.com Tue Sep 18 18:28: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 F062921E8040 for ; Tue, 18 Sep 2012 18:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 8GUkDxshd2-7 for ; Tue, 18 Sep 2012 18:28:52 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6844B21E8037 for ; Tue, 18 Sep 2012 18:28:52 -0700 (PDT) Received: by us.padl.com with ESMTP id q8J1SljU005676; Tue, 18 Sep 2012 21:28:49 -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, 19 Sep 2012 11:28:45 +1000 Content-Transfer-Encoding: 7bit Message-Id: References: To: "Cantor, Scott" 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] Google and 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: Wed, 19 Sep 2012 01:28:53 -0000 >> No, the authzid cannot serve this purpose even if it were mandatory. >> This is a misunderstanding. Ryan wants the identity of the OAuth >> credential owner as a routing hint to find a server that can verify the >> OAuth credential for that user. The authzid has nothing to do with >> that. > > I thought from the earlier description that the purpose of the hint was to > identify the server hosting the mailbox of the "effective" identity > involved, which to me seemed an awful lot like authzid. I am with Scott here in this understanding. -- Luke From simon@josefsson.org Wed Sep 19 00:11: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 18A3E21F8620 for ; Wed, 19 Sep 2012 00:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.837 X-Spam-Level: X-Spam-Status: No, score=-99.837 tagged_above=-999 required=5 tests=[AWL=0.072, 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 RFTePnM3MBgN for ; Wed, 19 Sep 2012 00:11: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 E9FCC21F856C for ; Wed, 19 Sep 2012 00:11:13 -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 q8J7B44B006539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Sep 2012 09:11:05 +0200 From: Simon Josefsson To: "Cantor\, Scott" References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120919:kitten@ietf.org::eJqk2PdNvb4sURMP:3175 X-Hashcash: 1:22:120919:cantor.2@osu.edu::6XyV4dzwo2JR0ArB:KA+F Date: Wed, 19 Sep 2012 09:11:03 +0200 In-Reply-To: (Scott Cantor's message of "Tue, 18 Sep 2012 23:05:34 +0000") Message-ID: <87pq5iij20.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] Google and 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: Wed, 19 Sep 2012 07:11:19 -0000 "Cantor, Scott" writes: > On 9/18/12 6:09 PM, "Simon Josefsson" wrote: >>> >>> Authz-id can serve this purpose but it's not mandatory. You can make >>> it mandatory in your service documentation, that's as easy as making >>> an optional field in the SASL data that you require. >> >>No, the authzid cannot serve this purpose even if it were mandatory. >>This is a misunderstanding. Ryan wants the identity of the OAuth >>credential owner as a routing hint to find a server that can verify the >>OAuth credential for that user. The authzid has nothing to do with >>that. > > I thought from the earlier description that the purpose of the hint was to > identify the server hosting the mailbox of the "effective" identity > involved, which to me seemed an awful lot like authzid. That's not what I understand from the latest explanation: as I understand Ryan, the routing hint is there to identify the server that is able to validate the OAuth credential. That makes the routing hint effectively the authentication identity, although the routing hint cannot be relied on as the authentication identity until the credential has been validated to belonging to the claimed user. Ryan could you clarify for us again, please? /Simon From simon@josefsson.org Wed Sep 19 00:47: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 E706421F8650 for ; Wed, 19 Sep 2012 00:47:58 -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 ZmjPrtGakerS for ; Wed, 19 Sep 2012 00:47: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 D586221F863C for ; Wed, 19 Sep 2012 00:47: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 q8J7lnUX008363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Sep 2012 09:47:50 +0200 From: Simon Josefsson To: William Mills References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> <87r4pzf6c9.fsf@latte.josefsson.org> <87obl3jaw8.fsf@latte.josefsson.org> <1348005154.32177.YahooMailNeo@web31806.mail.mud.yahoo.com> <871uhzj84q.fsf@latte.josefsson.org> <1348007537.59848.YahooMailNeo__26057.019775226$1348007565$gmane$org@web31806.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120919:wmills@yahoo-inc.com::v0VP1xsJEHLV1Xdx:GouV X-Hashcash: 1:22:120919:kitten@ietf.org::N3Erlv64AC8LDN1r:00i4q Date: Wed, 19 Sep 2012 09:47:48 +0200 In-Reply-To: <1348007537.59848.YahooMailNeo__26057.019775226$1348007565$gmane$org@web31806.mail.mud.yahoo.com> (William Mills's message of "Tue, 18 Sep 2012 15:32:17 -0700 (PDT)") Message-ID: <87zk4mh2sb.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] Google and 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: Wed, 19 Sep 2012 07:47:59 -0000 William Mills writes: > OK, so is it then reasonable to provide the user key/value as "A hint > to the server that MAY be used as a routing hint for the server to > find the correct credential authenticator.  The server MAY fail the > authentication if the hint indicates the wrong authenticator for the > credential."? Yes, although let's first see if I understood Ryan correctly this time around... /Simon > > > > >>________________________________ >> From: Simon Josefsson >>To: William Mills >>Cc: Ryan Troll ; "kitten@ietf.org" >>Sent: Tuesday, September 18, 2012 3:09 PM >>Subject: Re: [kitten] Google and SASL OAuth >> >>William Mills writes: >> >>>>I was hoping to get something into this mechanism that would >>> standardize this scenario across service providers, but if the >>> group's consensus is that it doesn't make sense to do so, so be it. >>> >>> Authz-id can serve this purpose but it's not mandatory.  You can make >>> it mandatory in your service documentation, that's as easy as making >>> an optional field in the SASL data that you require. >> >>No, the authzid cannot serve this purpose even if it were mandatory. >>This is a misunderstanding.  Ryan wants the identity of the OAuth >>credential owner as a routing hint to find a server that can verify the >>OAuth credential for that user.  The authzid has nothing to do with >>that. >> >>I believe the routing hint and the SASL authentication identity will >>always be the same for a successful authentication though.  However, the >>authcid is implied from the OAuth credential, and since the routing hint >>is not integrity protected, you couldn't say that the authentication >>identity is always the routing hint. >> >>Some mechanisms (PLAIN, SCRAM) transfer the authentication identity in >>the clear and the OAuth mechanism could as well if people think it is >>useful. >> >>/Simon >> >>> >>> >>> >>> >>> >>>>________________________________ >>>> From: Ryan Troll >>>>To: Simon Josefsson >>>>Cc: "kitten@ietf.org" >>>>Sent: Tuesday, September 18, 2012 2:32 PM >>>>Subject: Re: [kitten] Google and SASL OAuth >>>> >>>> >>>> >>>> >>>>Thanks for explaining.  To be sure I understand completely: you COULD >>>>>have found out the example@gmail.com identity by looking into the OAuth >>>>>credential (possibly using some database that eventually map the OAuth >>>>>credential to the particular user), couldn't you? >>>> >>>> >>>>Yes, this COULD have been done. >>>>  >>>> So this is just a >>>>>convenience hint for front-ends, and the internal server double-checks >>>>>whether the supplied hint was indeed the right one.  Right? >>>>> >>>> >>>> >>>>Yes.  Supplying an incorrect fails. >>>> >>>> >>>>  >>>>Finally: The backend makes no use of the routing hint except for >>>>>comparing it with the identity implied by the OAuth credential?  What >>>>>I'm looking for to confirm is that there is never any doubt to the >>>>>internal server which user identity the OAuth credential belongs to. >>>>> >>>> >>>> >>>> >>>> >>>>This is my understanding.  However, it could be that the backend >>>> totally ignores the hint, and only uses the data in the OAuth >>>> credential.  This would lead to a user having access to his data >>>> even if the hint was wrong, if (and only if) the hint mapped to the >>>> same backend as the user. >>>> >>>> >>>>Regardless, the identity used for data access is the OAuth >>>> credential.  The backend does not use the hint as authoritative for >>>> anything. >>>> >>>> >>>>  >>>>> Simon:  Does this answer your question? >>>>> >>>>>Yes.  If your use-case is important, there could be a field inside the >>>>>OAuth mechanism to convey this information so that servers doesn't have >>>>>to look into the OAuth credential. >>>>> >>>> >>>> >>>>This was considered and ruled out.  We're keeping our OAuth >>>> credentials opaque, which means that frontends would need to perform >>>> additional work to break it apart. >>>> >>>> >>>>  >>>>This routing hint field has nothing whatsoever to do with the SASL >>>>>authcid or authzid though. >>>>> >>>>>But if you are able to implement your system without this routing hint, >>>>>it is indicative that others will be in the same situation, so I would >>>>>prefer to drop the field since it adds no information but just require >>>>>more text in the document to describe. >>>>> >>>> >>>> >>>>Your recommendation is to just have Google document the user field as >>>> something it needs outside of the spec?  In which case, the only >>>> difference between our XOAUTH mechanism, and this draft, is the name >>>> of the mechanism (plus our additional field)? >>>> >>>> >>>>I was hoping to get something into this mechanism that would >>>> standardize this scenario across service providers, but if the >>>> group's consensus is that it doesn't make sense to do so, so be it. >>>> >>>> >>>>-R >>>> >>>> >>>>  >>>> >>>>>/Simon >>>>> >>>>> >>>>>> Hannes: Yes, once this draft is standardized we will add support for >>>>>> the conformant SASL mechanism. >>>>>> >>>>>> Bill: Agreed.  When this draft becomes the law, we'll advertise that we >>>>>> require the documented GS2 header. >>>>>> >>>>>> -R >>>>>> >>>>>> >>>>>> On Tue, Sep 18, 2012 at 1:01 PM, Simon Josefsson >>>>>> wrote: >>>>>> >>>>>>> Ryan Troll writes: >>>>>>> >>>>>>> > As for omitting the user information, your basically looking >>>>>>> > at why I had >>>>>>> > originally asked to add this field as Optional -- not all services >>>>>>> benefit >>>>>>> > from it.  I'm not familiar enough with our XMPP service to explain why, >>>>>>> > while our IMAP and SMTP implementations do use it. >>>>>>> > >>>>>>> > Bill: >>>>>>> > >>>>>>> > Thanks for considering adding the user= field in order to make the move >>>>>>> > from XOAUTH2 to this standard easier, but I'm not sure it's >>>>>>> > worth it.  If >>>>>>> > the GS2 header is required, the data is already there, and clients that >>>>>>> > wish to add OAUTH support to their XOAUTH2 client will simple reformat >>>>>>> the >>>>>>> > request a bit. >>>>>>> >>>>>>> I'm puzzled -- could you expand on what use you make of the user field? >>>>>>> Like Nico, I believe it was only ever there because of a >>>>>>> misunderstanding.  If you make use of it, and really requires it, I >>>>>>> wonder if something is missing.  What do clients put in the user field, >>>>>>> and how do servers use that information? >>>>>>> >>>>>>> /Simon >>>>>>> >>>>> >>>> >>>>_______________________________________________ >>>>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 simon@josefsson.org Wed Sep 19 00:53: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 D312721F866E for ; Wed, 19 Sep 2012 00:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.844 X-Spam-Level: X-Spam-Status: No, score=-99.844 tagged_above=-999 required=5 tests=[AWL=0.065, 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 zMJQR4-uXqlO for ; Wed, 19 Sep 2012 00:53: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 D3FF821F8669 for ; Wed, 19 Sep 2012 00:53:07 -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 q8J7qve2008612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Sep 2012 09:52:59 +0200 From: Simon Josefsson To: Ryan Troll References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> <87r4pzf6c9.fsf@latte.josefsson.org> <87obl3jaw8.fsf@latte.josefsson.org> <87fw6fj98s.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120919:rtroll@googlers.com::PGfX5i8hG4ZAQ9b4:6Nzk X-Hashcash: 1:22:120919:kitten@ietf.org::9B/GarAbbfxVMvoK:WYGf Date: Wed, 19 Sep 2012 09:52:57 +0200 In-Reply-To: (Ryan Troll's message of "Tue, 18 Sep 2012 15:36:19 -0700") Message-ID: <87vcfah2jq.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] Google and 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: Wed, 19 Sep 2012 07:53:08 -0000 Ryan Troll writes: >> > Your recommendation is to just have Google document the user field as >> > something it needs outside of the spec? In which case, the only >> difference >> > between our XOAUTH mechanism, and this draft, is the name of the >> mechanism >> > (plus our additional field)? >> >> I would recommend/hope that you implement the draft that eventually >> comes out of this WG and phase out your experimental XOAUTH* stuff at >> that point. >> > > I've already been telling folks here that we should implement this draft > once finalized. Never had pushback, so I expect it will happen. > > Removing the experimental stuff will depend on how many folks actually use > it. If there's significant usage, there's no compelling reason for us to > work to move folks off of it, to something that is essentially a > re-ordering of the bits in the request. We don't want to put developers > through busy-work. Sure. "phase out" can take a while. If we do everything right, implementations will migrate to the proper RFC variant and not the X-variant eventually. >> > I was hoping to get something into this mechanism that would standardize >> > this scenario across service providers, but if the group's consensus is >> > that it doesn't make sense to do so, so be it. >> >> Your input is part of the consensus process. What I'm not getting now >> is whether you can & will adapt to a design without a routing hint and >> change your implementation, or if you'd rather publish a separate >> document describing your variation of the mechanism and deploy that >> under a different SASL name? If the latter, I think we are having a WG >> failure and need to reconsider what changes to the document would make >> you happier. >> > > This came up back when I was describing this scenario to Nico. > > No, we will not be changing to a design without a routing hint. The Google > IMAP and SMTP services will continue to require it. Making the routing > hint a cleartext part of the OAuth token is something we've considered and > ruled out -- we're endeavoring to keep the token 100% opaque, removing the > ability for abusers to glean any information about an account from a token. > And we don't want to have a special token just for IMAP/SMTP. > > I'm not plannong on publishing another SASL mechanism with this single > addition - that would not be beneficial to anybody. If there is no place > to store this information in what's in the SASL/OAuth RFC, when we publish > a mechanism that is compliant with it, we'll document the additional item > we require (routing hint) in our developer documentation. And endeavor to > have the failure error message enable developers to quickly identify this > difference. To me this sounds as if you'd rather fork the spec than live without a routing hint -- having a document describing something additional outside the RFCs is essentially the same as forking it. However, it seems there is still not agreement on what you are using the routing hint for, so please reply to the other post whether it is to find the server with the intended mailbox (authzid) or to find the server that is able to verify the OAuth credential (authcid). /Simon > I'd love to see a hint of sorts be part of the SASL/OAuth negotiation, as > we are likely not the only service provider with this requirement. The > list has been great at listening and helping try to solve how to do this; > if it turns out this doesn't wind up in the standard, it's certainly not > for lack of trying. > > -R > > >> >> /Simon >> >> >> > -R >> > >> > >> > >> >> >> >> /Simon >> >> >> >> > Hannes: Yes, once this draft is standardized we will add support for >> >> > the conformant SASL mechanism. >> >> > >> >> > Bill: Agreed. When this draft becomes the law, we'll advertise that >> we >> >> > require the documented GS2 header. >> >> > >> >> > -R >> >> > >> >> > >> >> > On Tue, Sep 18, 2012 at 1:01 PM, Simon Josefsson > >> >wrote: >> >> > >> >> >> Ryan Troll writes: >> >> >> >> >> >> > As for omitting the user information, your basically looking at >> why I >> >> had >> >> >> > originally asked to add this field as Optional -- not all services >> >> >> benefit >> >> >> > from it. I'm not familiar enough with our XMPP service to explain >> >> why, >> >> >> > while our IMAP and SMTP implementations do use it. >> >> >> > >> >> >> > Bill: >> >> >> > >> >> >> > Thanks for considering adding the user= field in order to make the >> >> move >> >> >> > from XOAUTH2 to this standard easier, but I'm not sure it's worth >> it. >> >> If >> >> >> > the GS2 header is required, the data is already there, and clients >> >> that >> >> >> > wish to add OAUTH support to their XOAUTH2 client will simple >> reformat >> >> >> the >> >> >> > request a bit. >> >> >> >> >> >> I'm puzzled -- could you expand on what use you make of the user >> field? >> >> >> Like Nico, I believe it was only ever there because of a >> >> >> misunderstanding. If you make use of it, and really requires it, I >> >> >> wonder if something is missing. What do clients put in the user >> field, >> >> >> and how do servers use that information? >> >> >> >> >> >> /Simon >> >> >> >> >> >> > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From simon@josefsson.org Wed Sep 19 01:01: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 2D2E621F8766 for ; Wed, 19 Sep 2012 01:01:19 -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 fzYZQJ60c20H for ; Wed, 19 Sep 2012 01:01: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 9980E21F875B for ; Wed, 19 Sep 2012 01:01:13 -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 q8J8158v009139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Sep 2012 10:01:06 +0200 From: Simon Josefsson To: Luke Howard References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120919:lukeh@padl.com::No+qDTbp7PHVbgYV:kVz X-Hashcash: 1:22:120919:cantor.2@osu.edu::0iBie4aU53oXOHm/:7xun X-Hashcash: 1:22:120919:kitten@ietf.org::KZvmFWAq3azcLlQI:UpsP Date: Wed, 19 Sep 2012 10:01:04 +0200 In-Reply-To: (Luke Howard's message of "Wed, 19 Sep 2012 11:28:45 +1000") Message-ID: <87r4pyh267.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] Google and 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: Wed, 19 Sep 2012 08:01:19 -0000 Luke Howard writes: >>> No, the authzid cannot serve this purpose even if it were mandatory. >>> This is a misunderstanding. Ryan wants the identity of the OAuth >>> credential owner as a routing hint to find a server that can verify the >>> OAuth credential for that user. The authzid has nothing to do with >>> that. >> >> I thought from the earlier description that the purpose of the hint was to >> identify the server hosting the mailbox of the "effective" identity >> involved, which to me seemed an awful lot like authzid. > > I am with Scott here in this understanding. The reason I interpreted this differently was that Ryan confirmed that he could have gotten the routing hint information from the OAuth credential but he preferred to treat the OAuth credential as opaque and thus needed to get it from somewhere else. I don't see how you could ever hope to get the SASL authzid out of an OAuth credential? The authzid is asserted by the SASL client and is unrelated to the credential... ...unless the application is assumed to acquire a new OAuth credential for every unique SASL authzid it wish to use...? /Simon From ve7jtb@ve7jtb.com Wed Sep 19 07:50: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 9D7DD21F867C for ; Wed, 19 Sep 2012 07:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 6izoFa6GYBUh for ; Wed, 19 Sep 2012 07:50:22 -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 C62AB21F8653 for ; Wed, 19 Sep 2012 07:50:22 -0700 (PDT) Received: by qcac10 with SMTP id c10so998195qca.31 for ; Wed, 19 Sep 2012 07:50:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=4gJqiskA9X5+Z077AnobSimZezue0TQ6+V2VfGob7wQ=; b=ftrlWZRNiu3JrhHtrD3QJwwg703tDKwdH5OJSqF+Ua8BahzlM1Ctrp+nk8jJkZSJz9 PNop+Z5PVPXmTriQ39xU2YA365ICeLX9FbVKr1CByVF//jf2JtCLKzSoGVvqNhkSncQ8 l1P/sk8ahAbhpvhr/D5aIjl2+vARUj7tCPVgZ6jqrnDWvvvMPqIxSsVCWX6ramEqVM6m NDtPKbBxhazzMeVGVSvRU4SK7hcIPeJXLMao1QFNH9j/Q7sbMu0wzelzyl2Ch6iSayOy 8SMIbp8tiFBtdzSrLNnWWz2w1hCUUYL0A/xppiPAjlmiYo36Qf2otw5NsqMbD/f/o8tq D/1w== Received: by 10.224.174.148 with SMTP id t20mr7556574qaz.67.1348066221739; Wed, 19 Sep 2012 07:50:21 -0700 (PDT) Received: from [192.168.1.211] (190-20-24-188.baf.movistar.cl. [190.20.24.188]) by mx.google.com with ESMTPS id k6sm4219375qac.0.2012.09.19.07.50.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Sep 2012 07:50:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: <87r4pyh267.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 11:50:08 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <481B23BE-B744-459F-9873-024105A38348@ve7jtb.com> References: <87r4pyh267.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQnEKi2UNBct3GR/rzERFtfuboJQDM+nXcFCGguwz6Ap5RFimD373tyR+DfmEL9EeXKOMnHY Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 14:50:23 -0000 As near as I can make out the authzid should be usable for routing to = the backend server that can validate the access token. Is there a problem with it being in the GSS-API header? One catch is that the value of the authzid needs to be the email/xmpp = address you are trying to connect to. Not something the client tries to interpret from the user authentication = to the authorization server. I was thinking this over and people seem to want to believe that there = are one to one mappings between these identifiers. There may be multiple email addresses associated with a IMAP box. A account might have more than one Box (Not common but not impossible) The account may itself be authenticated by a a federated login that = accesses multiple services each with a IMAP mailbox. I personally have a google apps email that is saml authenticated from a = corporate SSO where there is no connection between my login name and my = email. =20 The client will do a OAuth authorization flow and get back a token that = authorizes it for one (or more mailboxes) as nothing requires the client = to send the target email to the authorization server that I can see. The access token and the authzid may both be required to connect to the = correct box.=20 Especially where you are doing SAS hosing and the tokens might be = encrypted to the RS I can see the value in having the external address = for routing to get it to the correct backend server. John B. On 2012-09-19, at 5:01 AM, Simon Josefsson wrote: > Luke Howard writes: >=20 >>>> No, the authzid cannot serve this purpose even if it were = mandatory. >>>> This is a misunderstanding. Ryan wants the identity of the OAuth >>>> credential owner as a routing hint to find a server that can verify = the >>>> OAuth credential for that user. The authzid has nothing to do with >>>> that. >>>=20 >>> I thought from the earlier description that the purpose of the hint = was to >>> identify the server hosting the mailbox of the "effective" identity >>> involved, which to me seemed an awful lot like authzid. >>=20 >> I am with Scott here in this understanding. >=20 > The reason I interpreted this differently was that Ryan confirmed that > he could have gotten the routing hint information from the OAuth > credential but he preferred to treat the OAuth credential as opaque = and > thus needed to get it from somewhere else. I don't see how you could > ever hope to get the SASL authzid out of an OAuth credential? The > authzid is asserted by the SASL client and is unrelated to the > credential... >=20 > ...unless the application is assumed to acquire a new OAuth credential > for every unique SASL authzid it wish to use...? >=20 > /Simon > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From wmills@yahoo-inc.com Wed Sep 19 09:06: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 74ABA21F875C for ; Wed, 19 Sep 2012 09:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[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 B0KGVZ3BYIM4 for ; Wed, 19 Sep 2012 09:06:06 -0700 (PDT) Received: from nm31.bullet.mail.ne1.yahoo.com (nm31.bullet.mail.ne1.yahoo.com [98.138.229.24]) by ietfa.amsl.com (Postfix) with SMTP id 50B4421F8752 for ; Wed, 19 Sep 2012 09:06:05 -0700 (PDT) Received: from [98.138.90.49] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2012 16:06:01 -0000 Received: from [98.138.89.194] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2012 16:06:01 -0000 Received: from [127.0.0.1] by omp1052.mail.ne1.yahoo.com with NNFMP; 19 Sep 2012 16:06:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 127425.3030.bm@omp1052.mail.ne1.yahoo.com Received: (qmail 70866 invoked by uid 60001); 19 Sep 2012 16:06:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348070760; bh=ZeFN9cP4hfyOiFdg8T9hsLIbgariZQTeI+A9r9k8LFQ=; 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=pwaIVnRPAfvHRBkJZwxnXPB5zI5njldfor204o5svlkp6BZZZcwMwCe+h8TQQIKgz5PA2ipmUaDnGhULNH2ZXeNXWa7ePMqpLSPiqy0eHcLHTAUh3bHVfiHna0PPUxii8D9WOYoORSBozpzZvsufkq4OcrTrYvrL8FQiQPhw1P0= 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=LauOE6MERxEtfwIlzLn9oEqts3o/lYZXNya26XMOuix71/TbvUkACFC9osuzU1j4Rh50R8yLPvyIRhseJ2i97A/aYdk6jQDVk/Pd1jRGlai8Pi5W6Q1hRltP0KMrujGddUkGgDneIuGUq83zt5+4AGw5QJBDYTkbpLbgBrHtBp0=; X-YMail-OSG: ErALHFUVM1kWckhlyo3lFPz.8u10aHisyJPlbelxE5PTFIt XBKX0Otwka3FFe0n1WEUou8anRTAe1aYPaGmyiOvJjPR3bq3DixTJCn3Mxet dOW4LAOkBtEPwI.kqSMwRogEJKEU9WAxpo.6rIxof6v1Zk5y4GaKMcb8Nf06 2GvAd_YNSuqTkF5xQJFsXTSzY2ViBV7AsWAtdEjAldD3CncTLefB2.x67Eqg XoFmdzPw8QEHJS.9kIhYmy7TKxM0pljcp79V3eAOAtadLdf_LNlymN_TikgP IFzesP9p7wRgB.a8pUrvQxOg6mTrIi6Xq_.CIIvJJ4u1PpsYjvWLUmVOtOXU D3WYscmwU8ibr0sB_cK9_fAGvsOToi58FsOvqXiN1qwGHHOC_g82tI6d2YOo QTCRJDWjJZJ23gn8af8xAbsTIi5h7Z2tijrmIdIDisxRo Received: from [107.32.74.86] by web31812.mail.mud.yahoo.com via HTTP; Wed, 19 Sep 2012 09:06:00 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <87pq5iij20.fsf@latte.josefsson.org> Message-ID: <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 09:06:00 -0700 (PDT) From: William Mills To: Simon Josefsson , "Cantor, Scott" In-Reply-To: <87pq5iij20.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-660678892-1348070760=:47728" Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 16:06:07 -0000 --1458549034-660678892-1348070760=:47728 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The hint is the user name being authenticated (as I've said multiple times = previously).=A0 The server is responsible for mapping the user name to the = server (cluster) handling that user.=0A=0A=0A=0A=0A=0A>____________________= ____________=0A> From: Simon Josefsson =0A>To: "Cantor= , Scott" =0A>Cc: "kitten@ietf.org" =0A= >Sent: Wednesday, September 19, 2012 12:11 AM=0A>Subject: Re: [kitten] Goog= le and SASL OAuth=0A> =0A>"Cantor, Scott" writes:=0A>=0A= >> On 9/18/12 6:09 PM, "Simon Josefsson" wrote:=0A>>>= >=0A>>>> Authz-id can serve this purpose but it's not mandatory.=A0 You can= make=0A>>>> it mandatory in your service documentation, that's as easy as = making=0A>>>> an optional field in the SASL data that you require.=0A>>>=0A= >>>No, the authzid cannot serve this purpose even if it were mandatory.=0A>= >>This is a misunderstanding.=A0 Ryan wants the identity of the OAuth=0A>>>= credential owner as a routing hint to find a server that can verify the=0A>= >>OAuth credential for that user.=A0 The authzid has nothing to do with=0A>= >>that.=0A>>=0A>> I thought from the earlier description that the purpose o= f the hint was to=0A>> identify the server hosting the mailbox of the "effe= ctive" identity=0A>> involved, which to me seemed an awful lot like authzid= .=0A>=0A>That's not what I understand from the latest explanation: as I=0A>= understand Ryan, the routing hint is there to identify the server that=0A>i= s able to validate the OAuth credential.=A0 That makes the routing hint=0A>= effectively the authentication identity, although the routing hint=0A>canno= t be relied on as the authentication identity until the credential=0A>has b= een validated to belonging to the claimed user.=0A>=0A>Ryan could you clari= fy for us again, please?=0A>=0A>/Simon=0A>_________________________________= ______________=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.iet= f.org/mailman/listinfo/kitten=0A>=0A>=0A> --1458549034-660678892-1348070760=:47728 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The hint = is the user name being authenticated (as I've said multiple times previousl= y).  The server is responsible for mapping the user name to the server= (cluster) handling that user.


From: Simon Josefsson <simon@= josefsson.org>
To: = "Cantor, Scott" <cantor.2@osu.edu>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Wednesday, September 19, = 2012 12:11 AM
Subject:= Re: [kitten] Google and SASL OAuth

"Cantor, Scott" = <cantor.2@osu.edu> writes:

> On 9/18/12 6:09 PM, "Simon Jo= sefsson" <simon@josefsson.org> wrote:
>>>
>&= gt;> Authz-id can serve this purpose but it's not mandatory.  You c= an make
>>> it mandatory in your service documentation, that's = as easy as making
>>> an optional field in the SASL data that y= ou require.
>>
>>No, the authzid cannot serve this purpos= e even if it were mandatory.
>>This is a misunderstanding.  R= yan wants the identity of the OAuth
>>credential owner as a routing h= int to find a server that can verify the
>>OAuth credential for th= at user.  The authzid has nothing to do with
>>that.
><= br>> I thought from the earlier description that the purpose of the hint= was to
> identify the server hosting the mailbox of the "effective" = identity
> involved, which to me seemed an awful lot like authzid.
That's not what I understand from the latest explanation: as I
unde= rstand Ryan, the routing hint is there to identify the server that
is ab= le to validate the OAuth credential.  That makes the routing hint
e= ffectively the authentication identity, although the routing hint
cannot= be relied on as the authentication identity until the credential
has be= en validated to belonging to the claimed user.

Ryan could you clarif= y for us again, please?

/Simon
_______________________________________________Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/lis= tinfo/kitten


--1458549034-660678892-1348070760=:47728-- From wmills@yahoo-inc.com Wed Sep 19 09:14: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 5997B21F86FE for ; Wed, 19 Sep 2012 09:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[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 3ZLG4IkP-wvD for ; Wed, 19 Sep 2012 09:14:23 -0700 (PDT) Received: from nm14.bullet.mail.sp2.yahoo.com (nm14.bullet.mail.sp2.yahoo.com [98.139.91.84]) by ietfa.amsl.com (Postfix) with SMTP id 99B1C21F86E3 for ; Wed, 19 Sep 2012 09:14:23 -0700 (PDT) Received: from [72.30.22.92] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 19 Sep 2012 16:14:23 -0000 Received: from [98.139.91.16] by tm14.bullet.mail.sp2.yahoo.com with NNFMP; 19 Sep 2012 16:14:23 -0000 Received: from [127.0.0.1] by omp1016.mail.sp2.yahoo.com with NNFMP; 19 Sep 2012 16:14:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 305168.84623.bm@omp1016.mail.sp2.yahoo.com Received: (qmail 36133 invoked by uid 60001); 19 Sep 2012 16:14:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348071262; bh=0wg4QMH+Do2q8ZYoWe2nJQcOEEKyq5WvSNlnTl4PFfc=; 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=WDahNdHR3cGVn6EdIkO/Dys+x/Qak0JPnk885kvbHFGuEQF9SO+XNuc0+dyhsuzEK/SOIN+t8l6I7jB+n/43aGOs4HyrmDCXyMijH5ec22vM3+y4bT4ILaQXABRvsppI86Jim1WUKCECHLC3gFodG7Zo+aXUkEkSaPDY3kqitss= 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=GQVoGNlAGmjhekspWmqB3g3tKApMOiVkog8q9R5Ki6LwRr9MLP1YI0h8RIh8bu+i/QGh9tpwaQU8QYjUgx86eRUap6IGVS5WX9QfomskNHJZzcuxVODkS+hDA9gQnI+FzEgA/EqfjmGu//v1qhmLYzwaZMhCjbOPhE0qdiW9XNE=; X-YMail-OSG: DxhN9TIVM1n1IcD_XEOLS7TWiFRtLqCXS8CURpnrzKaqsZ0 bpmzIfrzzYQhtFGyG23MUV6hgXz3ucABQLX6EBPgtvVG8wcTN8GPaEjTZ5Dd skD2d.rzQm.zbQuaH8H3FyRKsuWh1KV2FVyvH3TwVbwL9bSDsHBqlp7pgumL eVtV16VwWxFSbFhFNt7Oqv4aSJyEKTDOyipkohQzLYmdHT0yTuv4ASxDsGfZ k2gF1Wl_t4Z6Hc3dP.abY8x5wqdAJMKERIV0_RjnGP_I8xxX2LAhtb0QE0db KYmFZMerAe0NZBcp7n6QPNBEWuFdNoVK98dK_fTFSW_azFJ07iWRcZFANfiR lElRMeTqv6exY9vnSqe.ptlN0fkNM_RwMwZobvzqIS2mXJoHd0IwYY0CXW3V IYkRtCX39sCUtzL3f5NkV5DpQ9ejVebcI2OapBA3wDLY3MA-- Received: from [107.32.74.86] by web31805.mail.mud.yahoo.com via HTTP; Wed, 19 Sep 2012 09:14:22 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> Message-ID: <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 09:14:22 -0700 (PDT) From: William Mills To: William Mills , Simon Josefsson , "Cantor, Scott" In-Reply-To: <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-2141385817-1348071262=:95560" Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 16:14:24 -0000 ---551393103-2141385817-1348071262=:95560 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I should be more general, the routing hint is the resource being accessed i= n the context of the connection.=A0 The client needs to know this.=A0 For t= he use cases I'm focused on that will be a user name.=0A=0A=0A=0A=0A>______= __________________________=0A> From: William Mills = =0A>To: Simon Josefsson ; "Cantor, Scott" =0A>Cc: "kitten@ietf.org" =0A>Sent: Wednesday, Sep= tember 19, 2012 9:06 AM=0A>Subject: Re: [kitten] Google and SASL OAuth=0A> = =0A>=0A>The hint is the user name being authenticated (as I've said multipl= e times previously).=A0 The server is responsible for mapping the user name= to the server (cluster) handling that user.=0A>=0A>=0A>=0A>=0A>=0A>=0A>>__= ______________________________=0A>> From: Simon Josefsson =0A>>To: "Cantor, Scott" =0A>>Cc: "kitten@ietf.org" = =0A>>Sent: Wednesday, September 19, 2012 12:11 AM=0A>>Sub= ject: Re: [kitten] Google and SASL OAuth=0A>> =0A>>"Cantor, Scott" writes:=0A>>=0A>>> On 9/18/12 6:09 PM, "Simon Josefsson" wrote:=0A>>>>>=0A>>>>> Authz-id can serve this purpose but i= t's not mandatory.=A0 You can make=0A>>>>> it mandatory in your service doc= umentation, that's as easy as making=0A>>>>> an optional field in the SASL = data that you require.=0A>>>>=0A>>>>No, the authzid cannot serve this purpo= se even if it were mandatory.=0A>>>>This is a misunderstanding.=A0 Ryan=0A = wants the identity of the OAuth=0A>>>>credential owner as a routing hint to= find a server that can verify the=0A>>>>OAuth credential for that user.=A0= The authzid has nothing to do with=0A>>>>that.=0A>>>=0A>>> I thought from = the earlier description that the purpose of the hint was to=0A>>> identify = the server hosting the mailbox of the "effective" identity=0A>>> involved, = which to me seemed an awful lot like authzid.=0A>>=0A>>That's not what I un= derstand from the latest explanation: as I=0A>>understand Ryan, the routing= hint is there to identify the server that=0A>>is able to validate the OAut= h credential.=A0 That makes the routing hint=0A>>effectively the authentica= tion identity, although the routing hint=0A>>cannot be relied on as the aut= hentication identity until the credential=0A>>has been validated to belongi= ng to the claimed user.=0A>>=0A>>Ryan could you clarify for us again,=0A pl= ease?=0A>>=0A>>/Simon=0A>>_______________________________________________= =0A>>Kitten mailing list=0A>>Kitten@ietf.org=0A>>https://www.ietf.org/mailm= an/listinfo/kitten=0A>>=0A>>=0A>>=0A>______________________________________= _________=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org= /mailman/listinfo/kitten=0A>=0A>=0A> ---551393103-2141385817-1348071262=:95560 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I should be more general, the routing hint is the resource being accessed= in the context of the connection.  The client needs to know this.&nbs= p; For the use cases I'm focused on that will be a user name.

From: William Mil= ls <wmills@yahoo-inc.com>
T= o: Simon Josefsson <simon@josefsson.org>; "Cantor, Scott" <cantor.2@osu.edu>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Wednesday, September 19, 2012 9:06 AM Subject: Re: [kitten] Go= ogle and SASL OAuth

<= div style=3D"color:#000;background-color:#fff;font-family:Courier New, cour= ier, monaco, monospace, sans-serif;font-size:14pt;">The hint is the user na= me being authenticated (as I've said multiple times previously).  The = server is responsible for mapping the user name to the server (cluster) han= dling that user.


Fro= m: Simon Josefsson <simon@josefsson.org>
To: "Cantor, Scott" <cantor.2@osu.edu= >
Cc: "kitten@iet= f.org" <kitten@ietf.org>
Se= nt: Wednesday, September 19, 2012 12:11 AM
Subject: Re: [kitten] Google and SASL OAuth<= br>

"Cantor, Scott" <= cantor.2@osu.edu> writes:

> On 9/18/12 6:09 PM, "Simon Jos= efsson" <simon@josefsson.org&g= t; wrote:
>>>
>>> Authz-id can serve this purpose b= ut it's not mandatory.  You can make
>>> it mandatory in y= our service documentation, that's as easy as making
>>> an opti= onal field in the SASL data that you require.
>>
>>No, th= e authzid cannot serve this purpose even if it were mandatory.
>>This is a misunderstanding.  Ryan=0A wa= nts the identity of the OAuth
>>credential owner as a routing hint= to find a server that can verify the
>>OAuth credential for that = user.  The authzid has nothing to do with
>>that.
>
= > I thought from the earlier description that the purpose of the hint wa= s to
> identify the server hosting the mailbox of the "effective" ide= ntity
> involved, which to me seemed an awful lot like authzid.
That's not what I understand from the latest explanation: as I
underst= and Ryan, the routing hint is there to identify the server that
is able = to validate the OAuth credential.  That makes the routing hint
effe= ctively the authentication identity, although the routing hint
cannot be= relied on as the authentication identity until the credential
has been = validated to belonging to the claimed user.

Ryan could you clarify f= or us again,=0A please?

/Simon
__________________________________= _____________
Kitten mailing list
Kitte= n@ietf.org
https://www.ietf.org/mailman/listinfo/ki= tten


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

---551393103-2141385817-1348071262=:95560-- From ve7jtb@ve7jtb.com Wed Sep 19 09:52:29 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 6C12D21F8514 for ; Wed, 19 Sep 2012 09:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Dr-LbGGbFLuL for ; Wed, 19 Sep 2012 09:52:28 -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 628B621F8504 for ; Wed, 19 Sep 2012 09:52:28 -0700 (PDT) Received: by qafi29 with SMTP id i29so3769609qaf.10 for ; Wed, 19 Sep 2012 09:52:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=akPecqHcPIZJxrUlWDYSyv3xFvdBCOdyll9Tki8Rz9Q=; b=L5o8QzEjoPrlbtwexKdM6t+Nd0ZST1GvoqoP1a30HCA/258w4/rUD9YNux9KeiijLw SehkKNLpkRnU/6/dvaR36Pw/sIa+I8LzjA9Zeik5YhK+SB6LpqqMI0oHQEdE2vc0whEZ teOJDk+BCT9Op6Wvv7E40StPiiJ4/B5XLCv9oRTbyi0s0GsZakF/0fay73h2dO4Bi4no /Uu/aoDZl/SbG9DYixTQXnJVKgtOBZCG2fCqCospkMyaOSTLFpbxC+3gfXtNF4XiQOVx l7e1yokwh8nHVPVSQFFhdSZA4YUbb1NKh97TkZf6jX0192tHeC7gDbwRGK6bNLcQ/rHp Ur+A== Received: by 10.224.53.18 with SMTP id k18mr8710490qag.1.1348073547746; Wed, 19 Sep 2012 09:52:27 -0700 (PDT) Received: from [192.168.1.211] (190-20-24-188.baf.movistar.cl. [190.20.24.188]) by mx.google.com with ESMTPS id fl3sm4577012qab.3.2012.09.19.09.52.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Sep 2012 09:52:26 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4834C44C-3402-4099-9C32-34D267943F6F" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 13:52:18 -0300 Message-Id: <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQmhNyVFlHoERrhrj1ucr0tzHUJXyVsZGfhtdsdkvwZDC4Iq87o9/jKkk6XQANSeoABk22yn Cc: Simon Josefsson , "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 16:52:29 -0000 --Apple-Mail=_4834C44C-3402-4099-9C32-34D267943F6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 It isn't necessarily a user name it is or should be an identifier for = the resource being accessed. =20 There may be more than one possible resource authorized by the access = token as the authorization request is not for a specific resource as far = as I can tell. Generally if you ask for an email token the = authorization server will find that unambiguous and grant you something = that gives you IMAP and SMTP access rights that may cover multiple IMAP = resources if they exist. There is no one to one mapping from the resource identifier to the user = name. There is a possible many to many situation. =20 I might use a hotmail account to login to a gmail account. =20 I recognize that traditionally the resource identifier and the user name = are the same, but the world is now much more complicated. I think you = need both the resource identifier and grant unless the specific resource = is passed to the authorization server in the request. John B. On 2012-09-19, at 1:14 PM, William Mills wrote: > I should be more general, the routing hint is the resource being = accessed in the context of the connection. The client needs to know = this. For the use cases I'm focused on that will be a user name. >=20 > From: William Mills > To: Simon Josefsson ; "Cantor, Scott" = =20 > Cc: "kitten@ietf.org" =20 > Sent: Wednesday, September 19, 2012 9:06 AM > Subject: Re: [kitten] Google and SASL OAuth >=20 > The hint is the user name being authenticated (as I've said multiple = times previously). The server is responsible for mapping the user name = to the server (cluster) handling that user. >=20 >=20 > From: Simon Josefsson > To: "Cantor, Scott" =20 > Cc: "kitten@ietf.org" =20 > Sent: Wednesday, September 19, 2012 12:11 AM > Subject: Re: [kitten] Google and SASL OAuth >=20 > "Cantor, Scott" writes: >=20 > > On 9/18/12 6:09 PM, "Simon Josefsson" wrote: > >>> > >>> Authz-id can serve this purpose but it's not mandatory. You can = make > >>> it mandatory in your service documentation, that's as easy as = making > >>> an optional field in the SASL data that you require. > >> > >>No, the authzid cannot serve this purpose even if it were mandatory. > >>This is a misunderstanding. Ryan wants the identity of the OAuth > >>credential owner as a routing hint to find a server that can verify = the > >>OAuth credential for that user. The authzid has nothing to do with > >>that. > > > > I thought from the earlier description that the purpose of the hint = was to > > identify the server hosting the mailbox of the "effective" identity > > involved, which to me seemed an awful lot like authzid. >=20 > That's not what I understand from the latest explanation: as I > understand Ryan, the routing hint is there to identify the server that > is able to validate the OAuth credential. That makes the routing hint > effectively the authentication identity, although the routing hint > cannot be relied on as the authentication identity until the = credential > has been validated to belonging to the claimed user. >=20 > Ryan could you clarify for us again, please? >=20 > /Simon > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=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 --Apple-Mail=_4834C44C-3402-4099-9C32-34D267943F6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 It = isn't necessarily a user name it is or should be an identifier for the = resource being accessed.   

There may be = more than one possible resource authorized by the access token as the = authorization request is not for a specific resource as far as I can = tell.   Generally if you ask for an email token the authorization = server  will find that unambiguous and grant you something that = gives you IMAP and SMTP access rights that may cover multiple IMAP = resources if they exist.

There is no one to one = mapping from the resource identifier to the user name.   There is a = possible many to many situation.  

I might = use a hotmail account to login to a gmail account. =   

I recognize that traditionally the = resource identifier and the user name are the same, but the world is now = much more complicated.   I think you need both the resource = identifier and grant unless the specific resource is passed to the = authorization server in the request.

John = B.



On = 2012-09-19, at 1:14 PM, William Mills <wmills@yahoo-inc.com> = wrote:

I should be more general, the routing hint = is the resource being accessed in the context of the connection.  = The client needs to know this.  For the use cases I'm focused on = that will be a user name.

=
=
From: = William Mills <wmills@yahoo-inc.com>
= To: Simon Josefsson = <simon@josefsson.org>; = "Cantor, Scott" <cantor.2@osu.edu> =
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Wednesday, September 19, = 2012 9:06 AM
Subject: Re: [kitten] Google and SASL OAuth
=

The = hint is the user name being authenticated (as I've said multiple times = previously).  The server is responsible for mapping the user name = to the server (cluster) handling that = user.


From: Simon Josefsson <simon@josefsson.org>
= To: "Cantor, Scott" = <cantor.2@osu.edu> =
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Wednesday, September 19, = 2012 12:11 AM
Subject:= Re: [kitten] Google and SASL OAuth

"Cantor, = Scott" <cantor.2@osu.edu> = writes:

> On 9/18/12 6:09 PM, "Simon Josefsson" <simon@josefsson.org> = wrote:
>>>
>>> Authz-id can serve this purpose = but it's not mandatory.  You can make
>>> it mandatory = in your service documentation, that's as easy as making
>>> = an optional field in the SASL data that you = require.
>>
>>No, the authzid cannot serve this = purpose even if it were mandatory.
>>This is a misunderstanding.  Ryan wants the identity of the OAuth
>>credential owner as a = routing hint to find a server that can verify the
>>OAuth = credential for that user.  The authzid has nothing to do = with
>>that.
>
> I thought from the earlier = description that the purpose of the hint was to
> identify the = server hosting the mailbox of the "effective" identity
> involved, = which to me seemed an awful lot like authzid.

That's not what I = understand from the latest explanation: as I
understand Ryan, the = routing hint is there to identify the server that
is able to validate = the OAuth credential.  That makes the routing hint
effectively = the authentication identity, although the routing hint
cannot be = relied on as the authentication identity until the credential
has = been validated to belonging to the claimed user.

Ryan could you = clarify for us again, = please?

/Simon
_______________________________________________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=_4834C44C-3402-4099-9C32-34D267943F6F-- From rtroll@google.com Wed Sep 19 09:52: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 6826921F85C6 for ; Wed, 19 Sep 2012 09:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.809 X-Spam-Level: X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=0.167, 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 3of3CJyukuzc for ; Wed, 19 Sep 2012 09:52:51 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B76FC21F8551 for ; Wed, 19 Sep 2012 09:52:51 -0700 (PDT) Received: by iabz21 with SMTP id z21so1057304iab.31 for ; Wed, 19 Sep 2012 09:52:51 -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=I+mVbDpRWZFwbD0eEwEXyHMo+79BhnM2GCNxmMFsbRY=; b=PPLgWiKOtpKoZdDWcPuSF/GlilFTu7B3InKuZbScvQINMWjW3iaoIkZv6jPA5MvTkv oEm7Dm1GkMWg33X/DB/nHjb5LQc9ou8+44vGxgqBsMOoeBJcraDkKWiyMaEDAt1oc32O R5CxkTajHPJdnyeXtHNVv7hM9pBtAFqoixr6s= 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=I+mVbDpRWZFwbD0eEwEXyHMo+79BhnM2GCNxmMFsbRY=; b=F4kwzWAqEfXIpbMVmq1adKUyl2+JlfNcWDv2P5R4DB9MqdLtQCgTuZPLoHbUEPi+g3 zjcetYlnpmSRmbU6TP4ELD4HAIbE5NTVvTxNv9AGACyPdVWNtxwov3p7+brgiSpQxgG+ ivkjAqiGrtBdOLHfGtRPGj0Jgt/PDur97hrX6Vl67VsHquEUFAheqRendi80vR0uU+NQ fnjK0qjGwWRTHzqLv1G9mjckqBxt7zB5sQHBnxS5SWVMdAcfouC4fW+J05zpypJ01Agv cRyskjRsJg+dSJOrPLQcy2vTqVUkiPzKvq60jzWod261Z77FtJkSosIF+/TMPsY+7A88 MDHA== Received: by 10.50.180.225 with SMTP id dr1mr3487298igc.6.1348073571289; Wed, 19 Sep 2012 09:52:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.180.225 with SMTP id dr1mr3487290igc.6.1348073571175; Wed, 19 Sep 2012 09:52:51 -0700 (PDT) Received: by 10.50.36.131 with HTTP; Wed, 19 Sep 2012 09:52:51 -0700 (PDT) In-Reply-To: <87pq5iij20.fsf@latte.josefsson.org> References: <87pq5iij20.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 09:52:51 -0700 Message-ID: From: Ryan Troll To: Simon Josefsson Content-Type: multipart/alternative; boundary=14dae9340cdd574baa04ca10d6e3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmeQWfBCGddzUnFGf6kqkhyluu+aaKfXYKNGRwc8GOhKncGJhLWwCuwqhOUmv8B/j0/yO8aAlMce55HQm99jNacoznZW4qmJGvUd41j8XybuwSFgp5FdfnjuHaOm5dz55ZwYmwh5bd2M3Q1avqDJD7l1hKF20K0dSdUcZxIEjitrUymn3o6gwS5lWd8k8lUORn4Lgu/ Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 16:52:52 -0000 --14dae9340cdd574baa04ca10d6e3 Content-Type: text/plain; charset=ISO-8859-1 > >>No, the authzid cannot serve this purpose even if it were mandatory. > >>This is a misunderstanding. Ryan wants the identity of the OAuth > >>credential owner as a routing hint to find a server that can verify the > >>OAuth credential for that user. The authzid has nothing to do with > >>that. > > > > I thought from the earlier description that the purpose of the hint was > to > > identify the server hosting the mailbox of the "effective" identity > > involved, which to me seemed an awful lot like authzid. > > That's not what I understand from the latest explanation: as I > understand Ryan, the routing hint is there to identify the server that > is able to validate the OAuth credential. That makes the routing hint > effectively the authentication identity, although the routing hint > cannot be relied on as the authentication identity until the credential > has been validated to belonging to the claimed user. > > Ryan could you clarify for us again, please? > Generically, we want the hint to identify who the request is coming from. This allows a service to route the request to a backend capable of servicing the request. Other backends will not be able to successfully access the requested data. -R --14dae9340cdd574baa04ca10d6e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>No, the authzid cannot serve this purpose even if it were mandatory= .
>>This is a misunderstanding. =A0Ryan wants the identity of the OAuth=
>>credential owner as a routing hint to find a server that can verify= the
>>OAuth credential for that user. =A0The authzid has nothing to do wi= th
>>that.
>
> I thought from the earlier description that the purpose of the hint wa= s to
> identify the server hosting the mailbox of the "effective" i= dentity
> involved, which to me seemed an awful lot like authzid.

That's not what I understand from the latest explanation: as I understand Ryan, the routing hint is there to identify the server that
is able to validate the OAuth credential. =A0That makes the routing hint effectively the authentication identity, although the routing hint
cannot be relied on as the authentication identity until the credential
has been validated to belonging to the claimed user.

Ryan could you clarify for us again, please?


Generically, we want the hint to identify who the requ= est is coming from. =A0This allows a service to route the request to a back= end capable of servicing the request. =A0Other backends will not be able to= successfully access the requested data.

-R


--14dae9340cdd574baa04ca10d6e3-- From rtroll@google.com Wed Sep 19 09:54: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 617E621F8551 for ; Wed, 19 Sep 2012 09:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.837 X-Spam-Level: X-Spam-Status: No, score=-102.837 tagged_above=-999 required=5 tests=[AWL=0.139, 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 26mK9MF9T6-q for ; Wed, 19 Sep 2012 09:54:41 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE65B21F8504 for ; Wed, 19 Sep 2012 09:54:40 -0700 (PDT) Received: by iec9 with SMTP id 9so2125870iec.31 for ; Wed, 19 Sep 2012 09:54:40 -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=C+/+chfHnPAcIhbKlmFo+BEFc+JNXGK8OYKpguc3JEc=; b=G+wpYLrgH3dVliTypWLeTKVhx2e/mX8Aos/gjCvHeJJ1ELwZ9k1XECTGrnVyUGjU1p y5/4dB0OzaMaJu8aknAUy4QyHB+nRjV+qEyJkr2DoLzQHheEatPL23AKlQsFiCeDV4ig g8nh9C9V2dRtcfQId8IV9fEXioq4nIJIaP1hU= 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=C+/+chfHnPAcIhbKlmFo+BEFc+JNXGK8OYKpguc3JEc=; b=IXVL+XjKUFyMr+XMReTBzt4jT7PrOXuBqQfDDT/sosZ1MJCksaKVsJgcF9Mr4QGfcH PooJdE2IKI4KhYi+0cZquOuZcn6jpSk/zdbZvhuGvMnuePi0KVArYcvijuBq5X6pz0uL ergiq3pDSQ6mq4OM4jhJzC0IP0iDbIHlDmxLZukwhL/TcSvx8DJYCuSP/sVzbxWRd262 hXRsB7ZQomJFTvEDFkKZUsTIyNscScXPvnrklm36/h9bSVdugQ5gBt0vu2nLkcdWd+Mm h5o2jFEe7rzY+8D7onWheju1juvCjnQkTM3piYjPRkOxi8M3XXToUswZ+00Dp+8jzlq+ PT+g== MIME-Version: 1.0 Received: by 10.50.202.8 with SMTP id ke8mr3474124igc.6.1348073680458; Wed, 19 Sep 2012 09:54:40 -0700 (PDT) Received: by 10.50.36.131 with HTTP; Wed, 19 Sep 2012 09:54:40 -0700 (PDT) In-Reply-To: <87vcfah2jq.fsf@latte.josefsson.org> References: <1347984999.13150.YahooMailNeo@web31813.mail.mud.yahoo.com> <5058B024.4060601@gmx.net> <87r4pzf6c9.fsf@latte.josefsson.org> <87obl3jaw8.fsf@latte.josefsson.org> <87fw6fj98s.fsf@latte.josefsson.org> <87vcfah2jq.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 09:54:40 -0700 Message-ID: From: Ryan Troll To: Simon Josefsson Content-Type: multipart/alternative; boundary=f46d04479ee5dad56704ca10dca8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmTO4sj/Qzv02eLx6SrFehWKqBIOiFbiq+iTxoE4slYbxp3Lfcqfmf+Q8HswhuFWQdPaNCgWg1zw5ETXwP82PW9SxUNzaK19fuvzsRa6Y8CuSKfltl8NtpSdO0BEhbkcUEQja+zyBaGzpPBKHHBIuQZdamTbyqTKCiOH+64ylnmPsdD8llbRzLb+jjSA+Br3TqEE3I0 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 16:54:41 -0000 --f46d04479ee5dad56704ca10dca8 Content-Type: text/plain; charset=ISO-8859-1 > To me this sounds as if you'd rather fork the spec than live without a > routing hint -- having a document describing something additional > outside the RFCs is essentially the same as forking it. > I hadn't considered this "forking the spec", but you have a valid point - in which case: Yes, we'd fork the spec rather than live without this. -R --f46d04479ee5dad56704ca10dca8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
To me this sounds as if you'd rather fork the spec than live witho= ut a
routing hint -- having a document describing something additional
outside the RFCs is essentially the same as forking it.

I hadn't considered this "forking the spec",= but you have a valid point - in which case: Yes, we'd fork the spec ra= ther than live without this.

-R

--f46d04479ee5dad56704ca10dca8-- From rtroll@google.com Wed Sep 19 10:47: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 D17F321F86FA for ; Wed, 19 Sep 2012 10:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.857 X-Spam-Level: X-Spam-Status: No, score=-102.857 tagged_above=-999 required=5 tests=[AWL=0.119, 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 vvnumidRFJtB for ; Wed, 19 Sep 2012 10:46:59 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E05021F86F7 for ; Wed, 19 Sep 2012 10:46:59 -0700 (PDT) Received: by iec9 with SMTP id 9so2221858iec.31 for ; Wed, 19 Sep 2012 10:46:59 -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=eVHX1X4a42ha6hHexHORA1yYY5QWdav5nS7G/DBlxWw=; b=DGmrjEieKK+6r/4280s74nwFeiV8Yi9mFUo+4pTDhTAuNS3P/nj/Jq8f4E28uh08kq QNjTEk4s17RZN3oLZxz6gpcdE/49YwQuQJJRD4gl5/V/g+unHaS8+C2gI5LDZr5lMs7j XH6IuLYYmiyL8R/fIg/4bkfxUDoIu1e5VtToU= 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=eVHX1X4a42ha6hHexHORA1yYY5QWdav5nS7G/DBlxWw=; b=IGiE4Gc2KhsvRwSx1283o2qgnQL4Qm6tHJb11HKgsGMAiLmRldUiahJstxapA4vUey 16iTYq+K2xK7R67U51Bqk0VL/FIdArK3+TrsQ3sPeIix4DgNwffXJepmBTr1Rs2gCWS/ RWrXmuzUiQKBOjYvB8SihWNwd+EBwGT6JWoC/0wZqBksdSMccAOGqFb4v8K4JJ+HXlRg Hq2BRfFh5m8KDrOCbPrfcX5nMdF++ZnSXgo7ye3KOdmnwF5aRxQMuao3eG31DC3fRMOC 3nKgVz2ZY/WLoRfmP0hcopnjW1izLY+rE20sg6tzsxIDWEgEVKLCBp702iTU1JUG+N0B 0tnQ== Received: by 10.50.41.129 with SMTP id f1mr3660940igl.57.1348076819135; Wed, 19 Sep 2012 10:46:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.41.129 with SMTP id f1mr3660922igl.57.1348076818787; Wed, 19 Sep 2012 10:46:58 -0700 (PDT) Received: by 10.50.36.131 with HTTP; Wed, 19 Sep 2012 10:46:58 -0700 (PDT) In-Reply-To: <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> Date: Wed, 19 Sep 2012 10:46:58 -0700 Message-ID: From: Ryan Troll To: John Bradley Content-Type: multipart/alternative; boundary=14dae9340683e9edef04ca11977e X-System-Of-Record: true X-Gm-Message-State: ALoCoQlVuyGBoCRLqKIBFTPOiXrJ4hGxch1Y2+FmPrEvhm9QqoKyZl99m+Vfsfh9PGFm9fr+rq10m4qrCZblsEUaoQEt7jSMb8oc0XfJodeONKe+YeusFv43g+AV89Yh064pVuJNnOM1enGInGczoXacN1HOspWdBiJTX1ntussk9ZuM+WlVDWUDPglbV7WBGorECUV0L/jn Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 17:47:01 -0000 --14dae9340683e9edef04ca11977e Content-Type: text/plain; charset=ISO-8859-1 Good point re: OpenID. I had to walk through this a few times to get everything worked out right. Here's the example I came up with: Let's say I'm setting up "example@nifty-cool-email.org". Going through the web setup for "nifty-cool-email.org", I log in with my " user@identity-provider.com" address. The end result of this setup is the creation of "example@nifty-cool-email.org", which I can read through their web interface. Logging into the web interface involves me using the "log in with your identity-provider.com account" functionality (button, etc.) When setting up a desktop IMAP client to talk to nifty-cool-email.org, I provide the client with the name of the email account I'm setting up ( example@nifty-cool-email.org). The client will (eventually) be able to take this, find the OAuth URLs associated with the service, and bring up a browser allowing me to walk through the OAuth flow for nifty-cool-email.org. The first step of this flow is to log in, and logging in via identity-provider.com is supported. The end result of this OAuth flow is an OAuth credential, asserting my nifty-cool-email.org identity and the fact I'm allowed to access the IMAP service. This OAuth credential, along with the name of the resource being accessed ("example@nifty-coool-email.org") are sent via IMAP, and the IMAP service use these to authenticate and authorize access. It's up to the service provider to confirm that the [Identity asserted by the OAuth credential] has [granted the client access to this service] and [has granted the client access to this data]. In this scenario, the Client has no idea what my identity-provider.comidentity is, and has no need to. It does know what resource I'm attempting to access. As a result, I believe you're right - and my previous statement was incorrect - the hint should identify what the request is trying to access. (This has been doubly confusing, as in my immediate use case, these two values are the same.) I hope the scenario example helps. -R On Wed, Sep 19, 2012 at 9:52 AM, John Bradley wrote: > It isn't necessarily a user name it is or should be an identifier for the > resource being accessed. > > There may be more than one possible resource authorized by the access > token as the authorization request is not for a specific resource as far as > I can tell. Generally if you ask for an email token the authorization > server will find that unambiguous and grant you something that gives you > IMAP and SMTP access rights that may cover multiple IMAP resources if they > exist. > > There is no one to one mapping from the resource identifier to the user > name. There is a possible many to many situation. > > I might use a hotmail account to login to a gmail account. > > I recognize that traditionally the resource identifier and the user name > are the same, but the world is now much more complicated. I think you > need both the resource identifier and grant unless the specific resource is > passed to the authorization server in the request. > > John B. > > > > On 2012-09-19, at 1:14 PM, William Mills wrote: > > I should be more general, the routing hint is the resource being accessed > in the context of the connection. The client needs to know this. For the > use cases I'm focused on that will be a user name. > > ------------------------------ > *From:* William Mills > *To:* Simon Josefsson ; "Cantor, Scott" < > cantor.2@osu.edu> > *Cc:* "kitten@ietf.org" > *Sent:* Wednesday, September 19, 2012 9:06 AM > *Subject:* Re: [kitten] Google and SASL OAuth > > The hint is the user name being authenticated (as I've said multiple times > previously). The server is responsible for mapping the user name to the > server (cluster) handling that user. > > > ------------------------------ > *From:* Simon Josefsson > *To:* "Cantor, Scott" > *Cc:* "kitten@ietf.org" > *Sent:* Wednesday, September 19, 2012 12:11 AM > *Subject:* Re: [kitten] Google and SASL OAuth > > "Cantor, Scott" writes: > > > On 9/18/12 6:09 PM, "Simon Josefsson" wrote: > >>> > >>> Authz-id can serve this purpose but it's not mandatory. You can make > >>> it mandatory in your service documentation, that's as easy as making > >>> an optional field in the SASL data that you require. > >> > >>No, the authzid cannot serve this purpose even if it were mandatory. > >>This is a misunderstanding. Ryan wants the identity of the OAuth > >>credential owner as a routing hint to find a server that can verify the > >>OAuth credential for that user. The authzid has nothing to do with > >>that. > > > > I thought from the earlier description that the purpose of the hint was > to > > identify the server hosting the mailbox of the "effective" identity > > involved, which to me seemed an awful lot like authzid. > > That's not what I understand from the latest explanation: as I > understand Ryan, the routing hint is there to identify the server that > is able to validate the OAuth credential. That makes the routing hint > effectively the authentication identity, although the routing hint > cannot be relied on as the authentication identity until the credential > has been validated to belonging to the claimed user. > > Ryan could you clarify for us again, please? > > /Simon > _______________________________________________ > 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 > > --14dae9340683e9edef04ca11977e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good point re: OpenID. =A0I had to walk through this a few times to get eve= rything worked out right. =A0Here's the example I came up with:

Let's say I'm setting up "example@nifty-cool-email.org". = =A0Going through the web setup for "nifty-cool-email.org", I log in with my "user@identity-provider.com" addres= s. =A0The end result of this setup is the creation of "example@nifty-cool-email.org", wh= ich I can read through their web interface. =A0Logging into the web interfa= ce involves me using the "log in with your identity-provider.com account" functionality (button= , etc.)

When setting up a desktop IMAP client to talk to nifty-cool-email.org, I provide the c= lient with the name of the email account I'm setting up (example@nifty-cool-email.org). =A0The= client will (eventually) be able to take this, find the OAuth URLs associa= ted with the service, and bring up a browser allowing me to walk through th= e OAuth flow for nifty-cool-email.o= rg. =A0The first step of this flow is to log in, and logging in via identity-provider.com is supporte= d.

The end result of this OAuth flow is an OAuth credentia= l, asserting my nifty-cool-email.or= g identity and the fact I'm allowed to access the IMAP service. =A0= This OAuth credential, along with the name of the resource being accessed (= "example@nifty-coool-= email.org") are sent via IMAP, and the IMAP service use these to a= uthenticate and authorize access. =A0It's up to the service provider to= confirm that the [Identity asserted by the OAuth credential] has [granted = the client access to this service] and [has granted the client access to th= is data].

In this scenario, the Client has no idea what my identity-provider.com identity is, a= nd has no need to. =A0It does know what resource I'm attempting to acce= ss.


As a result, I believe you're right = - and my previous statement was incorrect - the hint should identify what t= he request is trying to access. =A0(This has been doubly confusing, as in m= y immediate use case, these two values are the same.)


I hope the scenario example helps.
=
-R



On Wed,= Sep 19, 2012 at 9:52 AM, John Bradley <ve7jtb@ve7jtb.com> w= rote:
It isn&#= 39;t necessarily a user name it is or should be an identifier for the resou= rce being accessed. =A0=A0

There may be more than one possible resource authorized by t= he access token as the authorization request is not for a specific resource= as far as I can tell. =A0 Generally if you ask for an email token the auth= orization server =A0will find that unambiguous and grant you something that= gives you IMAP and SMTP access rights that may cover multiple IMAP resourc= es if they exist.

There is no one to one mapping from the resource identi= fier to the user name. =A0 There is a possible many to many situation. =A0<= /div>

I might use a hotmail account to login to a gmail = account. =A0=A0

I recognize that traditionally the resource identifier = and the user name are the same, but the world is now much more complicated.= =A0 I think you need both the resource identifier and grant unless the spe= cific resource is passed to the authorization server in the request.

John B.



On 2012-09-19, at 1:14 PM, William Mills= <wmills@yahoo= -inc.com> wrote:

I sh= ould be more general, the routing hint is the resource being accessed in th= e context of the connection.=A0 The client needs to know this.=A0 For the u= se cases I'm focused on that will be a user name.

From: William Mills <wmills@yahoo-inc.com>
To: Simon Josefsson <simon@josefsson.org&g= t;; "Cantor, Scott" <cantor.2@osu.edu= >
Cc: "kitten@ietf.org" &= lt;kitten@ietf.org= >
Sent: Wednesday, September = 19, 2012 9:06 AM
Subject: Re: [kitten] Google and SASL OAuth

The hint is the user name being authenticated (as I've said multiple ti= mes previously).=A0 The server is responsible for mapping the user name to = the server (cluster) handling that user.


From: Simon Josefsson <simon@josefsson.org>
To: "Cantor, Scott" <= ;cantor.2@osu.edu= >
Cc: "kitten@ietf.org" <kitten@ietf.org>
= Sent: Wednesday, September 19, = 2012 12:11 AM
Subject: Re: [kitten] Googl= e and SASL OAuth

"Cantor, Scott" <cantor.2@= osu.edu> writes:

> On 9/18/12 6:09 PM, "Simon Josefsson" <simon@josefsson= .org> wrote:
>>>
>>> Authz-id can serve this= purpose but it's not mandatory.=A0 You can make
>>> it mandatory in your service documentation, that's as easy= as making
>>> an optional field in the SASL data that you requ= ire.
>>
>>No, the authzid cannot serve this purpose even = if it were mandatory.
>>This is a misunderstanding.=A0 Ryan wants the identity of the OAuth
>>credential owner as a routing h= int to find a server that can verify the
>>OAuth credential for th= at user.=A0 The authzid has nothing to do with
>>that.
>
> I thought from the earlier description that the purpose of the hint wa= s to
> identify the server hosting the mailbox of the "effective= " identity
> involved, which to me seemed an awful lot like auth= zid.

That's not what I understand from the latest explanation: as I
u= nderstand Ryan, the routing hint is there to identify the server that
is= able to validate the OAuth credential.=A0 That makes the routing hint
effectively the authentication identity, although the routing hint
canno= t be relied on as the authentication identity until the credential
has b= een validated to belonging to the claimed user.

Ryan could you clari= fy for us again, please?

/Simon
_______________________________________________Kitten mailing list
Kitten@ietf.org
https://www.iet= f.org/mailman/listinfo/kitten



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


__________________= _____________________________
Kitten mailing 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


--14dae9340683e9edef04ca11977e-- From nico@cryptonector.com Wed Sep 19 11:02: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 9847111E8091 for ; Wed, 19 Sep 2012 11:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=-0.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 vDPqR9r69rWn for ; Wed, 19 Sep 2012 11:02:25 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8EF11E808A for ; Wed, 19 Sep 2012 11:02:25 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id C519D36006F for ; Wed, 19 Sep 2012 11:02:24 -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=AhCyC2jOl1v9OLM9YwzG xwJXX+s=; b=BODpZxU0pPQDAQSKZN//A0gIu8M1LsZjJtA1wNgiDJj3F9MCu2on OF5laPBbersqB3cNZWN5ogLqD6nFpcMMfZh+56GTo1i4vr1LWBPk+tWM0aljeOTp bQbpqrze9A+SXSDPesMrHBYOpNV9mj4QtXcJZJ4J8Ymea6vSxC/om7g= 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 ABC8936006B for ; Wed, 19 Sep 2012 11:02:24 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so733312pbb.31 for ; Wed, 19 Sep 2012 11:02:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.236.69 with SMTP id us5mr253580pbc.59.1348077744358; Wed, 19 Sep 2012 11:02:24 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 11:02:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 13:02:24 -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] Google and 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: Wed, 19 Sep 2012 18:02:25 -0000 On Tue, Sep 18, 2012 at 8:28 PM, Luke Howard wrote: >>> No, the authzid cannot serve this purpose even if it were mandatory. >>> This is a misunderstanding. Ryan wants the identity of the OAuth >>> credential owner as a routing hint to find a server that can verify the >>> OAuth credential for that user. The authzid has nothing to do with >>> that. >> >> I thought from the earlier description that the purpose of the hint was to >> identify the server hosting the mailbox of the "effective" identity >> involved, which to me seemed an awful lot like authzid. > > I am with Scott here in this understanding. Me too. I'm very confused by the turn this thread is taking. Can we step back and state requirements clearly? I thought the requirements were: a) communicate the ID of the credential owner; b) communicate what Ryan calls a "routing hint" but which we Scott, Luke, Simon, and I believe is rightly the SASL authz-id; c) communicate some other ID? like the ID of the proxy using the credential? Nico -- From nico@cryptonector.com Wed Sep 19 11:08: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 EACDD11E8091 for ; Wed, 19 Sep 2012 11:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=-0.124, 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 nNSr-1KpDlsW for ; Wed, 19 Sep 2012 11:08:30 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 85BF611E808A for ; Wed, 19 Sep 2012 11:08:30 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 0822626C073 for ; Wed, 19 Sep 2012 11:08:30 -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=xZrVQDB1KR4Szqe2bJ9G QhxatIs=; b=Hq1fFRSrgZxSpC+ojIiGX29OYfIfuwHI67z4xtjHAJ+F/RbxqQ3f C6Mof8KOjGjsBNCFSjOEz9ErXJXMJMN27V6povVMLBeJO1Uas3QWpxYZU0RNxaIH 0cgkMgjEf6BeTNyYF4AcCouVGuNEgOTuc57ul01T8Z1PFbQ8VcuA1cg= 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-a87.g.dreamhost.com (Postfix) with ESMTPSA id DDE5126C06F for ; Wed, 19 Sep 2012 11:08:29 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so745416pbb.31 for ; Wed, 19 Sep 2012 11:08:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.194 with SMTP id d2mr8735479pax.42.1348078109470; Wed, 19 Sep 2012 11:08:29 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 11:08:29 -0700 (PDT) In-Reply-To: <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 13:08:29 -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] Google and 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: Wed, 19 Sep 2012 18:08:31 -0000 On Wed, Sep 19, 2012 at 11:14 AM, William Mills wrote: > I should be more general, the routing hint is the resource being accessed in > the context of the connection. The client needs to know this. For the use > cases I'm focused on that will be a user name. If the routing hint is the name of the resource then the routing hint cannot be the username. Just because a mailbox might have the same (fully-qualified) name as the username does not make them the same. This: > >The hint is the user name being authenticated (as I've said multiple >> times previously). The server is responsible for mapping the user >> name to the server (cluster) handling that user. must therefore be wrong. Nico -- From ve7jtb@ve7jtb.com Wed Sep 19 11:08: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 950A821F868A for ; Wed, 19 Sep 2012 11:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ygpoaAKytiCo for ; Wed, 19 Sep 2012 11:08:50 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4902021F8694 for ; Wed, 19 Sep 2012 11:08:50 -0700 (PDT) Received: by yenl13 with SMTP id l13so371154yen.31 for ; Wed, 19 Sep 2012 11:08:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=t9w7p3IK8YLOB9IoTST/SicJ7u2I7wmc22bOVZWdIao=; b=cb5ScRIY7Pg5TQ/RJSl72WH6CnubZez3QeUqfigAg8LIjZP1GNn4sY/RLD52nDDDYp 0oUT5m1HUGIjm8ioaNkNFUN0B5WUvRLw7/ns2gUloFU/ogRzO9YfqkJcKF1CaFZxLL00 TlgQ9JW+xRpwTgl8Yy/Vq0/GpbovF/vGhA8MTwbou64Cf18y9xlDb1BTb3GcTCQWr6zU /4HIuOtogt8BnSB37RRTVykv/y8lcJkqatQ59FBmlLCsSI9hbBQtjTPPQFynvho2SLSY V8pP9TyzOx9VLtn6FPfO1tKQlUCd6uSF5ucNIZEKegk4hqT+SQnqYqneetMptAD5JZsT CLFg== Received: by 10.236.73.72 with SMTP id u48mr4434343yhd.71.1348078129755; Wed, 19 Sep 2012 11:08:49 -0700 (PDT) Received: from [192.168.1.211] (190-20-24-188.baf.movistar.cl. [190.20.24.188]) by mx.google.com with ESMTPS id w20sm3442578anj.18.2012.09.19.11.08.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Sep 2012 11:08:49 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1845809F-7BCE-4B3B-92DE-690A4F8A58F2" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: Date: Wed, 19 Sep 2012 15:08:19 -0300 Message-Id: References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> To: Ryan Troll X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQkuU9Rak8a02xTmmNzVZZNiSpIfOO7dw9twzc8V5Z1xFxsBW75BM/B1PL2fqunE4iQo7fx3 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 18:08:51 -0000 --Apple-Mail=_1845809F-7BCE-4B3B-92DE-690A4F8A58F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Right that is the sort of thing I was thinking of. That will be more = common especially with outsourcing enterprise email where there is still = a enterprise AD doing the actual User authentication. John B. On 2012-09-19, at 2:46 PM, Ryan Troll wrote: > Good point re: OpenID. I had to walk through this a few times to get = everything worked out right. Here's the example I came up with: >=20 >=20 > Let's say I'm setting up "example@nifty-cool-email.org". Going = through the web setup for "nifty-cool-email.org", I log in with my = "user@identity-provider.com" address. The end result of this setup is = the creation of "example@nifty-cool-email.org", which I can read through = their web interface. Logging into the web interface involves me using = the "log in with your identity-provider.com account" functionality = (button, etc.) >=20 > When setting up a desktop IMAP client to talk to nifty-cool-email.org, = I provide the client with the name of the email account I'm setting up = (example@nifty-cool-email.org). The client will (eventually) be able to = take this, find the OAuth URLs associated with the service, and bring up = a browser allowing me to walk through the OAuth flow for = nifty-cool-email.org. The first step of this flow is to log in, and = logging in via identity-provider.com is supported. >=20 > The end result of this OAuth flow is an OAuth credential, asserting my = nifty-cool-email.org identity and the fact I'm allowed to access the = IMAP service. This OAuth credential, along with the name of the = resource being accessed ("example@nifty-coool-email.org") are sent via = IMAP, and the IMAP service use these to authenticate and authorize = access. It's up to the service provider to confirm that the [Identity = asserted by the OAuth credential] has [granted the client access to this = service] and [has granted the client access to this data]. >=20 > In this scenario, the Client has no idea what my identity-provider.com = identity is, and has no need to. It does know what resource I'm = attempting to access. >=20 >=20 > As a result, I believe you're right - and my previous statement was = incorrect - the hint should identify what the request is trying to = access. (This has been doubly confusing, as in my immediate use case, = these two values are the same.) >=20 >=20 > I hope the scenario example helps. > -R >=20 >=20 >=20 > On Wed, Sep 19, 2012 at 9:52 AM, John Bradley = wrote: > It isn't necessarily a user name it is or should be an identifier for = the resource being accessed. =20 >=20 > There may be more than one possible resource authorized by the access = token as the authorization request is not for a specific resource as far = as I can tell. Generally if you ask for an email token the = authorization server will find that unambiguous and grant you something = that gives you IMAP and SMTP access rights that may cover multiple IMAP = resources if they exist. >=20 > There is no one to one mapping from the resource identifier to the = user name. There is a possible many to many situation. =20 >=20 > I might use a hotmail account to login to a gmail account. =20 >=20 > I recognize that traditionally the resource identifier and the user = name are the same, but the world is now much more complicated. I think = you need both the resource identifier and grant unless the specific = resource is passed to the authorization server in the request. >=20 > John B. >=20 >=20 >=20 > On 2012-09-19, at 1:14 PM, William Mills wrote: >=20 >> I should be more general, the routing hint is the resource being = accessed in the context of the connection. The client needs to know = this. For the use cases I'm focused on that will be a user name. >>=20 >> From: William Mills >> To: Simon Josefsson ; "Cantor, Scott" = =20 >> Cc: "kitten@ietf.org" =20 >> Sent: Wednesday, September 19, 2012 9:06 AM >> Subject: Re: [kitten] Google and SASL OAuth >>=20 >> The hint is the user name being authenticated (as I've said multiple = times previously). The server is responsible for mapping the user name = to the server (cluster) handling that user. >>=20 >>=20 >> From: Simon Josefsson >> To: "Cantor, Scott" =20 >> Cc: "kitten@ietf.org" =20 >> Sent: Wednesday, September 19, 2012 12:11 AM >> Subject: Re: [kitten] Google and SASL OAuth >>=20 >> "Cantor, Scott" writes: >>=20 >> > On 9/18/12 6:09 PM, "Simon Josefsson" wrote: >> >>> >> >>> Authz-id can serve this purpose but it's not mandatory. You can = make >> >>> it mandatory in your service documentation, that's as easy as = making >> >>> an optional field in the SASL data that you require. >> >> >> >>No, the authzid cannot serve this purpose even if it were = mandatory. >> >>This is a misunderstanding. Ryan wants the identity of the OAuth >> >>credential owner as a routing hint to find a server that can verify = the >> >>OAuth credential for that user. The authzid has nothing to do with >> >>that. >> > >> > I thought from the earlier description that the purpose of the hint = was to >> > identify the server hosting the mailbox of the "effective" identity >> > involved, which to me seemed an awful lot like authzid. >>=20 >> That's not what I understand from the latest explanation: as I >> understand Ryan, the routing hint is there to identify the server = that >> is able to validate the OAuth credential. That makes the routing = hint >> effectively the authentication identity, although the routing hint >> cannot be relied on as the authentication identity until the = credential >> has been validated to belonging to the claimed user. >>=20 >> Ryan could you clarify for us again, please? >>=20 >> /Simon >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten >>=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 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 >=20 --Apple-Mail=_1845809F-7BCE-4B3B-92DE-690A4F8A58F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Right = that is the sort of thing I was thinking of.   That will be more = common especially with outsourcing enterprise email where there is still = a enterprise AD doing the actual User = authentication.

John B.

On = 2012-09-19, at 2:46 PM, Ryan Troll <rtroll@googlers.com> = wrote:

Good point re: OpenID.  I had to walk through this a = few times to get everything worked out right.  Here's the example I = came up with:



When setting up a desktop IMAP client to talk to nifty-cool-email.org, I = provide the client with the name of the email account I'm setting up (example@nifty-cool-email.org<= /a>).  The client will (eventually) be able to take this, find the = OAuth URLs associated with the service, and bring up a browser allowing = me to walk through the OAuth flow for nifty-cool-email.org. =  The first step of this flow is to log in, and logging in via identity-provider.com is = supported.

The end result of this OAuth flow is an OAuth = credential, asserting my nifty-cool-email.org identity = and the fact I'm allowed to access the IMAP service.  This OAuth = credential, along with the name of the resource being accessed ("example@nifty-coool-email.or= g") are sent via IMAP, and the IMAP service use these to = authenticate and authorize access.  It's up to the service provider = to confirm that the [Identity asserted by the OAuth credential] has = [granted the client access to this service] and [has granted the client = access to this data].

In this scenario, the Client has no idea what my identity-provider.com = identity is, and has no need to.  It does know what resource I'm = attempting to access.


As a result, I believe you're right - = and my previous statement was incorrect - the hint should identify what = the request is trying to access.  (This has been doubly confusing, = as in my immediate use case, these two values are the same.)


I hope the scenario example = helps.
-R



On Wed, Sep 19, 2012 at 9:52 AM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
It isn't necessarily a user name it is or = should be an identifier for the resource being accessed. =   

There may be more than one possible resource authorized = by the access token as the authorization request is not for a specific = resource as far as I can tell.   Generally if you ask for an email = token the authorization server  will find that unambiguous and = grant you something that gives you IMAP and SMTP access rights that may = cover multiple IMAP resources if they exist.

There is no one to one mapping from the resource = identifier to the user name.   There is a possible many to many = situation.  

I might use a hotmail account = to login to a gmail account.   

I recognize that traditionally the resource = identifier and the user name are the same, but the world is now much = more complicated.   I think you need both the resource identifier = and grant unless the specific resource is passed to the authorization = server in the request.

John B.



On = 2012-09-19, at 1:14 PM, William Mills <wmills@yahoo-inc.com> wrote:

I should be more = general, the routing hint is the resource being accessed in the context = of the connection.  The client needs to know this.  For the = use cases I'm focused on that will be a user name.

From: William Mills <wmills@yahoo-inc.com>
To: Simon Josefsson <simon@josefsson.org>; "Cantor, Scott" <cantor.2@osu.edu>
Cc: "kitten@ietf.org" = <kitten@ietf.org>
Sent: Wednesday, = September 19, 2012 9:06 AM
Subject: Re: [kitten] Google and = SASL OAuth

The hint is the user name being authenticated (as I've said multiple = times previously).  The server is responsible for mapping the user = name to the server (cluster) handling that = user.


From: Simon Josefsson <simon@josefsson.org>
To: "Cantor, Scott" <cantor.2@osu.edu>
Cc: "kitten@ietf.org" = <kitten@ietf.org>
Sent: Wednesday, September 19, = 2012 12:11 AM
Subject: Re: [kitten] = Google and SASL OAuth

"Cantor, Scott" <cantor.2@osu.edu> writes:

> On 9/18/12 6:09 PM, "Simon Josefsson" <simon@josefsson.org> = wrote:
>>>
>>> Authz-id can serve this purpose = but it's not mandatory.  You can make
>>> it mandatory in your service documentation, that's as easy = as making
>>> an optional field in the SASL data that you = require.
>>
>>No, the authzid cannot serve this = purpose even if it were mandatory.
>>This is a misunderstanding.  Ryan wants the identity of the OAuth
>>credential owner as a = routing hint to find a server that can verify the
>>OAuth = credential for that user.  The authzid has nothing to do = with
>>that.
>
> I thought from the earlier description that the purpose of the hint = was to
> identify the server hosting the mailbox of the = "effective" identity
> involved, which to me seemed an awful lot = like authzid.

That's not what I understand from the latest explanation: as = I
understand Ryan, the routing hint is there to identify the server = that
is able to validate the OAuth credential.  That makes the = routing hint
effectively the authentication identity, although the routing = hint
cannot be relied on as the authentication identity until the = credential
has been validated to belonging to the claimed = user.

Ryan could you clarify for us again, = please?

/Simon
_______________________________________________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



= --Apple-Mail=_1845809F-7BCE-4B3B-92DE-690A4F8A58F2-- From nico@cryptonector.com Wed Sep 19 11:12: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 07E2B21F861F for ; Wed, 19 Sep 2012 11:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 3dUrl1PRCiL4 for ; Wed, 19 Sep 2012 11:12:58 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB1D21F861D for ; Wed, 19 Sep 2012 11:12:52 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id DE76A28606F for ; Wed, 19 Sep 2012 11:12:51 -0700 (PDT) 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-a97.g.dreamhost.com (Postfix) with ESMTPSA id C0E01286058 for ; Wed, 19 Sep 2012 11:12:51 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so754635pbb.31 for ; Wed, 19 Sep 2012 11:12:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr112330pbc.149.1348078371424; Wed, 19 Sep 2012 11:12:51 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 11:12:51 -0700 (PDT) In-Reply-To: References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> Date: Wed, 19 Sep 2012 13:12:51 -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] Google and 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: Wed, 19 Sep 2012 18:12:59 -0000 On Wed, Sep 19, 2012 at 12:46 PM, Ryan Troll wrote: > As a result, I believe you're right - and my previous statement was > incorrect - the hint should identify what the request is trying to access. > (This has been doubly confusing, as in my immediate use case, these two > values are the same.) Right, that's the source of the confusion. The right thing to do is to say that the IMAP server uses the authz-id *if provided* as the resource name, else it *derives* one from the authcid. So I believe we're back to *not* needing the user KV. Correct? Nico -- From ve7jtb@ve7jtb.com Wed Sep 19 11:23: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 DC49F21F8493 for ; Wed, 19 Sep 2012 11:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 pHHjdVltxq42 for ; Wed, 19 Sep 2012 11:23:25 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA94121F8489 for ; Wed, 19 Sep 2012 11:23:24 -0700 (PDT) Received: by ghbg10 with SMTP id g10so375070ghb.31 for ; Wed, 19 Sep 2012 11:23:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=2HX4r+bnpaBy6MQZy86SHr0j2yCMncky1ZS0w5hqc4o=; b=KYOgE+mAqh+hAgI0z1nx42o7/xpqf3aa4MyKftWyw0D3YikyJnQZB5BNNr0E7u1ffm UC9cwVlA0HTaqMa1moFlkIOA2Pw2HV6aO5z8wVI9muf0d0iSZoOfVhnSqTSjku5rt4D6 aOp3cRmD0ONKTPza6bQ5zG96OXRisplK37ldFbAAU0uC+Pei9g1SBwgYRH91rdYxfbtg TPEXwaXWjV/mamUWx+obcKN9tbalRtiFRQXPaJkwLVlyJPzgP7FjyWgQ3vHB74M7UBVF 2iYTTiMbudgs5FzGo8rnJxCrMHstVz8WMahsdDHAbsppE7sQlUZ9H3iesPxoVExjRjCZ itYw== Received: by 10.236.155.71 with SMTP id i47mr4455039yhk.72.1348079003838; Wed, 19 Sep 2012 11:23:23 -0700 (PDT) Received: from [192.168.1.211] (190-20-24-188.baf.movistar.cl. [190.20.24.188]) by mx.google.com with ESMTPS id a4sm3491619anm.14.2012.09.19.11.23.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Sep 2012 11:23:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: Date: Wed, 19 Sep 2012 15:22:55 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <97FF49B2-E200-4A39-BDEF-5F6A5D3892B5@ve7jtb.com> References: To: Nico Williams X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQld6it70eauTnk8xdMHP+djfHmS4AmeQN7uqE49d2VlPL9nrk72OomJRPcS/tK7DMFKDO89 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 18:23:26 -0000 The ID of the client using the credential is mostly for OAuth 1 = compatibility. =20 The signature mechanism probably should use it as there is no guarantee = that the keyid is globally unique to the authorization server or scoped = to the client. It has no relevance to the Oauth 2 RS, one of the reasons I suspect it = is not mentioned in XOAuth2. I think the notion of a ID of the credential owner is confusing and not = relevant to a OAuth RS. The resource owner makes a grant that wis translated into a access = token. The RS needs to know the resource being accessed and then determine if = the token allows the access. In some cases people overload the access token with additional state = information about he context of the request.=20 That is a implementation decision and outside of the OAuth 2 spec. If you want to keep it clean fully specify the resource in the request = separate from the access token. The token may be encrypted and only inspect-able in the context of the = resource by the RS. John B. On 2012-09-19, at 3:02 PM, Nico Williams wrote: > On Tue, Sep 18, 2012 at 8:28 PM, Luke Howard wrote: >>>> No, the authzid cannot serve this purpose even if it were = mandatory. >>>> This is a misunderstanding. Ryan wants the identity of the OAuth >>>> credential owner as a routing hint to find a server that can verify = the >>>> OAuth credential for that user. The authzid has nothing to do with >>>> that. >>>=20 >>> I thought from the earlier description that the purpose of the hint = was to >>> identify the server hosting the mailbox of the "effective" identity >>> involved, which to me seemed an awful lot like authzid. >>=20 >> I am with Scott here in this understanding. >=20 > Me too. >=20 > I'm very confused by the turn this thread is taking. >=20 > Can we step back and state requirements clearly? >=20 > I thought the requirements were: >=20 > a) communicate the ID of the credential owner; > b) communicate what Ryan calls a "routing hint" but which we Scott, > Luke, Simon, and I believe is rightly the SASL authz-id; > c) communicate some other ID? like the ID of the proxy using the = credential? >=20 > Nico > -- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From rtroll@google.com Wed Sep 19 11:27: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 401A421E804A for ; Wed, 19 Sep 2012 11:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.872 X-Spam-Level: X-Spam-Status: No, score=-102.872 tagged_above=-999 required=5 tests=[AWL=0.104, 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 AnfLiHcsxfdF for ; Wed, 19 Sep 2012 11:27:48 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEE121E8043 for ; Wed, 19 Sep 2012 11:27:48 -0700 (PDT) Received: by iec9 with SMTP id 9so2295547iec.31 for ; Wed, 19 Sep 2012 11:27:48 -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=4zW23JcTv/BkR0duoh/V7I8ofhCXclSTH9qNBPUDGyw=; b=CzyNdpbKTnnNSmAw+P5zb/w1kWYL91rasTKU7WGzwb/VHttcVzASdHGdSJ9LJu+k35 zbnMlZrFmgx3h2P8oGyFFsnO8FwNp1UjVk1j8+uKyUaZt48uYvUkN9E9lM+Z4m41bwti SzjNDapQWfyo9KRPvoNzd8pEoN+yXAggykCeU= 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=4zW23JcTv/BkR0duoh/V7I8ofhCXclSTH9qNBPUDGyw=; b=TLr0/aBgSkaXL+pmWc4U92F0OnszDG6FpDfm+XE9eSHH2W4OJcwgcOkacmrqAWN7pv C84zDm9sFQq7b4sYZLOj27ZlDinOf2Px6YhUiaov0pC0kq8lzblySvO5Ntu8q3miJ6RB CW7aD9I02vQaDwQvcgWiQQ88ojxA3UcXjkWgBe/rmeRUlddzk7mz/3qthVZbDzjd4uhy AZ7mkLFNqFLUnLndWraoP7G7C7rR3zEYJEwb7/ozQ8imvDZcNOpJaar41pF04/tzA1JM /ZlYrpgWxUhdGOzv7ds7VC6yNDbsQ8n9wJuaIVs6hRUf9qCc07ygHMU49YALC3mHN3HY CXRg== Received: by 10.50.188.129 with SMTP id ga1mr195476igc.6.1348079268093; Wed, 19 Sep 2012 11:27:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.188.129 with SMTP id ga1mr195468igc.6.1348079267977; Wed, 19 Sep 2012 11:27:47 -0700 (PDT) Received: by 10.50.36.131 with HTTP; Wed, 19 Sep 2012 11:27:47 -0700 (PDT) In-Reply-To: References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> Date: Wed, 19 Sep 2012 11:27:47 -0700 Message-ID: From: Ryan Troll To: Nico Williams Content-Type: multipart/alternative; boundary=14dae93407f7e59ac804ca122978 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmBoCFEnluX0QoSGxpx/HYTOH2t8NBBPHiuJipj4QUUYQ5IZD35OZfn8Q8SyQhnhIPIwqw1QhFQGZ+yuI5byPJchKuQHKnGBPkE2i9/G08nYjxRekE2vLVZCtJ/SRnsg17csF3prxulyUCEEhriQY59yLs7ZD2tpq7z74ll665v9ukpZ7Ch8TnURPiaGbr6Ji6Y6cKP Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 18:27:49 -0000 --14dae93407f7e59ac804ca122978 Content-Type: text/plain; charset=ISO-8859-1 Sorry to keep this moving in circles; but I think with the OpenID example, things were (at least for me) easier to visualize. Nico: The right thing to do is to say that the IMAP server uses the authz-id > *if provided* as the resource name, else it *derives* one from the > authcid. > > This makes sense, and is what we came up with around 9/4. > So I believe we're back to *not* needing the user KV. Correct? Correct. I believe this discussion came up because we launched our OAuth2 support, which was based on version -03 of the draft, and Bill asked if including it would make migration simpler. Nice to ask, but not necessary. One thing that would make this really helpful would be an example of a successful SASL/OAuth transaction, with the authc-id and authz-id included. -R --14dae93407f7e59ac804ca122978 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry to keep this moving in circles; but I think with the OpenID example, = things were (at least for me) easier to visualize.

Nico:=


So I believe we're back to *not* needing the user KV. =A0Correct?

Correct. =A0I believe this discussion came up be= cause we launched our OAuth2 support, which was based on version -03 of the= draft, and Bill asked if including it would make migration simpler. Nice t= o ask, but not necessary.

One thing that would make this really helpful would be = an example of a successful SASL/OAuth transaction, with the authc-id and au= thz-id included.

-R
--14dae93407f7e59ac804ca122978-- From cantor.2@osu.edu Wed Sep 19 11:30: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 D925021E8043 for ; Wed, 19 Sep 2012 11:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.795 X-Spam-Level: X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[AWL=-0.196, 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 K2lR7cRt+JzV for ; Wed, 19 Sep 2012 11:30:45 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3EB21E803A for ; Wed, 19 Sep 2012 11:30:45 -0700 (PDT) Received: from mail79-co1-R.bigfish.com (10.243.78.226) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Sep 2012 18:30:44 +0000 Received: from mail79-co1 (localhost [127.0.0.1]) by mail79-co1-R.bigfish.com (Postfix) with ESMTP id C0C4EB40066; Wed, 19 Sep 2012 18:30:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371I1432I1418Id6f1izz1202h1d1ah1d2ahzz8275bhz2fh87h2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail79-co1: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail79-co1 (localhost.localdomain [127.0.0.1]) by mail79-co1 (MessageSwitch) id 1348079443202782_31465; Wed, 19 Sep 2012 18:30:43 +0000 (UTC) Received: from CO1EHSMHS017.bigfish.com (unknown [10.243.78.249]) by mail79-co1.bigfish.com (Postfix) with ESMTP id 2F754380045; Wed, 19 Sep 2012 18:30:43 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by CO1EHSMHS017.bigfish.com (10.243.66.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Sep 2012 18:30:41 +0000 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, 19 Sep 2012 14:30:25 -0400 From: "Cantor, Scott" To: Nico Williams , Ryan Troll Thread-Topic: [kitten] Google and SASL OAuth Thread-Index: AQHNlepDvUDtSOgX70WW0RrYcbNMvJeQuHuAgAEdFHqAAEVTAIAACpkAgAAPRgCAAAc7gP//wdiA Date: Wed, 19 Sep 2012 18:30:25 +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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 18:30:46 -0000 On 9/19/12 2:12 PM, "Nico Williams" wrote: >On Wed, Sep 19, 2012 at 12:46 PM, Ryan Troll wrote: >> As a result, I believe you're right - and my previous statement was >> incorrect - the hint should identify what the request is trying to >>access. >> (This has been doubly confusing, as in my immediate use case, these two >> values are the same.) > >Right, that's the source of the confusion. > >The right thing to do is to say that the IMAP server uses the authz-id >*if provided* as the resource name, else it *derives* one from the >authcid. > >So I believe we're back to *not* needing the user KV. Correct? I think the problem is that if they need the hint to route the request *up front* to the right back end before the OAuth credential is even delivered and evaluated, then you end up needing to require authzid or adding something. I think that's the source of the problem. If the client decides whether to supply an authzid independent of SASL mech, then obviously it's not workable to say "when using OAuth, client must supply authzid". So I think it's an order of evaluation problem, when the hint is first needed. If it's only needed after the OAuth token is received and the authcid determined, then what you suggest sounds ok. -- Scott From wmills@yahoo-inc.com Wed Sep 19 11: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 785AD21F85B8 for ; Wed, 19 Sep 2012 11:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.468 X-Spam-Level: X-Spam-Status: No, score=-17.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 ktchFDgopzcZ for ; Wed, 19 Sep 2012 11:48:14 -0700 (PDT) Received: from nm13.bullet.mail.bf1.yahoo.com (nm13.bullet.mail.bf1.yahoo.com [98.139.212.172]) by ietfa.amsl.com (Postfix) with SMTP id 9C24E21F849B for ; Wed, 19 Sep 2012 11:48:14 -0700 (PDT) Received: from [98.139.215.140] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 19 Sep 2012 18:48:14 -0000 Received: from [98.139.212.197] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 19 Sep 2012 18:48:14 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 19 Sep 2012 18:48:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 997738.14166.bm@omp1006.mail.bf1.yahoo.com Received: (qmail 46335 invoked by uid 60001); 19 Sep 2012 18:48:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348080493; bh=1czgdGa85Zd5A4pN/NDbEh8q6rx2P6HuKnK8AlX8yy8=; 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=Z8f/gw3bSQjbiMH6E4DrQKimIwP6HrLPCGytm0+e5BZVsjAzoEgcBxJNNbqOWPLksPv0qA31ob9WM7+qZFzHgVnAj1M2h8SRJLLhtY1JRWGeVJrwB00dkDl/6tU6lubmzazpGxeUwTJgVqn4myiuzMy1gBroIO6Xe0EODTEGhXU= 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=oPRGWaY58Eowb8iCN2AcmynMmVfNuUuUo7QTN3M3XhhcRWVy7iYWn9Ey7xcZQmGQvzeVtbKmfljM6Vb8JmI4ViHrp2k9CN3vwzYs9FTEPfxsYTAQTFFFhLpOjirNgw3knm8IMGqyxnJhq7qg4+rC2nb3eRHP8+3ABh6B67FECQw=; X-YMail-OSG: gi9PAmwVM1kgpKhpL7C9DPByC1kTqiFeLI9HLT2x2CS8475 xCI0xMwtMCIM.X2oQRg0MDFKOiZl8SFF4RV8nEp_pGkZhYruA.2VYz_GkjJW 9mgBmnlwPTQQsQFsrnf_QRfTtExXwzL.UyJlq5zNazPD8wnplgFhXsptw6Mz ONYobdgbhCUH.vZZuxs6p.W0zRoSZIwewEcsQ8.be1rSXyRcGlvhtnNtdUe9 0Cle5sI31MkA5zAu9JDv_P997aF21mJ5x_ObSGxU_vD6dqc6SfwlTjk8rsjA dfcSrF8hF0L4N2tWzjOkEDdmK5W6A_5LUQAxBIeDX7Xif8x6qjRBauVxtv8_ z_Hk_8LiAjG3h9Eqflrn28WRpvmdkqi6XXQZJHazRHFYPPMjkC5Mi5hFAdcq rRA8INsSSTrkcJCt3PUwapHKj9U9qQXlH_Rrd.K0X0SpRtKHEIOrxTtKzloZ Y84oIMGM- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Wed, 19 Sep 2012 11:48:13 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: Message-ID: <1348080493.34585.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 11:48:13 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Nico Williams , Ryan Troll In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 18:48:15 -0000 =0A>So I think it's an order of evaluation problem, when the hint is first= =0A>needed. If it's only needed after the OAuth token is received and the= =0A>authcid determined, then what you suggest sounds ok.=0A=0AYes, and the = stated goal is that the hint is provided and used before the=0Atoken is val= idated.=0A=0A=0A=0A=0A=0A=0A>________________________________=0A> From: "Ca= ntor, Scott" =0A>To: Nico Williams ; Ryan Troll =0A>Cc: "kitten@ietf.org" ; Simon Josefsson =0A>Sent: Wednesday, September = 19, 2012 11:30 AM=0A>Subject: Re: [kitten] Google and SASL OAuth=0A> =0A>On= 9/19/12 2:12 PM, "Nico Williams" wrote:=0A>=0A>>On= Wed, Sep 19, 2012 at 12:46 PM, Ryan Troll wrote:=0A>= >> As a result, I believe you're right - and my previous statement was=0A>>= > incorrect - the hint should identify what the request is trying to=0A>>>a= ccess.=0A>>> (This has been doubly confusing, as in my immediate use case, = these two=0A>>> values are the same.)=0A>>=0A>>Right, that's the source of = the confusion.=0A>>=0A>>The right thing to do is to say that the IMAP serve= r uses the authz-id=0A>>*if provided* as the resource name, else it *derive= s* one from the=0A>>authcid.=0A>>=0A>>So I believe we're back to *not* need= ing the user KV.=A0 Correct?=0A>=0A>I think the problem is that if they nee= d the hint to route the request *up=0A>front* to the right back end before = the OAuth credential is even delivered=0A>and evaluated, then you end up ne= eding to require authzid or adding=0A>something. I think that's the source = of the problem.=0A>=0A>If the client decides whether to supply an authzid i= ndependent of SASL=0A>mech, then obviously it's not workable to say "when u= sing OAuth, client=0A>must supply authzid".=0A>=0A>So I think it's an order= of evaluation problem, when the hint is first=0A>needed. If it's only need= ed after the OAuth token is received and the=0A>authcid determined, then wh= at you suggest sounds ok.=0A>=0A>-- Scott=0A>=0A>=0A>______________________= _________________________=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>http= s://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> From nico@cryptonector.com Wed Sep 19 11:49: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 EC14321F85D5 for ; Wed, 19 Sep 2012 11:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=-0.117, 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 mmypWk+At+rw for ; Wed, 19 Sep 2012 11:49:12 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6928B21F85C6 for ; Wed, 19 Sep 2012 11:49:12 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 3D7CD438072 for ; Wed, 19 Sep 2012 11:49: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=ymDDU1McwHcM2wro26Cf EbsMTjY=; b=lm0p6u3Z8xqBTXL3QOid8M8gjVBe/9oa6AmAPhwW9/LXpR8rh/4c 2EZeL5OcQoLly5iUPZxudurXdlglf7x//umZBpjoVQmQ5+DicXoUDKbdmbechIzQ NIbvR71mC57tq1w1os+whC3gLsHClRJ+qAruMJilzlN8fDS2NjN9i9A= 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 23EA143806C for ; Wed, 19 Sep 2012 11:49:12 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so822890pbb.31 for ; Wed, 19 Sep 2012 11:49:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.75.133 with SMTP id c5mr9093816paw.24.1348080551747; Wed, 19 Sep 2012 11:49:11 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 11:49:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Sep 2012 13:49:11 -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] Google and 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: Wed, 19 Sep 2012 18:49:13 -0000 On Wed, Sep 19, 2012 at 1:30 PM, Cantor, Scott wrote: > I think the problem is that if they need the hint to route the request *up > front* to the right back end before the OAuth credential is even delivered > and evaluated, then you end up needing to require authzid or adding > something. I think that's the source of the problem. > > If the client decides whether to supply an authzid independent of SASL > mech, then obviously it's not workable to say "when using OAuth, client > must supply authzid". No, it's workable: the service provider just has to tell the customers how to configure their client. The problem is that it'd be nice to not have to do that. > So I think it's an order of evaluation problem, when the hint is first > needed. If it's only needed after the OAuth token is received and the > authcid determined, then what you suggest sounds ok. Neither the authz-id nor the authcid can be had without actually consuming the SASL authentication messages. The only way an order of processing issue comes up is if the server implementation isn't following SASL strictly. Nico -- From nico@cryptonector.com Wed Sep 19 11:51: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 D42B421F85DA for ; Wed, 19 Sep 2012 11:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=-0.113, 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 9LWz78pSo-+x for ; Wed, 19 Sep 2012 11:51:06 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 527FF21F85C6 for ; Wed, 19 Sep 2012 11:51:06 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 0529F202038 for ; Wed, 19 Sep 2012 11:51:06 -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=zxSssMf6XDhOlVE8lyAb RmM+6pc=; b=hdeGwzdh4VjtjR4e6aMIH0Ut9AtPp217JUx3MB5DbtwOaEPGNpR6 T8w8buXmHRp9GZi0B2VxdO5RzvZJKFMWmg2RNixRUMBY7Ypw9Bu/id3UCfKTXqbX iz6+2o16fEQ1xaYtoxfYUxD00aRFYbiyY1E9Lhhd8RbiFBU+WwOwQ0Q= 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 D8DCD202022 for ; Wed, 19 Sep 2012 11:51:05 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so826329pbb.31 for ; Wed, 19 Sep 2012 11:51:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.220.104 with SMTP id pv8mr416748pbc.119.1348080665555; Wed, 19 Sep 2012 11:51:05 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 11:51:05 -0700 (PDT) In-Reply-To: <1348080493.34585.YahooMailNeo@web31813.mail.mud.yahoo.com> References: <1348080493.34585.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 13:51:05 -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] Google and 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: Wed, 19 Sep 2012 18:51:07 -0000 On Wed, Sep 19, 2012 at 1:48 PM, William Mills wrote: > >>So I think it's an order of evaluation problem, when the hint is first >>needed. If it's only needed after the OAuth token is received and the >>authcid determined, then what you suggest sounds ok. > > Yes, and the stated goal is that the hint is provided and used before the > token is validated. SASL does not allow that. You see bits on the wire and you think "hey, the bits I need are right there, so let's grab them", but the frameworks involved make these bits opaque to you. You don't have to use an implementation of the framework, but you must not preclude someone who chooses to do so from implementing the same functionality. Nico -- From wmills@yahoo-inc.com Wed Sep 19 11:55: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 A98C911E8091 for ; Wed, 19 Sep 2012 11:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.473 X-Spam-Level: X-Spam-Status: No, score=-17.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 PXW3-cN2jAwe for ; Wed, 19 Sep 2012 11:55:19 -0700 (PDT) Received: from nm3-vm4.bullet.mail.ne1.yahoo.com (nm3-vm4.bullet.mail.ne1.yahoo.com [98.138.91.163]) by ietfa.amsl.com (Postfix) with SMTP id AD4A521F8602 for ; Wed, 19 Sep 2012 11:55:18 -0700 (PDT) Received: from [98.138.90.53] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2012 18:55:14 -0000 Received: from [98.138.89.252] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2012 18:55:14 -0000 Received: from [127.0.0.1] by omp1044.mail.ne1.yahoo.com with NNFMP; 19 Sep 2012 18:55:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 712511.77463.bm@omp1044.mail.ne1.yahoo.com Received: (qmail 61439 invoked by uid 60001); 19 Sep 2012 18:55:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348080914; bh=6pDS8MCRpQg0j/oLIheDhAEWfnVf8LwQZ9HCZMwoyPI=; 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=AbmzhOzy2KDrc+6uvf1/XpHR4s4b1vCF3dP194s7TCWFxb6rA/PWq9AdGbgLe0QY4LgguCEVH9AOVYNvXMLo3LMPGWf7dkK7Ht24aT7t19Ux41hddGYhz459DTWM/r4UUD8eUQu+zIpRMT/q45Say79E0NCZBwsmQVJDE0vDpH8= 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=aXTSOVdH1NZm4GYTyC/SA5V82ppoddeM5rOGdMZvkutl1Q1/iXML8pwILLd9+EQ4IF5UFfMkd3D6Zt+tk5LIY7J8nvVJszcnY30AHeaTwT6ZbAQhe4VLGxGUThGcNHf1fm/GIKWm2cNu5rLm8fo2zjBgQ6wBe1eAe/oL+bjU2U4=; X-YMail-OSG: Ti_nr4EVM1nr53iwHvfQ4YQp1FCWTSvVuZTXZSBKFNHRGru K4Zm.h1fir20MJ0fswYKETv0gUdq7_rLqTQAAg9yGB4q8tSS3mxsfD23I11w 7XNwC2mhPtaIIVGU.cVlaOKBRaccktr73_T_hedXRWSHkaU2_LJDqxQiNEnK 43hu35itQCdLjqrdp31PUa_9xzkHjrT3VQuAaCJsc6sVgt3AtUfnuKaWVx5b GmInJY3u3NMga2RQ7W0WsYLbFiKwdU52Q0TOZlM6rIh.hK411RsugIDU8b9T LZ6jxYUr24zoHAxIHSsTE1DxfmkDkkcXqHxTmSp1MhqkRq5Tt8_rv7X28rzJ Q5d4m7zfsHUvly0YDDRYcFpWZFL2AzGtXAkO.C33SQrowThBIy1ZKQSs1Kcl id95dXVe5t2Y3oKZxDsddVjc8PCkSky4ggsv3Ce8ES6l_E_y_1W6XXeG2QxT H7NnankCo Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Wed, 19 Sep 2012 11:55:14 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <1348080493.34585.YahooMailNeo@web31813.mail.mud.yahoo.com> Message-ID: <1348080914.59493.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 11:55:14 -0700 (PDT) From: William Mills To: William Mills , "Cantor, Scott" , Nico Williams , Ryan Troll In-Reply-To: <1348080493.34585.YahooMailNeo@web31813.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 18:55:19 -0000 And tokens are an opaque blob and not decrypted by the routing server.=0A= =0A=0A=0A=0A----- Original Message -----=0A> From: William Mills =0A> To: "Cantor, Scott" ; Nico Williams ; Ryan Troll =0A> Cc: "kitten@ietf.= org" ; Simon Josefsson =0A> Sent: Wed= nesday, September 19, 2012 11:48 AM=0A> Subject: Re: [kitten] Google and SA= SL OAuth=0A> =0A> =0A>> So I think it's an order of evaluation problem, whe= n the hint is first=0A>> needed. If it's only needed after the OAuth token = is received and the=0A>> authcid determined, then what you suggest sounds o= k.=0A> =0A> Yes, and the stated goal is that the hint is provided and used = before the=0A> token is validated.=0A> =0A> =0A> =0A> =0A> =0A> =0A>> _____= ___________________________=0A>> From: "Cantor, Scott" = =0A>> To: Nico Williams ; Ryan Troll =0A> =0A>> Cc: "kitten@ietf.org" ; Simon Josefsson = =0A> =0A>> Sent: Wednesday, September 19, 2012 11:30 = AM=0A>> Subject: Re: [kitten] Google and SASL OAuth=0A>> =0A>> On 9/19/12 2= :12 PM, "Nico Williams" =0A> wrote:=0A>> =0A>>> On = Wed, Sep 19, 2012 at 12:46 PM, Ryan Troll =0A> wrote:= =0A>>>> As a result, I believe you're right - and my previous statement = =0A> was=0A>>>> incorrect - the hint should identify what the request is t= rying to=0A>>>> access.=0A>>>> (This has been doubly confusing, as in my i= mmediate use case, these =0A> two=0A>>>> values are the same.)=0A>>> =0A>>= > Right, that's the source of the confusion.=0A>>> =0A>>> The right thing t= o do is to say that the IMAP server uses the authz-id=0A>>> *if provided* a= s the resource name, else it *derives* one from the=0A>>> authcid.=0A>>> = =0A>>> So I believe we're back to *not* needing the user KV.=A0 Correct?=0A= >> =0A>> I think the problem is that if they need the hint to route the req= uest *up=0A>> front* to the right back end before the OAuth credential is e= ven delivered=0A>> and evaluated, then you end up needing to require authzi= d or adding=0A>> something. I think that's the source of the problem.=0A>> = =0A>> If the client decides whether to supply an authzid independent of SAS= L=0A>> mech, then obviously it's not workable to say "when using OAuth, =0A= > client=0A>> must supply authzid".=0A>> =0A>> So I think it's an order of = evaluation problem, when the hint is first=0A>> needed. If it's only needed= after the OAuth token is received and the=0A>> authcid determined, then wh= at you suggest sounds ok.=0A>> =0A>> -- Scott=0A>> =0A>> =0A>> ____________= ___________________________________=0A>> Kitten mailing list=0A>> Kitten@ie= tf.org=0A>> https://www.ietf.org/mailman/listinfo/kitten=0A>> =0A>> =0A>> = =0A> _______________________________________________=0A> Kitten mailing lis= t=0A> Kitten@ietf.org=0A> https://www.ietf.org/mailman/listinfo/kitten=0A> From cantor.2@osu.edu Wed Sep 19 12:01: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 84AC621E809F for ; Wed, 19 Sep 2012 12:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.786 X-Spam-Level: X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[AWL=-0.187, 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 5qpU8qbZs0Jl for ; Wed, 19 Sep 2012 12:01:01 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id BB9B511E8091 for ; Wed, 19 Sep 2012 12:00:56 -0700 (PDT) Received: from mail102-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Sep 2012 19:00:52 +0000 Received: from mail102-ch1 (localhost [127.0.0.1]) by mail102-ch1-R.bigfish.com (Postfix) with ESMTP id CF80E80293; Wed, 19 Sep 2012 19:00:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.171; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT06.osuad.osu.edu; RD:cio-tnc-ht06.osuad.osu.edu; EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zzbb2dI98dI9371I1432Id6f1izz1202h1d1ah1d2ahzz8275bhz2fh87h2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail102-ch1: domain of osu.edu designates 164.107.81.171 as permitted sender) client-ip=164.107.81.171; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT06.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail102-ch1 (localhost.localdomain [127.0.0.1]) by mail102-ch1 (MessageSwitch) id 1348081250817692_7782; Wed, 19 Sep 2012 19:00:50 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail102-ch1.bigfish.com (Postfix) with ESMTP id C2E9C1A004D; Wed, 19 Sep 2012 19:00:50 +0000 (UTC) Received: from CIO-TNC-HT06.osuad.osu.edu (164.107.81.171) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Sep 2012 19:00:49 +0000 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, 19 Sep 2012 15:00:48 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] Google and SASL OAuth Thread-Index: AQHNlepDvUDtSOgX70WW0RrYcbNMvJeQuHuAgAEdFHqAAEVTAIAACpkAgAAPRgCAAAc7gP//wdiAgABIT4D//8AsAA== Date: Wed, 19 Sep 2012 19:00: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: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <374692CF9001DE4B8093E055BC3D8819@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 19:01:01 -0000 On 9/19/12 2:49 PM, "Nico Williams" wrote: >> >> If the client decides whether to supply an authzid independent of SASL >> mech, then obviously it's not workable to say "when using OAuth, client >> must supply authzid". > >No, it's workable: the service provider just has to tell the customers >how to configure their client. The problem is that it'd be nice to >not have to do that. Perhaps, but I think it's nicer not to have to glue in extra mechanism fields that have weird overlapping semantics too. -- Scott From wmills@yahoo-inc.com Wed Sep 19 12: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 899DE21F84F1 for ; Wed, 19 Sep 2012 12:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.477 X-Spam-Level: X-Spam-Status: No, score=-17.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 6hw8I4HGZdfF for ; Wed, 19 Sep 2012 12:08:49 -0700 (PDT) Received: from nm15-vm2.bullet.mail.ne1.yahoo.com (nm15-vm2.bullet.mail.ne1.yahoo.com [98.138.91.91]) by ietfa.amsl.com (Postfix) with SMTP id B98DC21F8467 for ; Wed, 19 Sep 2012 12:08:49 -0700 (PDT) Received: from [98.138.90.54] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2012 19:08:40 -0000 Received: from [98.138.89.233] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2012 19:08:40 -0000 Received: from [127.0.0.1] by omp1048.mail.ne1.yahoo.com with NNFMP; 19 Sep 2012 19:08:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 957233.31281.bm@omp1048.mail.ne1.yahoo.com Received: (qmail 72315 invoked by uid 60001); 19 Sep 2012 19:08:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348081720; bh=bFna5eirKG1AI6Gw1CuMgDLq2AMWrUkncvUngTGXEpU=; 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=Sks008syD3Mrc49sjp9Ho8ZGfG6IzzOMpvDBIB3LEUyUt6YYRq8uWCOj6hhVQikxqm0jHYiiUYxSQ9m8zGWDrYcxQm+tQ3iwuyOObIyU5zsPEV5NrlsiSy6OPPuDOLzWf28sZ5TrcEr7r5oOkMrjjaCo5nUFYRE6RyEqRm2NvGE= 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=Z5Qed6sg+x97BaMnCD75jEBr5a0fzDpTJf4LoovFUJwPT/ODgNYgr5HzJjHNe2F0Lbw3oZzArJG8BG7e+8khW/81yCku/4YgYxK+sMlUyHsr4ZQxw6FEWoOaL1CfAyIccfZxQnN1PXy+4NLw5v0t6yLjNtZC9SXhRWtdlUTKMOw=; X-YMail-OSG: Kkb7ovAVM1n49QfWsq6SheSQtgPCrbWHtMswmm5kWTv1jeT oMm2K9QROy0ZyN3D9Vro6OVRYmroP2ox.njIUjjBM_8RkGqBGiKK8SGgMYa0 GPVPUef8KqB.VV6WKZsea703NxzubtPClWLUV81O_ft9wOjjF2xI_dOa_FTY T.e26u8RhYgVOrPmOZUaWeonpoIaBrc.I3efELEMK6YzTXt.7HSz892QOJvI YcNmfkYatGZ4VSJXiJ6OLWSO.Tk6_tQ3xcHeAfCqvrw_.m5XNW7XsQGZqc.0 58pw565Hp_AKD9_hhKrhWLUemqELSESqWYYgvmVdhj9.I7CaOxSK4XZqa3ws BBCo1IjEAqufuCfjrt13kldeW8ETcaNl1UiAqx3WD7jA1S3EDESzt3NUk.hb jbkj97iBBZhhcKQ0Y8lljs37BHPeIahKqMxAGnzECiNQOjXnf7J6W66_IDoL cgrn03jUh Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Wed, 19 Sep 2012 12:08:40 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: Message-ID: <1348081720.8612.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 12:08:40 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 19:08:50 -0000 So have we danced around the floor again to the point where the gs2-header = authzid can be used for this purpose and some services may require the clie= nt applications to send authz-id?=0A=0A=0A=0A=0A----- Original Message ----= -=0A> From: "Cantor, Scott" =0A> To: Nico Williams =0A> Cc: "kitten@ietf.org" ; Simon Josefs= son =0A> Sent: Wednesday, September 19, 2012 12:00 PM= =0A> Subject: Re: [kitten] Google and SASL OAuth=0A> =0A> On 9/19/12 2:49 P= M, "Nico Williams" =0A> wrote:=0A>>> =0A>>> If the= client decides whether to supply an authzid independent of SASL=0A>>> mec= h, then obviously it's not workable to say "when using =0A> OAuth, client= =0A>>> must supply authzid".=0A>> =0A>> No, it's workable: the service pro= vider just has to tell the customers=0A>> how to configure their client.=A0= The problem is that it'd be nice to=0A>> not have to do that.=0A> =0A> Per= haps, but I think it's nicer not to have to glue in extra mechanism=0A> fie= lds that have weird overlapping semantics too.=0A> =0A> -- Scott=0A> =0A> = =0A> _______________________________________________=0A> Kitten mailing lis= t=0A> Kitten@ietf.org=0A> https://www.ietf.org/mailman/listinfo/kitten=0A> From cantor.2@osu.edu Wed Sep 19 12:10: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 9D79321F8573 for ; Wed, 19 Sep 2012 12:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.779 X-Spam-Level: X-Spam-Status: No, score=-3.779 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 T4EY-oSvKovk for ; Wed, 19 Sep 2012 12:10:38 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 09E8921F8551 for ; Wed, 19 Sep 2012 12:10:37 -0700 (PDT) Received: from mail130-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Sep 2012 19:10:37 +0000 Received: from mail130-va3 (localhost [127.0.0.1]) by mail130-va3-R.bigfish.com (Postfix) with ESMTP id 10547A02CA; Wed, 19 Sep 2012 19:10:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.43; KIP:(null); UIP:(null); IPV:NLI; H:CIO-KRC-HT03.osuad.osu.edu; RD:cio-krc-ht03.osuad.osu.edu; EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zzbb2dI98dI9371Izz1202h1d1ah1d2ahzz8275bhz2fh87h2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail130-va3: domain of osu.edu designates 164.107.81.43 as permitted sender) client-ip=164.107.81.43; envelope-from=cantor.2@osu.edu; helo=CIO-KRC-HT03.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail130-va3 (localhost.localdomain [127.0.0.1]) by mail130-va3 (MessageSwitch) id 1348081836121036_24822; Wed, 19 Sep 2012 19:10:36 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.246]) by mail130-va3.bigfish.com (Postfix) with ESMTP id 0A348380071; Wed, 19 Sep 2012 19:10:36 +0000 (UTC) Received: from CIO-KRC-HT03.osuad.osu.edu (164.107.81.43) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Sep 2012 19:10:32 +0000 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, 19 Sep 2012 15:10:31 -0400 From: "Cantor, Scott" To: William Mills , Nico Williams Thread-Topic: [kitten] Google and SASL OAuth Thread-Index: AQHNlepDvUDtSOgX70WW0RrYcbNMvJeQuHuAgAEdFHqAAEVTAIAACpkAgAAPRgCAAAc7gP//wdiAgABIT4D//8AsAIAARUYA//+9cYA= Date: Wed, 19 Sep 2012 19:10:31 +0000 Message-ID: In-Reply-To: <1348081720.8612.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: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <74931552A29FDD41A2DC714EEF3D62D2@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 19:10:38 -0000 On 9/19/12 3:08 PM, "William Mills" wrote: >So have we danced around the floor again to the point where the >gs2-header authzid can be used for this purpose and some services may >require the client applications to send authz-id? I think we're still dancing, but it's probably a judgement call by the folks more in tune with the trade-offs. My ill-informed opinion is as you state. -- Scott From nico@cryptonector.com Wed Sep 19 13:18: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 19A8A21E8034 for ; Wed, 19 Sep 2012 13:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=-0.110, 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 aueyUadEvcRJ for ; Wed, 19 Sep 2012 13:18:25 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 861A421F84C9 for ; Wed, 19 Sep 2012 13:18:25 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 257B92F406A for ; Wed, 19 Sep 2012 13:18: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=T2q4VfM1sCbiRepTm1YS exhDD64=; b=eqKFfFiCEbSky9z7RS9/y1gg4xfQUd5kAcF5PzGC99B/EDYL+tUq as42YGXOC9z7xFnkN5JKjcLmmSL+YOJmWLuhf4j2jZusy5iSjss0HDsO5yZZKn7n ZBJNmkaCcNHnY1UrHZ36jhqzuMOqDVZ5+wBT4s2H0YZgA/Zd/HgSDso= 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 0B0362F4060 for ; Wed, 19 Sep 2012 13:18:25 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so980011pbb.31 for ; Wed, 19 Sep 2012 13:18:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr817831pbc.149.1348085904648; Wed, 19 Sep 2012 13:18:24 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 13:18:24 -0700 (PDT) In-Reply-To: References: <1348080493.34585.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 15:18:24 -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] Google and 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: Wed, 19 Sep 2012 20:18:26 -0000 On Wed, Sep 19, 2012 at 1:51 PM, Nico Williams wrote: >> Yes, and the stated goal is that the hint is provided and used before the >> token is validated. > > SASL does not allow that. You see bits on the wire and you think > "hey, the bits I need are right there, so let's grab them", but the > frameworks involved make these bits opaque to you. You don't have to > use an implementation of the framework, but you must not preclude > someone who chooses to do so from implementing the same functionality. I should say that if we were willing to obsolete all non-GS2 SASL mechanisms and declare that all future SASL mechanisms must be GS2 mechanisms, *then* it'd be fair to make use of the gs2 header before processing the rest of the mechanism's message(s) with the caveat that the gs2-header is not authenticated until the other messages are processed. However, that'd be asking a lot :/ From simon@josefsson.org Wed Sep 19 14:04: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 4CCBC21E8034 for ; Wed, 19 Sep 2012 14:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.852 X-Spam-Level: X-Spam-Status: No, score=-99.852 tagged_above=-999 required=5 tests=[AWL=0.057, 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 Po9PwbQDDKC8 for ; Wed, 19 Sep 2012 14:04:01 -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 765C321F8510 for ; Wed, 19 Sep 2012 14:04:00 -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 q8JL3jLa016228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Sep 2012 23:03:47 +0200 From: Simon Josefsson To: Nico Williams References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120919:kitten@ietf.org::a5mF73sMdHvsI4El:w1P X-Hashcash: 1:22:120919:nico@cryptonector.com::vwqQDOC2jAGQ6DmD:45Bu X-Hashcash: 1:22:120919:rtroll@googlers.com::4L1zaizmJd9mrzce:Ljnz X-Hashcash: 1:22:120919:ve7jtb@ve7jtb.com::xxZYPctXpl2l6uTP:0Jk0V Date: Wed, 19 Sep 2012 23:03:44 +0200 In-Reply-To: (Nico Williams's message of "Wed, 19 Sep 2012 13:12:51 -0500") Message-ID: <87y5k5d8sv.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] Google and 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: Wed, 19 Sep 2012 21:04:02 -0000 Nico Williams writes: > On Wed, Sep 19, 2012 at 12:46 PM, Ryan Troll wrote: >> As a result, I believe you're right - and my previous statement was >> incorrect - the hint should identify what the request is trying to access. >> (This has been doubly confusing, as in my immediate use case, these two >> values are the same.) > > Right, that's the source of the confusion. Thanks Ryan for explaining another time. I'm now in agreement that the routing hint you want is effectively the authorization identity. > The right thing to do is to say that the IMAP server uses the authz-id > *if provided* as the resource name, else it *derives* one from the > authcid. Agreed. Alas, I believe Ryan is saying (fairly strongly) that this wouldn't work for him though, as he cannot derive the authzid from the authcid since the server end point needs to be routed (authzid-vice) to the right machine before it is able to infer anything from the authcid. /Simon From nico@cryptonector.com Wed Sep 19 14:04: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 8B2E221E80A8 for ; Wed, 19 Sep 2012 14:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 SkqDcH8LBaYK for ; Wed, 19 Sep 2012 14:04:12 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 0A37D21F8514 for ; Wed, 19 Sep 2012 14:04:12 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id B6538286078 for ; Wed, 19 Sep 2012 14:04:11 -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=4kxfTRlJQlI6pBAWCvZW chzah40=; b=G06gHGOFSiBACWlIbZKxIVyeUak5Hted3+/snPOUgYifBQbXHkWl Y3TwWaI/gt0NNiKaGBxHlGIwaG/af+vqkCW4vWV5fItL0Hlf3okvGakyTJOQ9fKM uDhYQ6qz6BtRW2XKYiPJQ9T1rT9IQ74vvzPehcCeCZGhC3AYJO/RNkk= 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-a97.g.dreamhost.com (Postfix) with ESMTPSA id 90524286057 for ; Wed, 19 Sep 2012 14:04:11 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1057471pbb.31 for ; Wed, 19 Sep 2012 14:04:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.73 with SMTP id ra9mr1218615pbc.85.1348088651274; Wed, 19 Sep 2012 14:04:11 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 14:04:11 -0700 (PDT) In-Reply-To: References: <1348080493.34585.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 16:04:11 -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] Google and 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: Wed, 19 Sep 2012 21:04:13 -0000 On Wed, Sep 19, 2012 at 3:18 PM, Nico Williams wrote: > On Wed, Sep 19, 2012 at 1:51 PM, Nico Williams wrote: >>> Yes, and the stated goal is that the hint is provided and used before the >>> token is validated. >> >> SASL does not allow that. You see bits on the wire and you think >> "hey, the bits I need are right there, so let's grab them", but the >> frameworks involved make these bits opaque to you. You don't have to >> use an implementation of the framework, but you must not preclude >> someone who chooses to do so from implementing the same functionality. > > I should say that if we were willing to obsolete all non-GS2 SASL > mechanisms and declare that all future SASL mechanisms must be GS2 > mechanisms, *then* it'd be fair to make use of the gs2 header before > processing the rest of the mechanism's message(s) with the caveat that > the gs2-header is not authenticated until the other messages are > processed. I should further say that the idea of using an authz-id prior to its being authenticated makes me very nervous. It's one thing if it helps begin slow I/Os, but you have to be very careful not to leak existential information to clients with invalid credentials. > However, that'd be asking a lot :/ From nico@cryptonector.com Wed Sep 19 14:10: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 36D5721F853B for ; Wed, 19 Sep 2012 14:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=-0.104, 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 zGXez+5oeE+f for ; Wed, 19 Sep 2012 14:10:57 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7E821F853A for ; Wed, 19 Sep 2012 14:10:57 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 0295342807C for ; Wed, 19 Sep 2012 14:10: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=sTKJiTmOyLXSAe1G0ZPP K7GT5js=; b=nUTWA/A7MLvIFPn3IFV/HXYTCFrEZSZVMAC21Ok8v/wJuOuydc75 T2b4N4zzeSK+b1UEe+qfALbyqKWF0kAoCceT4egZw3TVJqOhKYPKDADc4PFPLFGQ 3DK9ldqNkEJ23Tk8DfB3gm+FK2aUA4aHigR+B+c6XG/C/xecmdEP+ks= 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 C99BB42806E for ; Wed, 19 Sep 2012 14:10:56 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1069058pbb.31 for ; Wed, 19 Sep 2012 14:10:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.73 with SMTP id ra9mr1252072pbc.85.1348089056388; Wed, 19 Sep 2012 14:10:56 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 14:10:56 -0700 (PDT) In-Reply-To: <87y5k5d8sv.fsf@latte.josefsson.org> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 16:10:56 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 21:10:58 -0000 On Wed, Sep 19, 2012 at 4:03 PM, Simon Josefsson wrote: >> The right thing to do is to say that the IMAP server uses the authz-id >> *if provided* as the resource name, else it *derives* one from the >> authcid. > > Agreed. Alas, I believe Ryan is saying (fairly strongly) that this > wouldn't work for him though, as he cannot derive the authzid from the > authcid since the server end point needs to be routed (authzid-vice) to > the right machine before it is able to infer anything from the authcid. Hmm. If you only use SASL mechanisms that bear an authz-id in the first client authentication message and where the client can extract that immediately, then it could be done. It'd not be strictly SASL, but it'd work. I'd recommend that the "router" also be the node terminating SASL, then the authz-id can always be available before having to know where to route the application layer messages. Now, perhaps Ryan has *two* routing problems: a) how to route the processing of SASL authentication messages, b) how to route post-authentication application messages. If we think of these as two distinct routing tasks (even if the routing outcome is always the same for (a) and (b)) then we can say that the routing should be done as follows: - make the SASL server framework implementation used by the router be a proxy such that the mechanism uses whatever information is available/appropriate to route the processing of the SASL authentication messages; - post-authentication let the router use the authz-id (or authcid) to route the application messages. Nico -- From simon@josefsson.org Wed Sep 19 14:22: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 2E40C21E8064 for ; Wed, 19 Sep 2012 14:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.855 X-Spam-Level: X-Spam-Status: No, score=-99.855 tagged_above=-999 required=5 tests=[AWL=0.054, 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 JT196lowOnKt for ; Wed, 19 Sep 2012 14:22:23 -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 5B4D321E8042 for ; Wed, 19 Sep 2012 14:22: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 q8JLM6OY017194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Sep 2012 23:22:08 +0200 From: Simon Josefsson To: Nico Williams References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120919:nico@cryptonector.com::0qLAqkB62u/5Affx:4AIZ X-Hashcash: 1:22:120919:ve7jtb@ve7jtb.com::gEFphZacg09Uryri:FtcD X-Hashcash: 1:22:120919:kitten@ietf.org::uORoHyMohNxOLBX1:UG+h X-Hashcash: 1:22:120919:rtroll@googlers.com::XZTlc2ZjpZfCT7Cg:XXzQ Date: Wed, 19 Sep 2012 23:22:05 +0200 In-Reply-To: (Nico Williams's message of "Wed, 19 Sep 2012 16:10:56 -0500") Message-ID: <87mx0ld7ya.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] Google and 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: Wed, 19 Sep 2012 21:22:24 -0000 Nico Williams writes: > On Wed, Sep 19, 2012 at 4:03 PM, Simon Josefsson wrote: >>> The right thing to do is to say that the IMAP server uses the authz-id >>> *if provided* as the resource name, else it *derives* one from the >>> authcid. >> >> Agreed. Alas, I believe Ryan is saying (fairly strongly) that this >> wouldn't work for him though, as he cannot derive the authzid from the >> authcid since the server end point needs to be routed (authzid-vice) to >> the right machine before it is able to infer anything from the authcid. > > Hmm. If you only use SASL mechanisms that bear an authz-id in the > first client authentication message and where the client can extract > that immediately, then it could be done. It'd not be strictly SASL, > but it'd work. This would essentially be achieved by having service provider specific documents saying "you must send an authzid", right? This could indeed work in practice, but it feels like sacrifying part of the SASL design and will require work for MUA implementers (few implementations expose a authzid field to the user today), service providers (they need to document this and explain how to configure popular clients) and for users (read the documentation and configure their clients with an authzid). > I'd recommend that the "router" also be the node terminating SASL, > then the authz-id can always be available before having to know where > to route the application layer messages. Yes, this seems like a better model to me. > Now, perhaps Ryan has *two* routing problems: a) how to route the > processing of SASL authentication messages, b) how to route > post-authentication application messages. If we think of these as two > distinct routing tasks (even if the routing outcome is always the same > for (a) and (b)) then we can say that the routing should be done as > follows: > > - make the SASL server framework implementation used by > the router be a proxy such that the mechanism uses > whatever information is available/appropriate to route the > processing of the SASL authentication messages; > > - post-authentication let the router use the authz-id (or authcid) > to route the application messages. Yes. /Simon From cantor.2@osu.edu Wed Sep 19 14:33: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 99F3E21E80AB for ; Wed, 19 Sep 2012 14:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.772 X-Spam-Level: X-Spam-Status: No, score=-3.772 tagged_above=-999 required=5 tests=[AWL=-0.173, 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 pLpSfg-i6Wxi for ; Wed, 19 Sep 2012 14:33:26 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 07CE021E80A4 for ; Wed, 19 Sep 2012 14:33:25 -0700 (PDT) Received: from mail167-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Sep 2012 21:33:25 +0000 Received: from mail167-co1 (localhost [127.0.0.1]) by mail167-co1-R.bigfish.com (Postfix) with ESMTP id 773CB580076; Wed, 19 Sep 2012 21:33:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.43; KIP:(null); UIP:(null); IPV:NLI; H:CIO-KRC-HT03.osuad.osu.edu; RD:cio-krc-ht03.osuad.osu.edu; EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zzbb2dI98dI9371I1432Id6f1izz1202h1d1ah1d2ahzz8275dhz2fh87h2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail167-co1: domain of osu.edu designates 164.107.81.43 as permitted sender) client-ip=164.107.81.43; envelope-from=cantor.2@osu.edu; helo=CIO-KRC-HT03.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail167-co1 (localhost.localdomain [127.0.0.1]) by mail167-co1 (MessageSwitch) id 1348090403116689_4007; Wed, 19 Sep 2012 21:33:23 +0000 (UTC) Received: from CO1EHSMHS010.bigfish.com (unknown [10.243.78.249]) by mail167-co1.bigfish.com (Postfix) with ESMTP id 1A7EB5C0049; Wed, 19 Sep 2012 21:33:23 +0000 (UTC) Received: from CIO-KRC-HT03.osuad.osu.edu (164.107.81.43) by CO1EHSMHS010.bigfish.com (10.243.66.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Sep 2012 21:33:22 +0000 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, 19 Sep 2012 17:33:20 -0400 From: "Cantor, Scott" To: Simon Josefsson , Nico Williams Thread-Topic: [kitten] Google and SASL OAuth Thread-Index: AQHNlqzRvUDtSOgX70WW0RrYcbNMvJeSL2oA Date: Wed, 19 Sep 2012 21:33:20 +0000 Message-ID: In-Reply-To: <87mx0ld7ya.fsf@latte.josefsson.org> 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-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 21:33:26 -0000 On 9/19/12 5:22 PM, "Simon Josefsson" wrote: > >This would essentially be achieved by having service provider specific >documents saying "you must send an authzid", right? This could indeed >work in practice, but it feels like sacrifying part of the SASL design >and will require work for MUA implementers (few implementations expose a >authzid field to the user today), service providers (they need to >document this and explain how to configure popular clients) and for >users (read the documentation and configure their clients with an >authzid). This was what I was really trying to ask, and I guess I didn't make it clear. I had thought the default client behavior was in fact to populate authz-id based on the usual "username" field in the client. If that's not so, I'd say that's a major issue for what's being proposed. The mechanism can't do anything about this because it's sitting inside the GS2 layer unable to control what goes in that header, even if it wanted to. So the two options seem to be: - bite the bullet and add something mech-specific that also involves the server side code not using standard SASL bits and groveling through mech bits to find the hint - not trying to do this and terminating the SASL at the front-end and routing app traffic afterward Even if semantically authzid is ok as a fit, the reality of clients is going to trump pretty much everything else I would think. -- Scott From rtroll@google.com Wed Sep 19 14: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 8F0EE21E80AD for ; Wed, 19 Sep 2012 14:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.883 X-Spam-Level: X-Spam-Status: No, score=-102.883 tagged_above=-999 required=5 tests=[AWL=0.093, 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 1+6mFTjgEF8y for ; Wed, 19 Sep 2012 14:39:01 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B19F321E8034 for ; Wed, 19 Sep 2012 14:39:01 -0700 (PDT) Received: by iec9 with SMTP id 9so2607440iec.31 for ; Wed, 19 Sep 2012 14:39:01 -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=3iPDz3VqjcXCRIhnQ/tgc/dfcLr0up2O4qO5XFA23I8=; b=IGFkb3S5sZUMZbnt+PCAT23NPYZOuYER6ibDVqCIoOlWcV772l9yeF+fGvfKlMk5Nx ML4GZ3hLInEw6+ZlSnrLzGD7D6DQXsomq2UCnB7lvuP0AkzeH16YJyTXhqKZHiYq+kFM QTdpoVfglPmmukru8h+qu7cM0GboReHKTtBxc= 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=3iPDz3VqjcXCRIhnQ/tgc/dfcLr0up2O4qO5XFA23I8=; b=bEz+X57xFAxUmK8bynOPNiXDMJ6/kYg72nInR0Drp1cstiuguBKBd/XvrbmdXRKJav be95Tywk+GqQyIzZDovt0OdeiFSLb1HycTXGhr3nAdHdUXi5BJEVxhZbqaRbMUTaqOeb G/f/TC2kuPCIFzcgoxXeYbVlZW8+6KrFzkubWppiD9fI92u4GlIgzFN8cmoAJMrfyzlZ mOFjhGx/i9JH/9R1q9d7GQ3bKUi5wxR53iqM/S94drp9NKRVWkB1ti6ZOz8VT0iRIuli k7K6v83PFI9OCGQk4g6Mb3d8OYi9eB9xrd1nsK0urbVFJoP2Llz7tP7y3Xy5Jv9wCS1W 3zmg== Received: by 10.43.9.3 with SMTP id ou3mr3538358icb.14.1348090741114; Wed, 19 Sep 2012 14:39:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.9.3 with SMTP id ou3mr3538337icb.14.1348090740919; Wed, 19 Sep 2012 14:39:00 -0700 (PDT) Received: by 10.50.36.131 with HTTP; Wed, 19 Sep 2012 14:39:00 -0700 (PDT) In-Reply-To: <87mx0ld7ya.fsf@latte.josefsson.org> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 14:39:00 -0700 Message-ID: From: Ryan Troll To: Simon Josefsson Content-Type: multipart/alternative; boundary=bcaec50fe0adbccd8704ca14d5f0 X-System-Of-Record: true X-Gm-Message-State: ALoCoQngEnB7YJBd4e0mQV6yISfyfa3YmX0XdhA3O/vDLaWT/BaVNtQmA1ALzMGz4cB27dTXJIFAy1W4mpMzD+MKPgVEmz7Nu/RcrktxZPR4tP8YztoPiqjltCcAmP9rV6eK9kINFiLxwCYWHpW2Mf/uaVhlR9KU0pM46umUtjKwXOPii5BPotio/Rzy9QdX1cUOJeKpS0my Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 21:39:02 -0000 --bcaec50fe0adbccd8704ca14d5f0 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 19, 2012 at 2:22 PM, Simon Josefsson wrote: > This would essentially be achieved by having service provider specific > documents saying "you must send an authzid", right? This could indeed > work in practice, but it feels like sacrifying part of the SASL design > and will require work for MUA implementers (few implementations expose a > authzid field to the user today), service providers (they need to > document this and explain how to configure popular clients) and for > users (read the documentation and configure their clients with an > authzid). > This is all true, but I don't think this change is significant in the face of the changes required to support OAuth. An MUA that wants to incorporate OAuth support already has to rip out the entire name/password concept, and replace it with something new. This something new is likely a page that says "Enter the email account you'd like to add". Upon entering a gmail/yahoo/hotmail/whomever account, the client will bring up a browser window, pointing at that domain's OAuth endpoint, allowing the user to traverse the OAuth flow, acquiring an OAuth credential. The browser closes, and the client connects via IMAP, sending the OAuth credential in the SASL negotiation. Granted, this example is a potential future (I'm assuming automatic discovery of SMTP, IMAP, and OAuth endpoints) - but it demonstrates how much the "Add An Account" flow will change to include OAuth. I'm not sure the addition of authz in the SASL negotiation has any significant impact on the the MUA implementer, compared to getting the OAuth credential in the first place. And the User should not see any difference. -R --bcaec50fe0adbccd8704ca14d5f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Sep 19, 2012 at 2:22 PM, Simon J= osefsson <simon@josefsson.org> wrote:
This would essentially be achieved by having service provi= der specific
documents saying "you must send an authzid", right? =A0This could= indeed
work in practice, but it feels like sacrifying part of the SASL design
and will require work for MUA implementers (few implementations expose a authzid field to the user today), service providers (they need to
document this and explain how to configure popular clients) and for
users (read the documentation and configure their clients with an
authzid).

This is all true,= but I don't think this change is significant in the face of the change= s required to support OAuth.

An MUA that wants to = incorporate OAuth support already has to rip out the entire name/password c= oncept, and replace it with something new. =A0This something new is likely = a page that says "Enter the email account you'd like to add".= =A0Upon entering a gmail/yahoo/hotmail/whomever account, the client will b= ring up a browser window, pointing at that domain's OAuth endpoint, all= owing the user to traverse the OAuth flow, acquiring an OAuth credential. = =A0The browser closes, and the client connects via IMAP, sending the OAuth = credential in the SASL negotiation.

Granted, this example is a potential future (I'm as= suming automatic discovery of SMTP, IMAP, and OAuth endpoints) - but it dem= onstrates how much the "Add An Account" flow will change to inclu= de OAuth. =A0I'm not sure the addition of authz in the SASL negotiation= has any significant impact on the the MUA=A0implementer, compared to getti= ng the OAuth credential in the first place. =A0And the User should not see = any difference.

-R
--bcaec50fe0adbccd8704ca14d5f0-- From wmills@yahoo-inc.com Wed Sep 19 14:44: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 E639C21E80AD for ; Wed, 19 Sep 2012 14:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.481 X-Spam-Level: X-Spam-Status: No, score=-17.481 tagged_above=-999 required=5 tests=[AWL=0.117, 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 nKkBEhQWCyBu for ; Wed, 19 Sep 2012 14:44:22 -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 SMTP id E537A21E803C for ; Wed, 19 Sep 2012 14:44:21 -0700 (PDT) Received: from [98.139.52.191] by nm25.bullet.mail.ac4.yahoo.com with NNFMP; 19 Sep 2012 21:44:17 -0000 Received: from [98.139.52.171] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 19 Sep 2012 21:44:17 -0000 Received: from [127.0.0.1] by omp1054.mail.ac4.yahoo.com with NNFMP; 19 Sep 2012 21:44:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 285800.79159.bm@omp1054.mail.ac4.yahoo.com Received: (qmail 84980 invoked by uid 60001); 19 Sep 2012 21:44:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348091056; bh=1ChqVkhcQE4HgBqtQ8RvmNbMhpj3uYD9kwBW4b5Fay8=; 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=RVpGU19u0layCRCz1fEqWG1ilnB8IgZifYLEdodesKA1q6GQWdP5I4fTVqEVMJRBp8zrfDwtNWU1S0a7RTqIJQoToXeqGpc/O9weumvthWVzO2PxGia7LomXCB26kHx4HZWSrRWyNKUZwohHi6cL3V5AuGOGO2G8WkN0h8F2F+A= 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=WU1uyA1UBnPD+GHCCYuEmL4KpiqZlZnKmoIw2/yGFng07wdsIt9aPYEnfelHn92ScA4WQCpnYPRBMpSznDWVGDAqrCRAHCGDk8GjLw/47IbYalEMZ436Ma9uis/b1eYC6ssaXWzTQ8DltP3+cMjiRV7xQ1FJwQjMQ/at2yRi/OE=; X-YMail-OSG: 8XzmyokVM1moeaEFMjyw4j7wyPL1jcgVxatdRbHaPNk6Pvh MMj10s.QHM1M6v4aQHx37_z9nIlruviNgJm.cqmdGUx4LNk.xsL._pu3NUr7 HmmxTsVvl2uaZHUichONWeiwYBv4CIOmIxGj4vkGnmvbOA88exgwXDbKwyCp 07QWxW3MDKXpeYpRfsYl.roMBmSL9_tyL9PYPJupoB8uJELWOLGkvat8YFMy f9asSudK1eUz7SSXMpq0Cq0GxR2krQ5h5gAI73n7yNcu27ctOX.Q_t7HVDr9 vBGw4tV0UD9kDsX3VF5Ov_lMv6_xOoGvYpZxP5KmsX9psvXl6NNdeFhWCMwA _x.rTK_zjKkNRhXgXKD8sfBXTj8bWsgMooWe1Nq7VHE56E1riN2S4OlEjdvt e9PBvNaA3zKo1xNVpkCp3ZGnmtuOvHRraQLskeTptKjYxazeMRKrVFCRMJSb ohBLSNA-- Received: from [209.131.62.113] by web31802.mail.mud.yahoo.com via HTTP; Wed, 19 Sep 2012 14:44:16 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> Message-ID: <1348091056.83284.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 14:44:16 -0700 (PDT) From: William Mills To: Ryan Troll , Simon Josefsson In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-1403715793-1348091056=:83284" Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 21:44:23 -0000 ---1036955950-1403715793-1348091056=:83284 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable +1=0A=0A=0A=0A=0A>________________________________=0A> From: Ryan Troll =0A>To: Simon Josefsson =0A>Cc: "ki= tten@ietf.org" =0A>Sent: Wednesday, September 19, 2012 2:= 39 PM=0A>Subject: Re: [kitten] Google and SASL OAuth=0A> =0A>=0A>=0A>=0A>= =0A>On Wed, Sep 19, 2012 at 2:22 PM, Simon Josefsson = wrote:=0A>=0A>This would essentially be achieved by having service provider= specific=0A>>documents saying "you must send an authzid", right? =A0This c= ould indeed=0A>>work in practice, but it feels like sacrifying part of the = SASL design=0A>>and will require work for MUA implementers (few implementat= ions expose a=0A>>authzid field to the user today), service providers (they= need to=0A>>document this and explain how to configure popular clients) an= d for=0A>>users (read the documentation and configure their clients with an= =0A>>authzid).=0A>>=0A>=0A>This is all true, but I don't think this change = is significant in the face of the changes required to support OAuth.=0A>=0A= >=0A>An MUA that wants to incorporate OAuth support already has to rip out = the entire name/password concept, and replace it with something new. =A0Thi= s something new is likely a page that says "Enter the email account you'd l= ike to add". =A0Upon entering a gmail/yahoo/hotmail/whomever account, the c= lient will bring up a browser window, pointing at that domain's OAuth endpo= int, allowing the user to traverse the OAuth flow, acquiring an OAuth crede= ntial. =A0The browser closes, and the client connects via IMAP, sending the= OAuth credential in the SASL negotiation.=0A>=0A>=0A>Granted, this example= is a potential future (I'm assuming automatic discovery of SMTP, IMAP, and= OAuth endpoints) - but it demonstrates how much the "Add An Account" flow = will change to include OAuth. =A0I'm not sure the addition of authz in the = SASL negotiation has any significant impact on the the MUA=A0implementer, c= ompared to getting the OAuth credential in the first place. =A0And the User= should not see any difference.=0A>=0A>=0A>-R=0A>__________________________= _____________________=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://= www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> ---1036955950-1403715793-1348091056=:83284 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
+1

<= div style=3D"font-family: Courier New, courier, monaco, monospace, sans-ser= if; font-size: 14pt;">
From: Ryan Troll <rtroll@googlers.com>
To: Simon Josefsson <simon@josefsson.org> Cc: "kitten@ietf.org" <= ;kitten@ietf.org>
Sent: Wednesday, September 19, 2012 2:39 PM
Subject: Re: [kitten] Google and SASL OAuth
 =



On Wed, Sep 19, 2012 at 2:22 PM, Simon Josefsson = <simon@josefsson.org> wrote:
=0A
This would = essentially be achieved by having service provider specific
=0Adocuments= saying "you must send an authzid", right?  This could indeed
=0Awo= rk in practice, but it feels like sacrifying part of the SASL design
=0A= and will require work for MUA implementers (few implementations expose a=0Aauthzid field to the user today), service providers (they need to
= =0Adocument this and explain how to configure popular clients) and for
= =0Ausers (read the documentation and configure their clients with an
=0A= authzid).
=0A

This is all true, but I don't think this change is significant i= n the face of the changes required to support OAuth.

An MUA that wants to incorporate OAuth support already has to rip out th= e entire name/password concept, and replace it with something new.  Th= is something new is likely a page that says "Enter the email account you'd = like to add".  Upon entering a gmail/yahoo/hotmail/whomever account, t= he client will bring up a browser window, pointing at that domain's OAuth e= ndpoint, allowing the user to traverse the OAuth flow, acquiring an OAuth c= redential.  The browser closes, and the client connects via IMAP, send= ing the OAuth credential in the SASL negotiation.
=0A

Granted, this example is a potential future (I'm assuming automatic disc= overy of SMTP, IMAP, and OAuth endpoints) - but it demonstrates how much th= e "Add An Account" flow will change to include OAuth.  I'm not sure th= e addition of authz in the SASL negotiation has any significant impact on t= he the MUA implementer, compared to getting the OAuth credential in th= e first place.  And the User should not see any difference.
=0A
-R
=0A

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


= ---1036955950-1403715793-1348091056=:83284-- From simon@josefsson.org Wed Sep 19 14:46: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 34C5621F84FA for ; Wed, 19 Sep 2012 14:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.857 X-Spam-Level: X-Spam-Status: No, score=-99.857 tagged_above=-999 required=5 tests=[AWL=0.052, 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 LrqgKg1unPvi for ; Wed, 19 Sep 2012 14:46:25 -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 6316121F84F9 for ; Wed, 19 Sep 2012 14:46:24 -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 q8JLkHVA018336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Sep 2012 23:46:18 +0200 From: Simon Josefsson To: "Cantor\, Scott" References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120919:cantor.2@osu.edu::iFbX1I/JBDXbvb+Q:4NZ3 X-Hashcash: 1:22:120919:kitten@ietf.org::mI4BjGotSWKNb81+:9y8D X-Hashcash: 1:22:120919:nico@cryptonector.com::GcCKd6DFIJ/qRa98:9RSX Date: Wed, 19 Sep 2012 23:46:16 +0200 In-Reply-To: (Scott Cantor's message of "Wed, 19 Sep 2012 21:33:20 +0000") Message-ID: <876279ofdj.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] Google and 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: Wed, 19 Sep 2012 21:46:26 -0000 "Cantor, Scott" writes: > On 9/19/12 5:22 PM, "Simon Josefsson" wrote: >> >>This would essentially be achieved by having service provider specific >>documents saying "you must send an authzid", right? This could indeed >>work in practice, but it feels like sacrifying part of the SASL design >>and will require work for MUA implementers (few implementations expose a >>authzid field to the user today), service providers (they need to >>document this and explain how to configure popular clients) and for >>users (read the documentation and configure their clients with an >>authzid). > > This was what I was really trying to ask, and I guess I didn't make it > clear. I had thought the default client behavior was in fact to populate > authz-id based on the usual "username" field in the client. No, the authzid is typically left empty/absent by common IMAP/SMTP/XMPP clients aimed at end-users. Powertools for admins may have the ability to specify an authzid, to be able to impersonate another user, although I have rarely seen this used for anything but debugging or testing. This is my experience at least. I looked at Evolution, a popular MUA on GNU systems, and there is no authzid field that I can see, just one field for "Username" which translates to the authcid that is transfered by PLAIN/CRAM-MD5/etc. > If that's not so, I'd say that's a major issue for what's being > proposed. The mechanism can't do anything about this because it's > sitting inside the GS2 layer unable to control what goes in that > header, even if it wanted to. > > So the two options seem to be: > > - bite the bullet and add something mech-specific that also involves the > server side code not using standard SASL bits and groveling through mech > bits to find the hint > > - not trying to do this and terminating the SASL at the front-end and > routing app traffic afterward > > Even if semantically authzid is ok as a fit, the reality of clients is > going to trump pretty much everything else I would think. I agree. /Simon From nico@cryptonector.com Wed Sep 19 14:49: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 DB76621E80AD for ; Wed, 19 Sep 2012 14:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=-0.101, 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 ydpHZGCjxf1C for ; Wed, 19 Sep 2012 14:49:02 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 26ACA21E8050 for ; Wed, 19 Sep 2012 14:49:02 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id A21252C807A for ; Wed, 19 Sep 2012 14:49: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=/ay0AOxbv1Z4wGqo6vCU iYTQMU8=; b=vDpGtCxqgFg84+PaQ2yoZ0scM5bWd11OaNqDdozpNq2ew6Onuoos ykFgcPLNJvlBRIiQJzeS2dELuvLLo8SYP/EJKWkDNuzN7hA87uWMB3hRgzcZjr07 WQdUmCJPHYuT5XJDhdSXenZRDx2Cby6+XF7tRPB+ibZACeD8cLaeWio= 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 83CC12C806E for ; Wed, 19 Sep 2012 14:49:01 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1129584pbb.31 for ; Wed, 19 Sep 2012 14:49:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.236.69 with SMTP id us5mr1486430pbc.59.1348091341119; Wed, 19 Sep 2012 14:49:01 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 14:49:01 -0700 (PDT) In-Reply-To: References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 16:49:01 -0500 Message-ID: From: Nico Williams To: Ryan Troll Content-Type: text/plain; charset=UTF-8 Cc: Simon Josefsson , "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 21:49:04 -0000 On Wed, Sep 19, 2012 at 4:39 PM, Ryan Troll wrote: > On Wed, Sep 19, 2012 at 2:22 PM, Simon Josefsson > wrote: >> This would essentially be achieved by having service provider specific >> documents saying "you must send an authzid", right? This could indeed >> work in practice, but it feels like sacrifying part of the SASL design >> and will require work for MUA implementers (few implementations expose a >> authzid field to the user today), service providers (they need to >> document this and explain how to configure popular clients) and for >> users (read the documentation and configure their clients with an >> authzid). > > This is all true, but I don't think this change is significant in the face > of the changes required to support OAuth. > > An MUA that wants to incorporate OAuth support already has to rip out the > entire name/password concept, and replace it with something new. This Actually, this is true in general. OAuth is hardly the only mechanism for which a name & password in a dialog is not appropriate. Kerberos has the same problem, for example (e.g., if the user is using PKINIT or OTPs). > something new is likely a page that says "Enter the email account you'd like > to add". Upon entering a gmail/yahoo/hotmail/whomever account, the client > will bring up a browser window, pointing at that domain's OAuth endpoint, > allowing the user to traverse the OAuth flow, acquiring an OAuth credential. Well, whether it's a browser or something else, the point is that what happens here is mechanism-specific. (Though I am of the mind that all user interaction for acquiring "cooked" credentials should be done via a "trusted"captive/embedded browser using XHR to talk to the mechanisms via trusted channels. In that case all interaction would be via a browser indeed.) Back to the routing problem though, does thinking of it as being two routing problems help? (see earlier post) Nico -- From simon@josefsson.org Wed Sep 19 14:52: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 CED4221F845E for ; Wed, 19 Sep 2012 14:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.859 X-Spam-Level: X-Spam-Status: No, score=-99.859 tagged_above=-999 required=5 tests=[AWL=0.050, 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 g1I1Zvsg5+mf for ; Wed, 19 Sep 2012 14:52: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 DDBAE21F8452 for ; Wed, 19 Sep 2012 14:52:19 -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 q8JLqA7l018561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Sep 2012 23:52:11 +0200 From: Simon Josefsson To: Ryan Troll References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120919:rtroll@googlers.com::OAAmkyewzViud/Vq:3fVl X-Hashcash: 1:22:120919:kitten@ietf.org::z9Xc+jis7UR87P+y:5Hik X-Hashcash: 1:22:120919:nico@cryptonector.com::hsf2H+U9p8sn4eQY:8pFg X-Hashcash: 1:22:120919:ve7jtb@ve7jtb.com::G5LqSWZZfzD374Nv:UbGg Date: Wed, 19 Sep 2012 23:52:09 +0200 In-Reply-To: (Ryan Troll's message of "Wed, 19 Sep 2012 14:39:00 -0700") Message-ID: <871uhxof3q.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] Google and 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: Wed, 19 Sep 2012 21:52:20 -0000 Ryan Troll writes: > On Wed, Sep 19, 2012 at 2:22 PM, Simon Josefsson wrote: > >> This would essentially be achieved by having service provider specific >> documents saying "you must send an authzid", right? This could indeed >> work in practice, but it feels like sacrifying part of the SASL design >> and will require work for MUA implementers (few implementations expose a >> authzid field to the user today), service providers (they need to >> document this and explain how to configure popular clients) and for >> users (read the documentation and configure their clients with an >> authzid). >> > > This is all true, but I don't think this change is significant in the face > of the changes required to support OAuth. > > An MUA that wants to incorporate OAuth support already has to rip out the > entire name/password concept, and replace it with something new. This > something new is likely a page that says "Enter the email account you'd > like to add". Upon entering a gmail/yahoo/hotmail/whomever account, the > client will bring up a browser window, pointing at that domain's OAuth > endpoint, allowing the user to traverse the OAuth flow, acquiring an OAuth > credential. The browser closes, and the client connects via IMAP, sending > the OAuth credential in the SASL negotiation. > > Granted, this example is a potential future (I'm assuming automatic > discovery of SMTP, IMAP, and OAuth endpoints) - but it demonstrates how > much the "Add An Account" flow will change to include OAuth. I'm not sure > the addition of authz in the SASL negotiation has any significant impact on > the the MUA implementer, compared to getting the OAuth credential in the > first place. And the User should not see any difference. I don't dispute any of this. However, I think you are ignoring the non-MUA world that may also want to use OAuth, and they are typically running generic GSS-API or SASL libraries that are modelled after the GSS-API and SASL designs. So by requiring the OAuth SASL mechanism to be treated specially, you are losing the advantages of using a plugin architecture where you can rely on some things behave the same regardless of mechanism used. Having a stable overall architecture is an advantage even to the MUA world in the long run. /Simon From rtroll@google.com Wed Sep 19 15:12: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 88F6B21F8516 for ; Wed, 19 Sep 2012 15:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.893 X-Spam-Level: X-Spam-Status: No, score=-102.893 tagged_above=-999 required=5 tests=[AWL=0.083, 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 8fS2s2fh0VuS for ; Wed, 19 Sep 2012 15:12:11 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABF5E21F8514 for ; Wed, 19 Sep 2012 15:12:07 -0700 (PDT) Received: by iec9 with SMTP id 9so2650509iec.31 for ; Wed, 19 Sep 2012 15:12:07 -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=n7ydWRDUHG+/t1rWOobVMOxutTU+UNDrkAn0K58/iIQ=; b=dGd6JH5oEbqQ74OToeVgB/H/rwKD9sArVTzIMSAHROZi6p2m0qXYDOtNkYoyT97sqB gf6srysBM+N/mreuUIiQ4fijpeKI/9vFUnhViGDXLnj2Y7oGvqUvn+MqnPa8NChM+mpA gBWPbibytdfHbOM3fn8WQvuFgwrrXuxmAGt7U= 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=n7ydWRDUHG+/t1rWOobVMOxutTU+UNDrkAn0K58/iIQ=; b=imDPenFQCz4CiNn516sKOJB4CSjyMYOoL2NhIc21qGbrrRABhYIUIEVY/wa8Rdc+Hl jEq9IFqwiYwACWWsCvRBZRmCdoSEI4afH5vPNekLaysWJjDL0dqJPsMX3JgOfQVQ+g+F dh59NYKw4dgApI2nzjJcOY9wRWE3AjZDvSiSqgFHQH04lHLTe1wGHCAnd4UXzAb449wE 8zjtKA9MUF0JzkA3Le8osyNAMr+po2VTker/3P4OsC4TwBIz2L9bcusNfeFdSFgo60Kw dFwNvpv+NiFsONe7VADjj3FwY5k70CJuQIoRORQ2fwQWAXMzaNGzfa88JEIqcozXfCgj Ckug== MIME-Version: 1.0 Received: by 10.50.157.201 with SMTP id wo9mr4017151igb.57.1348092727505; Wed, 19 Sep 2012 15:12:07 -0700 (PDT) Received: by 10.50.36.131 with HTTP; Wed, 19 Sep 2012 15:12:07 -0700 (PDT) In-Reply-To: <871uhxof3q.fsf@latte.josefsson.org> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <871uhxof3q.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 15:12:07 -0700 Message-ID: From: Ryan Troll To: Simon Josefsson Content-Type: multipart/alternative; boundary=e89a8f3ba97725b13f04ca154c7d X-System-Of-Record: true X-Gm-Message-State: ALoCoQmvd1GJftpcf2XtzUfhASNZyk4T992eX/LFgHmeYqlfhyEz4HRYpDPsYFTAdAwWI/4prv4PbIzDRbl/WlrrxSgFVirYv47xgL/YFlMoFk98qh0e6SnC5eAmHHVR3IXUCZx3/YMeWlvpkHcqcvoE9lRXBIxBXj5w2xzel6FT6LvTQkWIfeVIS95UvxsS2iLigIZ4IlGO Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 22:12:13 -0000 --e89a8f3ba97725b13f04ca154c7d Content-Type: text/plain; charset=ISO-8859-1 > I don't dispute any of this. However, I think you are ignoring the > non-MUA world that may also want to use OAuth, and they are typically > running generic GSS-API or SASL libraries that are modelled after the > GSS-API and SASL designs. So by requiring the OAuth SASL mechanism to > be treated specially, you are losing the advantages of using a plugin > architecture where you can rely on some things behave the same > regardless of mechanism used. Having a stable overall architecture is > an advantage even to the MUA world in the long run. > Very fair; you are right, I was focusing on MUAs. -R --e89a8f3ba97725b13f04ca154c7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't d= ispute any of this. =A0However, I think you are ignoring the
non-MUA world that may also want to use OAuth, and they are typically
running generic GSS-API or SASL libraries that are modelled after the
GSS-API and SASL designs. =A0So by requiring the OAuth SASL mechanism to be treated specially, you are losing the advantages of using a plugin
architecture where you can rely on some things behave the same
regardless of mechanism used. =A0Having a stable overall architecture is an advantage even to the MUA world in the long run.

Very fair; you are right, I was focusing on MUA= s.

-R

--e89a8f3ba97725b13f04ca154c7d-- From simon@josefsson.org Wed Sep 19 15:13: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 5F3F721E8034 for ; Wed, 19 Sep 2012 15:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.861 X-Spam-Level: X-Spam-Status: No, score=-99.861 tagged_above=-999 required=5 tests=[AWL=0.048, 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 uac8h3L1VtI8 for ; Wed, 19 Sep 2012 15:13: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 6B6FC11E808E for ; Wed, 19 Sep 2012 15:13: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 q8JMDOtk019923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Sep 2012 00:13:26 +0200 From: Simon Josefsson To: Ryan Troll References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120919:kitten@ietf.org::13FsF2Sh5TrbQTi1:8jat X-Hashcash: 1:22:120919:rtroll@googlers.com::XxDnsW5tqFIU4kV9:HsHJ Date: Thu, 20 Sep 2012 00:13:23 +0200 In-Reply-To: (Ryan Troll's message of "Wed, 19 Sep 2012 14:39:00 -0700") Message-ID: <87sjadmzjw.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] Google and 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: Wed, 19 Sep 2012 22:13:33 -0000 Let's see if we can take a step back and (re-)analyze another variant. One way to resolve this issue without affecting the SASL design wrt authzid would be to add another key-value field (for example) "resource identity" that transfers the identity that Ryan could route on and that clients would have to supply. Then Ryan's implementation would simply be unable to support a non-empty authzid, since the routing has already happened and cannot be re-routed at that point, but that is okay -- failing on non-empty authzid is the typical response if nothing else has been negotiated out-of-band between user and service provider. The "resource identity" would be a new concept introduced by the OAuth mechanism, which is also fine. The document would have to be careful in explaining this concept so there is no confusion with the authzid. I think I would prefer this, if the other alternative is to always require that the authzid is non-empty. I know we have been over this a few times, but what is the disadvantage with this approach? Is it worse than requiring a non-empty authzid? /Simon From rtroll@google.com Wed Sep 19 15:16: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 DE52C21F84EC for ; Wed, 19 Sep 2012 15:16:39 -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.076, 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 Q4t30dF2Lvhp for ; Wed, 19 Sep 2012 15:16:39 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 575F821F84EB for ; Wed, 19 Sep 2012 15:16:39 -0700 (PDT) Received: by iec9 with SMTP id 9so2660229iec.31 for ; Wed, 19 Sep 2012 15:16:39 -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=nNmH57JTpyDX2wENRBKIL94NKIxEHPTtvZGluIaAkLA=; b=ONw1sPjpvumqYWu4rqDgLxMrxdPvQx1yEzYzL+ybWZusjVThiyuQJXKySdpBLQh4pq CiW3Oazb6WzHx8Nn1VeANfpx+jIIWv4MPvFZu6YuKzFq0i90cEmHqWzDCcunKoP73gPm u1wtCLqy50P7pTlnmWpkqDEbW+yIsrf0+Go84= 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=nNmH57JTpyDX2wENRBKIL94NKIxEHPTtvZGluIaAkLA=; b=PBQp2Alkzb0PoY0pHdl4HQ+o17wRaNycKSdfucgtXLLwxXRXTAAf0mTf9Pc1jTlgVt tyOpdRV6Ltn08p6p/5UVmlQyoF/vbo3KpRuRVnxwPhLthqcjJETHfV4q45jSUEB/EDlG 0G+Vg2o6G5YGoWY3l74hEJvjyBZUjlga5sLh3IvqiGpH6+DwdQPdx6QvMyhqMzj5LUQv NH7nj5YQ1jbSDFzKOQ5nEU/QcopUyxxH4vuXKh5wdtHd2Vraoyr3dQPFBHl00WsqJ7rv +vbdoEFtlswM6iYnA9kSn2Al1Q3bqX5fdZugz6ahz+RSQGzIxvfI/j6dth1uoPk6bokY YqPg== Received: by 10.43.9.3 with SMTP id ou3mr3594725icb.14.1348092998950; Wed, 19 Sep 2012 15:16:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.9.3 with SMTP id ou3mr3594718icb.14.1348092998796; Wed, 19 Sep 2012 15:16:38 -0700 (PDT) Received: by 10.50.36.131 with HTTP; Wed, 19 Sep 2012 15:16:38 -0700 (PDT) In-Reply-To: References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 15:16:38 -0700 Message-ID: From: Ryan Troll To: Nico Williams Content-Type: multipart/alternative; boundary=bcaec50fe0ad51470e04ca155cee X-System-Of-Record: true X-Gm-Message-State: ALoCoQkZtyoI4NemWKSRBTZ9tkZLMGbuF7K6S792AYPqUjL5QH6OBnrvMGX6AC3Lfh3il4jik0tg6j5sff+zgO0D5XDm6ov+3GX+3Zgc3TnCsfvOFaW+AIGpFUQxZx0TpwQbGLP8eOE5A/NZmnaTbHujh3f8l6Tb5O1cHVtdidS2h4nAd6IynkC7ajPs1HXj+UghOjEMPWLc Cc: Simon Josefsson , "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 22:16:40 -0000 --bcaec50fe0ad51470e04ca155cee Content-Type: text/plain; charset=ISO-8859-1 > Now, perhaps Ryan has *two* routing problems: a) how to route the > processing of SASL authentication messages, b) how to route > post-authentication application messages. If we think of these as two > distinct routing tasks (even if the routing outcome is always the same > for (a) and (b)) then we can say that the routing should be done as > follows: > > - make the SASL server framework implementation used by > the router be a proxy such that the mechanism uses > whatever information is available/appropriate to route the > processing of the SASL authentication messages; > > - post-authentication let the router use the authz-id (or authcid) > to route the application messages. > I believe this is a reasonable way of looking at the problem. -R --bcaec50fe0ad51470e04ca155cee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Now, perhaps Ryan has *two* routing problems: a) how to route the
processing of SASL authentication messages, b) how to route
post-authentication application messages. =A0If we think of these as two distinct routing tasks (even if the routing outcome is always the same
for (a) and (b)) then we can say that the routing should be done as
follows:

=A0- make the SASL server framework implementation used by
=A0 =A0the router be a proxy such that the mechanism uses
=A0 =A0whatever information is available/appropriate to route the
=A0 =A0processing of the SASL authentication messages;

=A0- post-authentication let the router use the authz-id (or authcid)
=A0 =A0to route the application messages.

I believe this is a reasonable way of looking at the problem.
=
-R
--bcaec50fe0ad51470e04ca155cee-- From nico@cryptonector.com Wed Sep 19 15:17: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 3FC7121E804C for ; Wed, 19 Sep 2012 15:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=-0.092, 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 JELFd7Sp5X0y for ; Wed, 19 Sep 2012 15:16:59 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8A48021E8034 for ; Wed, 19 Sep 2012 15:16:59 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 2474320202C for ; Wed, 19 Sep 2012 15:16: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=nA1ZVlEp+XAC77+puYV7 3k0IGEA=; b=oFBwujiVeWWXdoA5BxcNE7tXRC/PBF9seaeWI2+JZGDUF455MZRc CJCNtgdE8hJXTFIJaDgtQXPRFWf1RZ8coQRSfGEzzeqN6DgTve3KOP1fZGsK6Cp6 63TDvuTqbOKLZOVlglvWunrUOYQbBa3NJ0pifHY+aldhLQg5WvzSA0w= 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 EF1EB202018 for ; Wed, 19 Sep 2012 15:16:58 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1171852pbb.31 for ; Wed, 19 Sep 2012 15:16:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.236.69 with SMTP id us5mr1614121pbc.59.1348093018473; Wed, 19 Sep 2012 15:16:58 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 15:16:58 -0700 (PDT) In-Reply-To: <87sjadmzjw.fsf@latte.josefsson.org> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 17:16:58 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 22:17:00 -0000 On Wed, Sep 19, 2012 at 5:13 PM, Simon Josefsson wrote: > Let's see if we can take a step back and (re-)analyze another variant. > > One way to resolve this issue without affecting the SASL design wrt > authzid would be to add another key-value field (for example) "resource > identity" that transfers the identity that Ryan could route on and that > clients would have to supply. [...] The problem with this is that it's a change to SASL that existing implementations can't take advantage of. It's like adding an authz-id to the GSS-API: it's a big deal. Before we do anything of the sort I'd like to see if the two-routing-problems approach solves Ryan's problem. Nico -- From nico@cryptonector.com Wed Sep 19 15:18: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 0090821E804C for ; Wed, 19 Sep 2012 15:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=-0.090, 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 na15KohKSXmz for ; Wed, 19 Sep 2012 15:18:24 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9A19321E8034 for ; Wed, 19 Sep 2012 15:18:24 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 6EC64594062 for ; Wed, 19 Sep 2012 15:18:24 -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=P6UhFIFKdBCAXdFMcVxS 2jnGu3I=; b=RjRsOHkmtic8sIkRkzMfNbgiIUcv+Dp71kXs3m29sQ9m+5MAZ5EB 4c5gftef+qV+ycHcH1j6BZSD/Hdn5AjOBfEj97cidYOipIe1elzzWexxQm0w4tHL 5HajagOfC98qEPcJrcu0A1jL84kP2+xnQ5u5SfpIvL0tUO7Zq9cQ45w= 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 4FAA7594061 for ; Wed, 19 Sep 2012 15:18:24 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1174023pbb.31 for ; Wed, 19 Sep 2012 15:18:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr1392285pbc.149.1348093103991; Wed, 19 Sep 2012 15:18:23 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 15:18:23 -0700 (PDT) In-Reply-To: References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 17:18:23 -0500 Message-ID: From: Nico Williams To: Ryan Troll Content-Type: text/plain; charset=UTF-8 Cc: Simon Josefsson , "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 22:18:25 -0000 On Wed, Sep 19, 2012 at 5:16 PM, Ryan Troll wrote: >> Now, perhaps Ryan has *two* routing problems: > > I believe this is a reasonable way of looking at the problem. Great! Is it also sufficient for your purposes, that is, does it address your problem? Nico -- From simon@josefsson.org Wed Sep 19 15:25: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 E29E721E8048 for ; Wed, 19 Sep 2012 15:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.863 X-Spam-Level: X-Spam-Status: No, score=-99.863 tagged_above=-999 required=5 tests=[AWL=0.046, 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 3JHGNvHvW3J9 for ; Wed, 19 Sep 2012 15:25:12 -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 EFF3D21E8034 for ; Wed, 19 Sep 2012 15:25: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 q8JMOwHO020607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Sep 2012 00:24:59 +0200 From: Simon Josefsson To: Nico Williams References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120919:nico@cryptonector.com::9XpAbdnLxK6iZC3k:CZB2 X-Hashcash: 1:22:120919:kitten@ietf.org::HWyDlcTnk81rAeqR:Zk+h Date: Thu, 20 Sep 2012 00:24:57 +0200 In-Reply-To: (Nico Williams's message of "Wed, 19 Sep 2012 17:16:58 -0500") Message-ID: <87obl1mz0m.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] Google and 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: Wed, 19 Sep 2012 22:25:13 -0000 Nico Williams writes: > On Wed, Sep 19, 2012 at 5:13 PM, Simon Josefsson wrote: >> Let's see if we can take a step back and (re-)analyze another variant. >> >> One way to resolve this issue without affecting the SASL design wrt >> authzid would be to add another key-value field (for example) "resource >> identity" that transfers the identity that Ryan could route on and that >> clients would have to supply. [...] > > The problem with this is that it's a change to SASL that existing > implementations can't take advantage of. I don't follow. What implementations, OAuth or SASL implementations? Adding another data field from the client to the server seems straightforward to me. Presumably, the OAuth mechanism will require some data from the client. If this is only a OAuth bearer token or both an OAuth bearer token and resource identity does not seems significant. The client needs to get the data from his provider somehow. All of this is strictly the mechanism's own business, and the SASL design is not involved. /Simon From simon@josefsson.org Wed Sep 19 15:27: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 CB2A321E80B6 for ; Wed, 19 Sep 2012 15:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.864 X-Spam-Level: X-Spam-Status: No, score=-99.864 tagged_above=-999 required=5 tests=[AWL=0.045, 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 Km47YDXhwEO8 for ; Wed, 19 Sep 2012 15:27:02 -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 EE66E21E8048 for ; Wed, 19 Sep 2012 15:27:01 -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 q8JMQpwS020821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Sep 2012 00:26:52 +0200 From: Simon Josefsson To: Nico Williams References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120919:nico@cryptonector.com::SQHoF+OsmERUAHJG:3a3U X-Hashcash: 1:22:120919:kitten@ietf.org::x0GGFrafXbxhHjuf:05R9W Date: Thu, 20 Sep 2012 00:26:50 +0200 In-Reply-To: (Nico Williams's message of "Wed, 19 Sep 2012 17:16:58 -0500") Message-ID: <87k3vpmyxh.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] Google and 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: Wed, 19 Sep 2012 22:27:02 -0000 Nico Williams writes: > Before we do anything of the sort I'd like to see if the > two-routing-problems approach solves Ryan's problem. I should have replied to this as well... I would prefer if the two-routing way of looking at it resolves Ryan's concern, since that seems the simplest to me. However as an alternative compromise idea the "resource identity" could be hashed out further. /Simon From wmills@yahoo-inc.com Wed Sep 19 15:29: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 6E46F21E8048 for ; Wed, 19 Sep 2012 15:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.485 X-Spam-Level: X-Spam-Status: No, score=-17.485 tagged_above=-999 required=5 tests=[AWL=0.113, 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 73-TlKoo3RRe for ; Wed, 19 Sep 2012 15:29: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 C245C21E8034 for ; Wed, 19 Sep 2012 15:29:58 -0700 (PDT) Received: from [98.139.91.69] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 19 Sep 2012 22:29:54 -0000 Received: from [98.139.91.55] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 19 Sep 2012 22:29:54 -0000 Received: from [127.0.0.1] by omp1055.mail.sp2.yahoo.com with NNFMP; 19 Sep 2012 22:29:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 501067.44128.bm@omp1055.mail.sp2.yahoo.com Received: (qmail 92679 invoked by uid 60001); 19 Sep 2012 22:29:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348093793; bh=JeWBkFW7wnlLLzIniTZvDxZXGycX5uqHoQ3aAjTJa2Q=; 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=fv+pTDhrHH6aFMytcTdx+4R8L4URVruk1KmsVixR+nEvJohKX3KSZJB5o6PtVgjSn7pdrVjjV7aTAFLolpQHpM7B73xuL6q7ByGs5MLqrzJIFGM4h0qduc3alUhmTalqIQ1LomEO7bHOvRgculbid4Em8le/6UO8grJvMsATjYQ= 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=BOhddY4Wq4nSbSrtFfv0zbYV5w+QHkqkers9cbQjx0ZsLaweR+NV2fqvyemqke19KGu3wfi+R1gH8cvQNcdCCjHeshmQ0CXJ/CNWa84UQMG+4y5CJgNqYu9+L2mJYL4s25qEdBCvK9j2q2W7Oy+ZVp40nem2mw5xFU/m2KQxJ2Q=; X-YMail-OSG: 80WKMtwVM1kb.58zu4WmKlspNknwQlnaDWxrzVLav_0Rz4r Zq04SAA9aY0pS0EcTF3PMJHHkOjo4R55EEEKr9VtCUrwBfoGL27nU8aXpbp3 cX5cHgbZiokynWJzNsmucsHHexbCFWz9MRnf_xiECSvP8CvrO36H96vAndlH uboNSqi6Yup..8sXbPVTaCmhcfwM8CRQwWv_2D.kASkLhavrSB91vb45Kf_b CVCYPFxb8jn48VqEQ9xkBjEdnp9Bm.p5UX2.E4IHruFtMjHedVVBqcV7RCqf Ey_iWS9SRMUdEza5HsySwEEOnitIEdIvPgphUTgUfyz2TgYl5840l5BZVgWq aPszdsJzvlGahyoDVU62kVLoe1EzxNUgfkJ5LzZ1WEZH.2eLVO43zWZ5Aekv 5.l9wNE1qt24y_Q2iy43IlPR1cLmLXwuIkmS2keYE6ZZStV7Kn2SeOFxvYZE sHF3oOxA- Received: from [209.131.62.113] by web31808.mail.mud.yahoo.com via HTTP; Wed, 19 Sep 2012 15:29:52 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87k3vpmyxh.fsf@latte.josefsson.org> Message-ID: <1348093792.92654.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 15:29:52 -0700 (PDT) From: William Mills To: Simon Josefsson , Nico Williams In-Reply-To: <87k3vpmyxh.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-356758851-1348093792=:92654" Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 22:29:59 -0000 --258328648-356758851-1348093792=:92654 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The resource identity field being a renaming of the current "user" field?= =0A=0A=0A=0A=0A=0A>________________________________=0A> From: Simon Josefss= on =0A>To: Nico Williams =0A>C= c: "kitten@ietf.org" =0A>Sent: Wednesday, September 19, 2= 012 3:26 PM=0A>Subject: Re: [kitten] Google and SASL OAuth=0A> =0A>Nico Wil= liams writes:=0A>=0A>> Before we do anything of the= sort I'd like to see if the=0A>> two-routing-problems approach solves Ryan= 's problem.=0A>=0A>I should have replied to this as well...=A0 I would pref= er if the=0A>two-routing way of looking at it resolves Ryan's concern, sinc= e that=0A>seems the simplest to me.=A0 However as an alternative compromise= idea the=0A>"resource identity" could be hashed out further.=0A>=0A>/Simon= =0A>_______________________________________________=0A>Kitten mailing list= =0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/listinfo/kitten=0A>=0A>= =0A> --258328648-356758851-1348093792=:92654 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The resou= rce identity field being a renaming of the current "user" field?


<= div style=3D"font-family: Courier New, courier, monaco, monospace, sans-ser= if; font-size: 14pt;">
From: Simon Josefsson <simon@josefsson.org>
To: Nico Williams <nico@cryptonector.com>= ;
Cc: "kitten@ietf.org= " <kitten@ietf.org>
Sent:<= /span> Wednesday, September 19, 2012 3:26 PM
Subject: Re: [kitten] Google and SASL OAuth
Nico Williams <nico@cryptonector.com> writes:
=
> Before we do anything of the sort I'd like to see if the
> t= wo-routing-problems approach solves Ryan's problem.

I should have re= plied to this as well...  I would prefer if the
two-routing way of = looking at it resolves Ryan's concern, since that
seems the simplest to = me.  However as an alternative compromise idea the
"resource identi= ty" could be hashed out further.

/Simon
_________________________= ______________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

=
--258328648-356758851-1348093792=:92654-- From rtroll@google.com Wed Sep 19 15:33: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 DCA3C21E8034 for ; Wed, 19 Sep 2012 15:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.907 X-Spam-Level: X-Spam-Status: No, score=-102.907 tagged_above=-999 required=5 tests=[AWL=0.069, 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 Er5swzAbDC6M for ; Wed, 19 Sep 2012 15:33:10 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B83F21F8504 for ; Wed, 19 Sep 2012 15:33:10 -0700 (PDT) Received: by iec9 with SMTP id 9so2693462iec.31 for ; Wed, 19 Sep 2012 15:33:08 -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=KDB7cMnF+oSRAB6kzSVX5D2Me50fmTCojKVNCyrFI8c=; b=fpXJH+RfBJSnyjZyilZbEKoQVe9h/pGDw/F7VSom8Vy+/7jf8G69Yl0KJxRs5oejOY r9K5hFFGfqzRLQXds+4cTpiUICgP1QdQQkDK8SpAhXE0wb3KKkykayd7m1OSJsslH45Z btcu/16vL0Jg/0ywzla6OBkowMM7SchJ5Z5jI= 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=KDB7cMnF+oSRAB6kzSVX5D2Me50fmTCojKVNCyrFI8c=; b=hLZGaNsT0xO4EJbXsU3q2UCtAcYJgN8QBEkBP4SQnynpAg8KxzipHnf9AywtpWROE5 HXQa6VacUYJ4cuBaLarhmnRAuMkAulIcHz6MD5rOMN7fWZ+Uzq6ffhwPzlR0Bfk/6j/N /XbacCq8UusmTxfZpHDWWXyys942s1iZ6b8cE/HPtVgqsUZ0dUtSth2tLq1ROjA1J6xC +f7tiowrp8ar5cTrC9Etih4oPu4VjhQ385K/c/QL7K5n/DLRgjohAvSiheGBBQ1wgSMF 6lgLe7WdioaK1IZo7EI+Wwt7bvNO25E+JybiBIdWIuCkGkv5ipchYGTjBcExPl1/75SY y5ZQ== MIME-Version: 1.0 Received: by 10.50.77.164 with SMTP id t4mr4219544igw.19.1348093988699; Wed, 19 Sep 2012 15:33:08 -0700 (PDT) Received: by 10.50.36.131 with HTTP; Wed, 19 Sep 2012 15:33:08 -0700 (PDT) In-Reply-To: References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 15:33:08 -0700 Message-ID: From: Ryan Troll To: Nico Williams Content-Type: multipart/alternative; boundary=e89a8f3b9d2f51ff2f04ca1597f2 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmPuAD0IVAO/DbIIVRo/qrNr5XaCK3+6OCVemI3hNAJNI0HpzIgqkWmr6EYMVUR+l2TcFSS/lMAhx2CCcD7lbx0No22WgGyliuqzr4HEYiWi0rbPfSlcXLh8mGFSy28wpOKPpsZaEpMpqozRw9+uF57L85wrBLW3llKd+mJAnH46L+isCZc+V2XKyWH7Att5EC4xKQg Cc: Simon Josefsson , "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 22:33:11 -0000 --e89a8f3b9d2f51ff2f04ca1597f2 Content-Type: text/plain; charset=ISO-8859-1 I'm sorry, you've lost me. The two routing decisions being made are: Problem #1 -- have the router's SASL implementation use what information's available to route the authentication Problem #2 -- have the router route all subsequent requests appropriately Our current approach uses the routing decision for Problem #1 as the answer to Problem #2, so I'm not quite sure how this rephrasing helps alleviate the issue at hand. -R On Wed, Sep 19, 2012 at 3:18 PM, Nico Williams wrote: > On Wed, Sep 19, 2012 at 5:16 PM, Ryan Troll wrote: > >> Now, perhaps Ryan has *two* routing problems: > > > > I believe this is a reasonable way of looking at the problem. > > Great! Is it also sufficient for your purposes, that is, does it > address your problem? > > Nico > -- > --e89a8f3b9d2f51ff2f04ca1597f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm sorry, you've lost me.

The two routing decis= ions being made are:

Problem #1 -- have the router= 's SASL implementation use what information's available to route th= e authentication
Problem #2 -- have the router route all subsequent requests appropriat= ely


Our current approach uses the r= outing decision for Problem #1 as the answer to Problem #2, so I'm not = quite sure how this rephrasing helps alleviate the issue at hand.

-R





On Wed, Sep 19, 2012 = at 3:18 PM, Nico Williams <nico@cryptonector.com> wrote:=
On Wed, Sep 19, 2012 at 5:= 16 PM, Ryan Troll <rtroll@googler= s.com> wrote:
>> Now, perhaps Ryan has *two* routing problems:
>
> I believe this is a reasonable way of looking = at the problem.

Great! =A0Is it also sufficient for your purposes, that is, does it address your problem?

Nico
--

--e89a8f3b9d2f51ff2f04ca1597f2-- From rtroll@google.com Wed Sep 19 15:35: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 E314021E8048 for ; Wed, 19 Sep 2012 15:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.912 X-Spam-Level: X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=0.064, 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 86A7tFowTlGh for ; Wed, 19 Sep 2012 15:35:28 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 40E9321F8505 for ; Wed, 19 Sep 2012 15:35:28 -0700 (PDT) Received: by iec9 with SMTP id 9so2697991iec.31 for ; Wed, 19 Sep 2012 15:35:27 -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=1PBAsjD94b2axXM/DahXa6sedNZ5lUeEgqt4nuNCQls=; b=gTWRN3bepFZV7eLdXgMz3at8JWvmotm/8GumJUMABOiy55bul25fLW+mNXw7afgMKc MpM6ahB6N8XFlomAL4+B9QF3g3jIKgIY6/xVcqwn7xMsfw4bMT6cARoldO9F0TZSlaL7 FW/RdL7/LXNoteVxoXi7xQPZ9kkvafmM6OaeU= 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=1PBAsjD94b2axXM/DahXa6sedNZ5lUeEgqt4nuNCQls=; b=LCd7FgSYKai/HaOKCR3PdPAWJ+vWNL9XlIyvbA9Bd8bETkjm3Jb/ARkVCRCWc3OuTn 45Qc2scmvZi7oqxc4RNof/tiyCsCugRkEuCsp0ppvzCkNkhIrHokasKl7d1rv4diSOZH M2CK75AqY//+aE6PCR2qeWnqGUFijvZc/b5HtKntaVww+TFnl4WWHjNyTLfVIuzTI1hC FY5vYWrltYY1OMoLEJ/9tw5EzoWBOiF6xqW6os9wlUI3F+EoIFenYxsdhLmCGzbnyyj2 37nthGGtlyGcsa+CJ+zpC85OLnHvMPSxe2iFAFIuAXWOa7nMIzaGuru6oEFtABXtFENX d/cQ== Received: by 10.42.92.17 with SMTP id r17mr3532164icm.39.1348094127693; Wed, 19 Sep 2012 15:35:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.92.17 with SMTP id r17mr3532154icm.39.1348094127575; Wed, 19 Sep 2012 15:35:27 -0700 (PDT) Received: by 10.50.36.131 with HTTP; Wed, 19 Sep 2012 15:35:27 -0700 (PDT) In-Reply-To: References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 15:35:27 -0700 Message-ID: From: Ryan Troll To: Ryan Troll Content-Type: multipart/alternative; boundary=90e6ba5bbb3599124504ca159f3b X-System-Of-Record: true X-Gm-Message-State: ALoCoQkwqcMXPt1QF3Ht6y5+1KzkiNqmhuGYCt3JJPwy0N2YFNh8L02wLUvnVyYvxmbvk0y2I1MO+7EFeCvVNdYkrGmNZRdPloDYpCJfQUg1mLAdibjGQ9LNnb+eMphv6qYd/WQKfUCfUNWFzjmJo8B3DRsc9EtSaCjUyzpmfXAQPTYhlGp1ghjvq19rOHj1ZiCC4IEYFn6D Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 22:35:29 -0000 --90e6ba5bbb3599124504ca159f3b Content-Type: text/plain; charset=ISO-8859-1 Hm - let me see if I can articulate that better. Within the SASL implementation, without cracking open the OAuth credential, how would you propose identifying the authz_id? -R On Wed, Sep 19, 2012 at 3:33 PM, Ryan Troll wrote: > I'm sorry, you've lost me. > > The two routing decisions being made are: > > Problem #1 -- have the router's SASL implementation use what information's > available to route the authentication > Problem #2 -- have the router route all subsequent requests appropriately > > > Our current approach uses the routing decision for Problem #1 as the > answer to Problem #2, so I'm not quite sure how this rephrasing helps > alleviate the issue at hand. > > -R > > > > > > On Wed, Sep 19, 2012 at 3:18 PM, Nico Williams wrote: > >> On Wed, Sep 19, 2012 at 5:16 PM, Ryan Troll wrote: >> >> Now, perhaps Ryan has *two* routing problems: >> > >> > I believe this is a reasonable way of looking at the problem. >> >> Great! Is it also sufficient for your purposes, that is, does it >> address your problem? >> >> Nico >> -- >> > > --90e6ba5bbb3599124504ca159f3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hm - let me see if I can articulate that better.

Within = the SASL implementation, without cracking open the OAuth credential, how wo= uld you propose identifying the authz_id?

-R

On Wed, Sep 19, 2012 at 3:33 PM, Ryan Troll = <rtroll@googlers.com> wrote:
I'm sorry, you've lost me.

The two routing decis= ions being made are:

Problem #1 -- have the router= 's SASL implementation use what information's available to route th= e authentication
Problem #2 -- have the router route all subsequent requests appropriat= ely


Our current approach uses the r= outing decision for Problem #1 as the answer to Problem #2, so I'm not = quite sure how this rephrasing helps alleviate the issue at hand.

-R





On Wed, Sep 19, 2012 at 3:18 PM, Nico Williams <nico@crypto= nector.com> wrote:
On Wed, Se= p 19, 2012 at 5:16 PM, Ryan Troll <rtroll@googlers.com> wrote:
>> Now, perhaps Ryan has *two* routing problems:
>
> I believe this is a reasonable way of looking at the proble= m.

Great! =A0Is it also sufficient for your purposes, that is, does it address your problem?

Nico
--


--90e6ba5bbb3599124504ca159f3b-- From wmills@yahoo-inc.com Wed Sep 19 15:40: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 486EF21E804E for ; Wed, 19 Sep 2012 15:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.488 X-Spam-Level: X-Spam-Status: No, score=-17.488 tagged_above=-999 required=5 tests=[AWL=0.110, 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 SEzCXYeFZkWG for ; Wed, 19 Sep 2012 15:40:03 -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 SMTP id 3B60721E8048 for ; Wed, 19 Sep 2012 15:40:03 -0700 (PDT) Received: from [98.139.52.193] by nm25.bullet.mail.ac4.yahoo.com with NNFMP; 19 Sep 2012 22:39:56 -0000 Received: from [98.139.52.183] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 19 Sep 2012 22:39:56 -0000 Received: from [127.0.0.1] by omp1066.mail.ac4.yahoo.com with NNFMP; 19 Sep 2012 22:39:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 700494.23027.bm@omp1066.mail.ac4.yahoo.com Received: (qmail 14988 invoked by uid 60001); 19 Sep 2012 22:39:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348094395; bh=cuP4fbdko6rxT1wCZHbUMTwiXtK8Iq1Zn8rVlA82qXw=; 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=Jzz/65DlpcTkHivsLnMLoheh95gFhAvR/DHNM+c5bHi0yJLzeL4QZB2GNk99ajsH/duGTGI2ZY/0uwxCEnxLtEjeO96G43Qs5EXE63uVlpgBTJXrn0zrXMRz8rd4z3etgQh1ClCl/kxU0aw0YLQd6J71DmcEgO6kFzoAc5/MCJY= 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=VmO7eL+65rUmyvntpQxIFocElmif9qYD1y55weODy652dOpUpaNvLB6tAWWE6du4CCa7IEqfDJCUMQx/rEOx2Q7xIpgMuKoafaxuV1mMkFX44jgXSMGsUd1+v7vWomtLx4rYqfYZ7ng5t0Q+ss/522bBMZ0Pag8jHeRWtcnfKw8=; X-YMail-OSG: 7_V6U4MVM1n8VERTPbLoQ1G3YtOG.isfz3DpB9uaJHw9vGq byee6IENZqkTUtZghJaXBHifDfsj8S7al.gMSiPvB.RiCggI1ets6VeZV2I3 XBETFMgs1lxH05JbW3A0peeKrUxpQsYNKg9AtJplXyNMhuIGY_kIfX1yg..Y z22d.677ZqHAnVkPk_91fPgKn3UU4fo01jPn7KIcrWquMO5Wtw2JPPq5Kr.S duqfa9ug5MQvA85QLmAJ.Sq07OTOqqKK82jXgN89EbMesrs4lmpLtkYaJ1T7 WDbH39JfUZiQ4VB5jWZehtNH6RPnZ41OGTl6bvZKpfPEKf_AD7ySb_qqN6lR vayfi3Sl1T44W3vHTDko3LvrcMFFuO5eBw64RgzsAkMRy1iH.Kyab3q9_XHz EnbuFUUukK_L7a4rDVCEqABN20pHzxqrX977hGHaODVaOfGzmnd1yltRq4kV 7Rm9jvho- Received: from [209.131.62.113] by web31810.mail.mud.yahoo.com via HTTP; Wed, 19 Sep 2012 15:39:55 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> Message-ID: <1348094395.12326.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 15:39:55 -0700 (PDT) From: William Mills To: Ryan Troll In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1935884094-2030888837-1348094395=:12326" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 22:40:04 -0000 --1935884094-2030888837-1348094395=:12326 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I've hit this wall before...=A0 authz-id will be wrong here.=A0 I think the= question you need to ask is, "Without using the credential in any way how = can I get a hint of what resource is being accessed?".=0A=0A=0A=0A=0A=0A>__= ______________________________=0A> From: Ryan Troll = =0A>To: Ryan Troll =0A>Cc: "kitten@ietf.org" ; Simon Josefsson =0A>Sent: Wednesday, Septe= mber 19, 2012 3:35 PM=0A>Subject: Re: [kitten] Google and SASL OAuth=0A> = =0A>=0A>Hm - let me see if I can articulate that better.=0A>=0A>=0A>Within = the SASL implementation, without cracking open the OAuth credential, how wo= uld you propose identifying the authz_id?=0A>=0A>=0A>-R=0A>=0A>=0A>On Wed, = Sep 19, 2012 at 3:33 PM, Ryan Troll wrote:=0A>=0A>I'm= sorry, you've lost me.=0A>>=0A>>=0A>>The two routing decisions being made = are:=0A>>=0A>>=0A>>Problem #1 -- have the router's SASL implementation use = what information's available to route the authentication=0A>>Problem #2 -- = have the router route all subsequent requests appropriately=0A>>=0A>>=0A>>= =0A>>=0A>>Our current approach uses the routing decision for Problem #1 as = the answer to Problem #2, so I'm not quite sure how this rephrasing helps a= lleviate the issue at hand.=0A>>=0A>>-R=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>= =0A>>=0A>>=0A>>=0A>>On Wed, Sep 19, 2012 at 3:18 PM, Nico Williams wrote:=0A>>=0A>>On Wed, Sep 19, 2012 at 5:16 PM, Ryan Troll= wrote:=0A>>>>> Now, perhaps Ryan has *two* routing p= roblems:=0A>>>>=0A>>>=0A>>>> I believe this is a reasonable way of looking = at the problem.=0A>>>=0A>>>Great! =A0Is it also sufficient for your purpose= s, that is, does it=0A>>>address your problem?=0A>>>=0A>>>Nico=0A>>>--=0A>>= >=0A>>=0A>=0A>_______________________________________________=0A>Kitten mai= ling list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/listinfo/kitte= n=0A>=0A>=0A> --1935884094-2030888837-1348094395=:12326 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I've hit = this wall before...  authz-id will be wrong here.  I think the qu= estion you need to ask is, "Without using the credential in any way how can= I get a hint of what resource is being accessed?".


From: Ryan T= roll <rtroll@googlers.com>
= To: Ryan Troll <rtroll@googlers.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>; Simon Jos= efsson <simon@josefsson.org>
Sent: Wednesday, September 19, 2012 3:35 PM
Subject: Re: [kitten] Google and SASL O= Auth

Hm - let me see if I c= an articulate that better.

Within the SASL implementatio= n, without cracking open the OAuth credential, how would you propose identi= fying the authz_id?

-R
=0A
On Wed, Sep 19, 2012 at 3:33 PM, Ryan Troll <rtroll@googlers.com&= gt; wrote:
=0AI'm sor= ry, you've lost me.

The two routing decisions being made= are:

Problem #1 -- have the router's SASL impleme= ntation use what information's available to route the authentication
= =0A=0A
Problem #2 -- have the router route all subsequent requests appr= opriately


Our current approach uses= the routing decision for Problem #1 as the answer to Problem #2, so I'm no= t quite sure how this rephrasing helps alleviate the issue at hand.
= =0A=0A

<= /div>
-R





On Wed, Sep 19, 2012 at 3:18 PM, Nico Williams <nico@cryptonec= tor.com> wrote:
=0A=0A
On Wed, Sep 19, 2012 = at 5:16 PM, Ryan Troll <rtroll@goo= glers.com> wrote:
=0A=0A=0A>> Now, perhaps Ryan has *two* r= outing problems:
=0A>
=0A
> I believe this is a reaso= nable way of looking at the problem.
=0A
=0A
Great!  Is it = also sufficient for your purposes, that is, does it
=0Aaddress your prob= lem?
=0A
=0ANico
=0A--
=0A

=0A

=0A

____________________= ___________________________
Kitten mailing list
Kitten@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/kitten


--1935884094-2030888837-1348094395=:12326-- From ve7jtb@ve7jtb.com Wed Sep 19 16:19: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 6227221F84C5 for ; Wed, 19 Sep 2012 16:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 JFnmb2UrwUfZ for ; Wed, 19 Sep 2012 16:19:02 -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 BD09A21F84C4 for ; Wed, 19 Sep 2012 16:19:02 -0700 (PDT) Received: by qafi29 with SMTP id i29so4060266qaf.10 for ; Wed, 19 Sep 2012 16:19:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Ie0ZlN0mTXfiSVXpF7I1R71q7+ZctF0vMoK4L5OZdJo=; b=pP77BtoqBmSLzpnR6PqiZFDgYshywi7IUwcl2r6vnvlC8a4EOaO3ViaVXlLeZbS+0U 0bm7dNxdIyGItyig/NnZs2T86L+QMXiES7YP2ZishY3UUZhgotREE4MTUAvQphzlwiit uloA8n5iXKzRwWLp50n2zxT11iCdFBfCjbXi6AjY1GRWCFsG+gzJQhW9fVoKNOicK0h4 7YUTN6a5DxUuZwVwftqwq+oSRMQQVOmCFeTCpnkKMEwXZn/C2e04LN8EVHRgQlzvbmzx vnmJnGkmhiMpdw/tnIpZQx9enGnqH2NwiQHZ5DWtnS3e6KNvGj3Kqmju/KtdRLbsLI3G oPuA== Received: by 10.224.177.15 with SMTP id bg15mr504505qab.85.1348096742199; Wed, 19 Sep 2012 16:19:02 -0700 (PDT) Received: from [192.168.1.211] (190-20-23-156.baf.movistar.cl. [190.20.23.156]) by mx.google.com with ESMTPS id et6sm5754992qab.8.2012.09.19.16.18.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Sep 2012 16:19:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: <87sjadmzjw.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 20:18:50 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQmAc/CqMqq7iKmplewUtFS2wQleN3DP3KgME/l5MhbdK9CcAhKNVwxmJi2o38YWzM7DtREe Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 23:19:03 -0000 In some ways trying to fit OAuth 1 is twisting the semantics. Looking at it from a OAuth 2 bearer perspective.=20 The email/xmpp address is the authentication identifier in the context = of the RS API . The bearer token is just a long password in most respects. Sending the email/resource identifier for the user as the authcid and = the token as another parameter may have the benefit of simplicity for = OAuth 2. Trying to map the abstract concept of the user identity at the = authorization server in just adds complexity. John B. On 2012-09-19, at 7:13 PM, Simon Josefsson wrote: > Let's see if we can take a step back and (re-)analyze another variant. >=20 > One way to resolve this issue without affecting the SASL design wrt > authzid would be to add another key-value field (for example) = "resource > identity" that transfers the identity that Ryan could route on and = that > clients would have to supply. Then Ryan's implementation would simply > be unable to support a non-empty authzid, since the routing has = already > happened and cannot be re-routed at that point, but that is okay -- > failing on non-empty authzid is the typical response if nothing else = has > been negotiated out-of-band between user and service provider. The > "resource identity" would be a new concept introduced by the OAuth > mechanism, which is also fine. The document would have to be careful = in > explaining this concept so there is no confusion with the authzid. >=20 > I think I would prefer this, if the other alternative is to always > require that the authzid is non-empty. >=20 > I know we have been over this a few times, but what is the = disadvantage > with this approach? Is it worse than requiring a non-empty authzid? >=20 > /Simon > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nico@cryptonector.com Wed Sep 19 16:19: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 54F2D21E80AF for ; Wed, 19 Sep 2012 16:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 dAhLmYUzJBxr for ; Wed, 19 Sep 2012 16:19:15 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id CB98F21E804E for ; Wed, 19 Sep 2012 16:19:15 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 836EC36006F for ; Wed, 19 Sep 2012 16:19: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=V3kdmNPl7t54VTQYMI7O W3OBvv4=; b=yBEabzwOgiRAAf35Z3K3xz3dH3o6C8gWHTp/UCrTT56SDqeyQ+Cg qllFlkZFCNpEarVRF3knPMTwSLIBm+sCOeHSzd8uJaTd2fsLHaLCCyZoKFmF6Ak0 42wNsXbtdeZ8qHUnbd+/UwG1FTflEmNJFLU1xWZ9IxxXx3Pm34XVCbU= 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 5FE6A36005C for ; Wed, 19 Sep 2012 16:19:15 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1264960pbb.31 for ; Wed, 19 Sep 2012 16:19:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.194 with SMTP id d2mr838943pax.42.1348096755087; Wed, 19 Sep 2012 16:19:15 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 16:19:14 -0700 (PDT) In-Reply-To: References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 18:19:14 -0500 Message-ID: From: Nico Williams To: Ryan Troll Content-Type: text/plain; charset=UTF-8 Cc: Simon Josefsson , "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 23:19:16 -0000 On Wed, Sep 19, 2012 at 5:33 PM, Ryan Troll wrote: > I'm sorry, you've lost me. > > The two routing decisions being made are: > > Problem #1 -- have the router's SASL implementation use what information's > available to route the authentication If the router can terminate the SASL exchange then there's nothing else to debate here: just use the authz-id, if one was provided, or map the authcid to a resource name otherwise. I was positing that perhaps you didn't want to terminate the SASL exchange at the router, that you wanted to have the resource server also be the terminator for the SASL exchange. In *that* case I'd propose that you have two routing problems, but since that appears not to be the case let's just forget it. Nico -- From nico@cryptonector.com Wed Sep 19 16:22: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 485F521E804E for ; Wed, 19 Sep 2012 16:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 L3+G14L-FVfW for ; Wed, 19 Sep 2012 16:22:07 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id BC75821E8048 for ; Wed, 19 Sep 2012 16:22:07 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 91B0B59807A for ; Wed, 19 Sep 2012 16:22: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=FFMK7tcHFohPW7mBYWNy UQffOeA=; b=tR8pIBM68kMKzYL3OCkEtK4xZFf4hG592OVQonuulF9WgqUp01qn Liwc27FPONNqJDRxm8j6hm2/jXfSAohpm0PNtR/EbeH6SEzhAs3vD8L/2e/a320P iG4ZlTZpSxH0tJfgEEKa4y6rLfcZu3P6GWJRdTYijMGbRYRtf0gf/YU= 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-a27.g.dreamhost.com (Postfix) with ESMTPSA id 7786F59806A for ; Wed, 19 Sep 2012 16:22:07 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1269308pbb.31 for ; Wed, 19 Sep 2012 16:22:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.85.133 with SMTP id h5mr963736paz.10.1348096927108; Wed, 19 Sep 2012 16:22:07 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 16:22:07 -0700 (PDT) In-Reply-To: <87obl1mz0m.fsf@latte.josefsson.org> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> Date: Wed, 19 Sep 2012 18:22:07 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 23:22:08 -0000 On Wed, Sep 19, 2012 at 5:24 PM, Simon Josefsson wrote: > Nico Williams writes: >> The problem with this is that it's a change to SASL that existing >> implementations can't take advantage of. > > I don't follow. What implementations, OAuth or SASL implementations? > > Adding another data field from the client to the server seems > straightforward to me. Presumably, the OAuth mechanism will require Adding a field is. Making it so SASL implementations know to output it is another. As long as anything new of this sort is done like GSS naming extensions then it can work backwards-compatibly. What I would object to is anything that would require adding variants of sasl_server_step() and similar functions in Cyrus SASL. > some data from the client. If this is only a OAuth bearer token or both > an OAuth bearer token and resource identity does not seems significant. > The client needs to get the data from his provider somehow. All of this > is strictly the mechanism's own business, and the SASL design is not > involved. From wmills@yahoo-inc.com Wed Sep 19 16:30: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 A41F321E804E for ; Wed, 19 Sep 2012 16:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[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 bxjsV4xPIKyf for ; Wed, 19 Sep 2012 16:30:05 -0700 (PDT) Received: from nm24-vm0.bullet.mail.ac4.yahoo.com (nm24-vm0.bullet.mail.ac4.yahoo.com [98.139.53.222]) by ietfa.amsl.com (Postfix) with SMTP id 91D7021E8048 for ; Wed, 19 Sep 2012 16:30:05 -0700 (PDT) Received: from [98.139.52.190] by nm24.bullet.mail.ac4.yahoo.com with NNFMP; 19 Sep 2012 23:29:58 -0000 Received: from [98.139.52.174] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 19 Sep 2012 23:29:58 -0000 Received: from [127.0.0.1] by omp1057.mail.ac4.yahoo.com with NNFMP; 19 Sep 2012 23:29:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 869974.26854.bm@omp1057.mail.ac4.yahoo.com Received: (qmail 70298 invoked by uid 60001); 19 Sep 2012 23:29:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348097398; bh=JtsDcVnfDvNc+JAh1J7GT3GkB4eJkljv7OHAD4k9hMo=; 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=FPHKAZVDN3yM2Rqg5OaAtouFe0WGTgMZz7Ehpuu5pEwBUTlah6M1Azyu6261AT7tfg2Rz1uaeBEaw7w8+pnaRJV6ZjBn35XT3mX7T+onmMrvUvG29AmnP3RGeefdnorGWr5hUMWDLH1FMPIczn5hRiEhYJaXbxdMi3zqE2XRpNo= 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=h+v6DtOx97k6Xkl7YQ5ujMv6KcBgijbZ4UMZ4alELBK4/R9gmPUyRgFx6qNKj0EWtJ4WoO386Eu+0Kzuzbs4qjMRy34n9oeALaGhQXA7/qWIGtz7OnoAzswYWP2719KXhEjGRl3DnAOCzWaYXArZu0C+otJA7QEnmyXlGKlUACk=; X-YMail-OSG: xTi.CSwVM1lK2hSu2R0NVVH3mQoTVUcUB5CKC4FTmEMx7Tt BSPfHRcLkgVSoAw0S8h3tdmb5rwXm5h9irXixeqd5jV2z4liEytOlp_4i6Nd WX_ESL5K4p_JuivavG1ZMBb2W_8prX.rzFV6k8sBRcMyyuRaTSFRKDgX6Vja EJo7rftO194yqwei3yo0Qm_cRFWJY80vZINGezvINPiY3cA0umUxO319nE1j SyFAVuV3I83ddplVAhXqcoxa9mn.CoUB8JNNV.1VsbG7Zky4HzMezZ0B3dE_ 58HP_MTLTMMbGhs1PGWYLMdjZinblqyFYdjvHX.Z8NmX_MwdhbV7ITXa0tBZ zUHzjxYwlINoUUdRNtoyM2hbEkNQrWczDumdZdtLyn29m50_UnOszzFjORX6 SvplxmvZZBNdsEI5Lx1g6GNiiUJPp8rEnWyCqHIaX_eRi Received: from [166.250.35.48] by web31801.mail.mud.yahoo.com via HTTP; Wed, 19 Sep 2012 16:29:58 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> Message-ID: <1348097398.58898.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 16:29:58 -0700 (PDT) From: William Mills To: John Bradley , Simon Josefsson In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-368338466-641630669-1348097398=:58898" Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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: Wed, 19 Sep 2012 23:30:06 -0000 ---368338466-641630669-1348097398=:58898 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OAuth 1 vs. 2 in the current discussion is irrelevant, we have the same fun= ctionality requesth in either case.=A0 =0A=0A=0A=0A=0A=0A=0A=0A>___________= _____________________=0A> From: John Bradley =0A>To: Sim= on Josefsson =0A>Cc: "kitten@ietf.org" =0A>Sent: Wednesday, September 19, 2012 4:18 PM=0A>Subject: Re: [kitten= ] Google and SASL OAuth=0A> =0A>In some ways trying to fit OAuth 1 is twist= ing the semantics.=0A>=0A>Looking at it from a OAuth 2 bearer perspective. = =0A>=0A>The email/xmpp address is the authentication identifier in the cont= ext of the RS API .=0A>=0A>The bearer token is just a long password in most= respects.=0A>=0A>Sending the email/resource identifier for the user as the= authcid and the token as another parameter may have the benefit of simplic= ity for OAuth 2.=0A>=0A>Trying to map the abstract concept of the user iden= tity at the authorization server in just adds complexity.=0A>=0A>John B.=0A= >=0A>On 2012-09-19, at 7:13 PM, Simon Josefsson wrote= :=0A>=0A>> Let's see if we can take a step back and (re-)analyze another va= riant.=0A>> =0A>> One way to resolve this issue without affecting the SASL = design wrt=0A>> authzid would be to add another key-value field (for exampl= e) "resource=0A>> identity" that transfers the identity that Ryan could rou= te on and that=0A>> clients would have to supply.=A0 Then Ryan's implementa= tion would simply=0A>> be unable to support a non-empty authzid, since the = routing has already=0A>> happened and cannot be re-routed at that point, bu= t that is okay --=0A>> failing on non-empty authzid is the typical response= if nothing else has=0A>> been negotiated out-of-band between user and serv= ice provider.=A0 The=0A>> "resource identity" would be a new concept introd= uced by the OAuth=0A>> mechanism, which is also fine.=A0 The document would= have to be careful in=0A>> explaining this concept so there is no confusio= n with the authzid.=0A>> =0A>> I think I would prefer this, if the other al= ternative is to always=0A>> require that the authzid is non-empty.=0A>> =0A= >> I know we have been over this a few times, but what is the disadvantage= =0A>> with this approach?=A0 Is it worse than requiring a non-empty authzid= ?=0A>> =0A>> /Simon=0A>> _______________________________________________=0A= >> Kitten mailing list=0A>> Kitten@ietf.org=0A>> https://www.ietf.org/mailm= an/listinfo/kitten=0A>=0A>_______________________________________________= =0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/= listinfo/kitten=0A>=0A>=0A> ---368338466-641630669-1348097398=:58898 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OAuth 1 v= s. 2 in the current discussion is irrelevant, we have the same functionalit= y requesth in either case. 




=
From: John Bradley <= ;ve7jtb@ve7jtb.com>
To:= Simon Josefsson <simon@josefsson.org>
Cc: "kitten@ietf.org" <kitten@ietf.org> Sent: Wednesday, September 19, 201= 2 4:18 PM
Subject: Re:= [kitten] Google and SASL OAuth

In some ways trying = to fit OAuth 1 is twisting the semantics.

Looking at it from a OAuth= 2 bearer perspective.

The email/xmpp address is the authentication= identifier in the context of the RS API .

The bearer token is just = a long password in most respects.

Sending the email/resource identif= ier for the user as the authcid and the token as another parameter may have= the benefit of simplicity for OAuth 2.

Trying to map the abstract c= oncept of the user identity at the authorization server in just adds comple= xity.

John B.

On 2012-09-19, at 7:13 PM, Simon Josefsson <= simon@josefsson.org> wrote:

> Let's see if we can take = a step back and (re-)analyze another variant.
>
> One way to re= solve this issue without affecting the SASL design wrt
> authzid woul= d be to add another key-value field (for example) "resource
> identit= y" that transfers the identity that Ryan could route on and that
> cl= ients would have to supply.  Then Ryan's implementation would simply> be unable to support a non-empty authzid, since the routing has alre= ady
> happened and cannot be re-routed at that point, but that is oka= y --
> failing on non-empty authzid is the typical response if nothin= g else has
> been negotiated out-of-band between user and service pro= vider.  The
> "resource identity" would be a new concept introdu= ced by the OAuth
> mechanism, which is also fine.  The document = would have to be careful in
> explaining this concept so there is no = confusion with the authzid.
>
> I think I would prefer this, if the other alternative is to always
> require that the authz= id is non-empty.
>
> I know we have been over this a few times= , but what is the disadvantage
> with this approach?  Is it wors= e than requiring a non-empty authzid?
>
> /Simon
> _____= __________________________________________
> Kitten mailing list
&= gt; K= itten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten=

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

---368338466-641630669-1348097398=:58898-- From cantor.2@osu.edu Wed Sep 19 17:31: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 1249221F84F5 for ; Wed, 19 Sep 2012 17:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.750, 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 OyAk9HOLp78P for ; Wed, 19 Sep 2012 17:31:52 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 79F3621F8504 for ; Wed, 19 Sep 2012 17:31:52 -0700 (PDT) Received: from mail155-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Sep 2012 00:31:51 +0000 Received: from mail155-ch1 (localhost [127.0.0.1]) by mail155-ch1-R.bigfish.com (Postfix) with ESMTP id 231744801BF; Thu, 20 Sep 2012 00:31:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.40; KIP:(null); UIP:(null); IPV:NLI; H:CIO-KRC-HT02.osuad.osu.edu; RD:cio-krc-ht02.osuad.osu.edu; EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zzbb2dI98dI9371I1432Id6f1izz1202h1d1ah1d2ahzz8275bhz2fh87h2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail155-ch1: domain of osu.edu designates 164.107.81.40 as permitted sender) client-ip=164.107.81.40; envelope-from=cantor.2@osu.edu; helo=CIO-KRC-HT02.osuad.osu.edu ; suad.osu.edu ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail155-ch1 (localhost.localdomain [127.0.0.1]) by mail155-ch1 (MessageSwitch) id 134810110969229_26637; Thu, 20 Sep 2012 00:31:49 +0000 (UTC) Received: from CH1EHSMHS042.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail155-ch1.bigfish.com (Postfix) with ESMTP id 0D87342005F; Thu, 20 Sep 2012 00:31:49 +0000 (UTC) Received: from CIO-KRC-HT02.osuad.osu.edu (164.107.81.40) by CH1EHSMHS042.bigfish.com (10.43.69.251) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Sep 2012 00:31:48 +0000 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, 19 Sep 2012 20:31:48 -0400 From: "Cantor, Scott" To: Ryan Troll Thread-Topic: [kitten] Google and SASL OAuth Thread-Index: AQHNlqpAvUDtSOgX70WW0RrYcbNMvJeSbD4AgAASWwCAAAB9gIAABB8AgAAApoD//910AA== Date: Thu, 20 Sep 2012 00:31: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.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <7E0C1227819EE4468CB28A29548F118F@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ociotest.osu.edu Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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, 20 Sep 2012 00:31:53 -0000 On 9/19/12 6:35 PM, "Ryan Troll" wrote: > >Hm - let me see if I can articulate that better. > >Within the SASL implementation, without cracking open the OAuth >credential, how would you propose identifying the authz_id? I probably wouldn't, because I don't think it's appropriate to expect the SASL outer layer (that knows nothing about the mechanism) to go digging into the mechanism bits to find out where to pass along those bits for processing. It's a layer violation. >From the outside, it seems better to me to take a field with fairly out of band semantics already (the authzid) and simply profile it for this purpose than to break that layering. -- Scott From ve7jtb@ve7jtb.com Wed Sep 19 17:47: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 9B54221F844C for ; Wed, 19 Sep 2012 17:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 WogQWnpRBNhG for ; Wed, 19 Sep 2012 17:47: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 95E6721F8445 for ; Wed, 19 Sep 2012 17:47:43 -0700 (PDT) Received: by qafi29 with SMTP id i29so4108552qaf.10 for ; Wed, 19 Sep 2012 17:47:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=4ZDa5a3VCGqHdJoaIVA+NazFzT3IfGH2edJb0YSQs14=; b=fDS5Rv/vX3Hz9ho1kRNevBAR7qW9RfRbSapNQuIrPZnUXuVwwgHdNIHrMVszteNdDd 7T1qXv5Xl+fpUPTeTTgI2CPTWirO401bULB2IuzOrFcXRn/Fmq8uB8jrgODyH6O7Z2wf +sN4ISgtEMySqQ37SAQpLevfOfLzD/k1QU4aCmANuIWtUeOTarldO6dmVNygVi6P/ln6 4bpQh6prQswitkCyZGEn3fK6qNnJ1X9UGbr3clxh2kh5Z4M5t17RVAe2k4NEr4VLX2th xO30yGy5x0DV6htT8bblOwNEDILdcTGO5vbiZWieHOtkNXyZCqqncu89t7QVYDgr9q/l pxxA== Received: by 10.229.135.75 with SMTP id m11mr168234qct.74.1348102062919; Wed, 19 Sep 2012 17:47:42 -0700 (PDT) Received: from [192.168.1.211] (190-20-23-156.baf.movistar.cl. [190.20.23.156]) by mx.google.com with ESMTPS id ck11sm6044589qab.17.2012.09.19.17.47.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Sep 2012 17:47:42 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0467F1DE-DA89-4284-BDE4-2C50D3D8B94D" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: <1348097398.58898.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 21:47:33 -0300 Message-Id: References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <1348097398.58898.YahooMailNeo@web31801.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQkOPoQZU8sKAvinc3xR7xcuNrTje/OGnowzUq6qPsRjznayLmE7ZXhBp0KLs+c1baD/EImQ Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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, 20 Sep 2012 00:47:44 -0000 --Apple-Mail=_0467F1DE-DA89-4284-BDE4-2C50D3D8B94D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 The difference is that because we are starting with OAuth 1 the = oauth_token is being treated as if it is the Authentication identifier. = =20 Token A unique identifier issued by the server and used by the client to associate authenticated requests with the resource owner whose authorization is requested or has been obtained by the client. Tokens have a matching shared-secret that is used by the client to establish its ownership of the token, and its authority to represent the resource owner. It is the client and not the RS that uses the unique identifier to = associate it's requests with the delegated authority.=20 The token may not identify the resource owner or carry any specific = information about the resource.=20 It is proof that the possessor of the token and the token secret have a = grant to access some set of resources. While there may be an inferred identity of the resource owner (granter = of permission) attached to the token in some cases, I would not always = assume that semantic. To be safe the resource should be fully specified and the oauth_token = used as a verifier of the grant. I think you retrying to hard to make the oauth_token/access_token fit = the definition of authcid. John B. On 2012-09-19, at 8:29 PM, William Mills wrote: > OAuth 1 vs. 2 in the current discussion is irrelevant, we have the = same functionality requesth in either case. =20 >=20 >=20 >=20 >=20 > From: John Bradley > To: Simon Josefsson =20 > Cc: "kitten@ietf.org" =20 > Sent: Wednesday, September 19, 2012 4:18 PM > Subject: Re: [kitten] Google and SASL OAuth >=20 > In some ways trying to fit OAuth 1 is twisting the semantics. >=20 > Looking at it from a OAuth 2 bearer perspective.=20 >=20 > The email/xmpp address is the authentication identifier in the context = of the RS API . >=20 > The bearer token is just a long password in most respects. >=20 > Sending the email/resource identifier for the user as the authcid and = the token as another parameter may have the benefit of simplicity for = OAuth 2. >=20 > Trying to map the abstract concept of the user identity at the = authorization server in just adds complexity. >=20 > John B. >=20 > On 2012-09-19, at 7:13 PM, Simon Josefsson = wrote: >=20 > > Let's see if we can take a step back and (re-)analyze another = variant. > >=20 > > One way to resolve this issue without affecting the SASL design wrt > > authzid would be to add another key-value field (for example) = "resource > > identity" that transfers the identity that Ryan could route on and = that > > clients would have to supply. Then Ryan's implementation would = simply > > be unable to support a non-empty authzid, since the routing has = already > > happened and cannot be re-routed at that point, but that is okay -- > > failing on non-empty authzid is the typical response if nothing else = has > > been negotiated out-of-band between user and service provider. The > > "resource identity" would be a new concept introduced by the OAuth > > mechanism, which is also fine. The document would have to be = careful in > > explaining this concept so there is no confusion with the authzid. > >=20 > > I think I would prefer this, if the other alternative is to always > > require that the authzid is non-empty. > >=20 > > I know we have been over this a few times, but what is the = disadvantage > > with this approach? Is it worse than requiring a non-empty authzid? > >=20 > > /Simon > > _______________________________________________ > > 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 >=20 >=20 --Apple-Mail=_0467F1DE-DA89-4284-BDE4-2C50D3D8B94D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 The = difference is that because we are starting with OAuth 1 the =  oauth_token is being treated as if it is the Authentication = identifier.   

Token    A unique identifier issued by the =
server and used by the client
         to associate authenticated requests with the resource owner
         whose authorization is requested or has been obtained by the
         client.  Tokens have a matching shared-secret that is used by
         the client to establish its ownership of the token, and its
         authority to represent the resource owner.

It is the client and not the RS that = uses the unique identifier to associate it's requests with the delegated = authority. 

The token may not identify the = resource owner or carry any specific information about the = resource. 

It is proof that the possessor = of the token and the token secret have a grant to access some set of = resources.

While there may be an inferred = identity of the resource owner (granter of permission) attached to the = token in some cases, I would not always assume that = semantic.

To be safe the resource should be = fully specified and the oauth_token used as a verifier of the = grant.

I think you retrying to hard to make the = oauth_token/access_token fit the definition of = authcid.

John = B.



On 2012-09-19, at = 8:29 PM, William Mills <wmills@yahoo-inc.com> = wrote:

OAuth 1 vs. 2 in the current discussion is = irrelevant, we have the same functionality requesth in either = case. 




=
=
From: = John Bradley <ve7jtb@ve7jtb.com>
To: Simon Josefsson <simon@josefsson.org> =
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Wednesday, September 19, = 2012 4:18 PM
Subject: Re: [kitten] Google and SASL OAuth
=

In some ways trying to fit OAuth 1 is twisting the = semantics.

Looking at it from a OAuth 2 bearer perspective. =

The email/xmpp address is the authentication identifier in the = context of the RS API .

The bearer token is just a long password = in most respects.

Sending the email/resource identifier for the = user as the authcid and the token as another parameter may have the = benefit of simplicity for OAuth 2.

Trying to map the abstract = concept of the user identity at the authorization server in just adds = complexity.

John B.

On 2012-09-19, at 7:13 PM, Simon = Josefsson <simon@josefsson.org> = wrote:

> Let's see if we can take a step back and (re-)analyze another variant.
>
> One way to = resolve this issue without affecting the SASL design wrt
> authzid = would be to add another key-value field (for example) "resource
> = identity" that transfers the identity that Ryan could route on and = that
> clients would have to supply.  Then Ryan's = implementation would simply
> be unable to support a non-empty = authzid, since the routing has already
> happened and cannot be = re-routed at that point, but that is okay --
> failing on = non-empty authzid is the typical response if nothing else has
> = been negotiated out-of-band between user and service provider.  = The
> "resource identity" would be a new concept introduced by the = OAuth
> mechanism, which is also fine.  The document would = have to be careful in
> explaining this concept so there is no = confusion with the authzid.
>
> I think I would prefer this, if the other alternative is to always
> require that the = authzid is non-empty.
>
> I know we have been over this a = few times, but what is the disadvantage
> with this = approach?  Is it worse than requiring a non-empty authzid?
> =
> /Simon
> = _______________________________________________
> 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

=
=

= --Apple-Mail=_0467F1DE-DA89-4284-BDE4-2C50D3D8B94D-- From wmills@yahoo-inc.com Wed Sep 19 18:24: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 DAF9A21F8514 for ; Wed, 19 Sep 2012 18:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.585 X-Spam-Level: X-Spam-Status: No, score=-17.585 tagged_above=-999 required=5 tests=[AWL=0.013, 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 EJm+RsvlhtFT for ; Wed, 19 Sep 2012 18:24:01 -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 SMTP id 302AD21F8516 for ; Wed, 19 Sep 2012 18:24:00 -0700 (PDT) Received: from [98.139.91.66] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 20 Sep 2012 01:23:57 -0000 Received: from [98.139.91.9] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 20 Sep 2012 01:23:56 -0000 Received: from [127.0.0.1] by omp1009.mail.sp2.yahoo.com with NNFMP; 20 Sep 2012 01:23:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 902099.64426.bm@omp1009.mail.sp2.yahoo.com Received: (qmail 12290 invoked by uid 60001); 20 Sep 2012 01:23:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348104236; bh=LyWVrzgeUhKlp/7CRDZDq0FQEIH/6QX9T7IB+wuD1tk=; 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=haB6duTS0/UBNfTc5gH/6XrVzsiAlfXZ/fFuMrW9L8M6QyQ5F2Yma4ZzlMLtbUry+f5TMYEvfrDh7W/6vPG1XsbAsRtb181rkjLf1w+1tZcWqL2oU3VKFVQbfiAxmbDSutdEgN5Hd54INkuJUroKCoBRShVUwlJZw0xjGt7h/EU= 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=GV6KLWOV0Wke3i/yee+ScuLCFTeIRKDhkewmP7HedhwYkaKp7mD3ELve64JbVatTkL87u97TTJMaFJUE3Rnorh1Y+Xl2lXXOBQ80m7T7TLa3BDdAsgJKFMLcuPEmq8Y13aQ0VYJJUWcYO4yWcol+MryffoayoVAAjHrPB9A427Y=; X-YMail-OSG: uNLuslUVM1nhvAMXEpArLTC8Hq1wwRb23e4vzQu09MSpPzM Vl4oVcjHCKdFac_7pDvvZcmS419nsxHEbta4tsRMuAntZVb6VSdp3KcZftHR 8y33wafUAyItiuMJbkJMxRZWbg96o53zXq5RnlWvMDi50Bhz0iPPR_F71Hiz iOjDVMEP_NinyWTYcNlHiTbkyMlnWnqeAbaKJ16kIvaxO494f9GVO6Ek.CYo ur8X4CM8RtzPcE9whzIzyHakX0fBxd89W6ONVVzOgUpmJ_beoBRFeBPFsyeW vS6Al4b.YLBOPqtJFPbDo0ltIc3Y7ewucMzjXC3OouF8uWGB0ROQ1eJxAXPO FStpBEnr46znjSIYgoK4cIVNBuWUg.556gGWBaAHPugeTFlQx1_4aTS739ZL .e2ELE4QlEhGgVhHpOgflb3rBVN4uvaeXSLN1mCbs9lVn Received: from [99.31.212.42] by web31810.mail.mud.yahoo.com via HTTP; Wed, 19 Sep 2012 18:23:56 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <1348097398.58898.YahooMailNeo@web31801.mail.mud.yahoo.com> Message-ID: <1348104236.2766.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 18:23:56 -0700 (PDT) From: William Mills To: John Bradley In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1935884094-561139530-1348104236=:2766" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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, 20 Sep 2012 01:24:04 -0000 --1935884094-561139530-1348104236=:2766 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable You are mistaken.=A0 The draft asserts that the token must carry or allow t= he server to derive an appropriate identity to be used as authcid.=0A=0A=0A= =0A=0A=0A>________________________________=0A> From: John Bradley =0A>To: William Mills =0A>Cc: Simon Josefs= son ; "kitten@ietf.org" =0A>Sent: We= dnesday, September 19, 2012 5:47 PM=0A>Subject: Re: [kitten] Google and SAS= L OAuth=0A> =0A>=0A>The difference is that because we are starting with OAu= th 1 the =A0oauth_token is being treated as if it is the Authentication ide= ntifier. =A0=A0=0A>=0A>=0A>Token A unique identifier issued by the serve= r and used by the client to associate authenticated requests with the resou= rce owner whose authorization is requested or has been obtained by the clie= nt. Tokens have a matching shared-secret that is used by the client to est= ablish its ownership of the token, and its authority to represent the resou= rce owner. =0A>=0A>=0A>It is the client and not the RS that uses the unique= identifier to associate it's requests with the delegated authority.=A0=0A>= =0A>=0A>The token may not identify the resource owner or carry any specific= information about the resource.=A0=0A>=0A>=0A>It is proof that the possess= or of the token and the token secret have a grant to access some set of res= ources.=0A>=0A>=0A>While there may be an inferred identity of the resource = owner (granter of permission) attached to the token in some cases, I would = not always assume that semantic.=0A>=0A>=0A>To be safe the resource should = be fully specified and the oauth_token used as a verifier of the grant.=0A>= =0A>=0A>I think you retrying to hard to make the oauth_token/access_token f= it the definition of authcid.=0A>=0A>=0A>John B.=0A>=0A>=0A>=0A>=0A>=0A>=0A= >On 2012-09-19, at 8:29 PM, William Mills wrote:=0A>= =0A>OAuth 1 vs. 2 in the current discussion is irrelevant, we have the same= functionality requesth in either case.=A0 =0A>>=0A>>=0A>>=0A>>=0A>>=0A>>= =0A>>=0A>>=0A>>>________________________________=0A>>> From: John Bradley <= ve7jtb@ve7jtb.com>=0A>>>To: Simon Josefsson =0A>>>Cc:= "kitten@ietf.org" =0A>>>Sent: Wednesday, September 19, 2= 012 4:18 PM=0A>>>Subject: Re: [kitten] Google and SASL OAuth=0A>>> =0A>>>In= some ways trying to fit OAuth 1 is twisting the semantics.=0A>>>=0A>>>Look= ing at it from a OAuth 2 bearer perspective. =0A>>>=0A>>>The email/xmpp add= ress is the authentication identifier in the context of the RS API .=0A>>>= =0A>>>The bearer token is just a long password in most respects.=0A>>>=0A>>= >Sending the email/resource identifier for the user as the authcid and the = token as another parameter may have the benefit of simplicity for OAuth 2.= =0A>>>=0A>>>Trying to map the abstract concept of the user identity at the = authorization server in just adds complexity.=0A>>>=0A>>>John B.=0A>>>=0A>>= >On 2012-09-19, at 7:13 PM, Simon Josefsson wrote:=0A= >>>=0A>>>> Let's see if we can take a=0A step back and (re-)analyze another= variant.=0A>>>> =0A>>>> One way to resolve this issue without affecting th= e SASL design wrt=0A>>>> authzid would be to add another key-value field (f= or example) "resource=0A>>>> identity" that transfers the identity that Rya= n could route on and that=0A>>>> clients would have to supply.=A0 Then Ryan= 's implementation would simply=0A>>>> be unable to support a non-empty auth= zid, since the routing has already=0A>>>> happened and cannot be re-routed = at that point, but that is okay --=0A>>>> failing on non-empty authzid is t= he typical response if nothing else has=0A>>>> been negotiated out-of-band = between user and service provider.=A0 The=0A>>>> "resource identity" would = be a new concept introduced by the OAuth=0A>>>> mechanism, which is also fi= ne.=A0 The document would have to be careful in=0A>>>> explaining this conc= ept so there is no confusion with the authzid.=0A>>>> =0A>>>> I think I wou= ld prefer=0A this, if the other alternative is to always=0A>>>> require tha= t the authzid is non-empty.=0A>>>> =0A>>>> I know we have been over this a = few times, but what is the disadvantage=0A>>>> with this approach?=A0 Is it= worse than requiring a non-empty authzid?=0A>>>> =0A>>>> /Simon=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/kitte= n=0A>>>=0A>>>=0A>>>=0A>=0A>=0A> --1935884094-561139530-1348104236=:2766 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
You are m= istaken.  The draft asserts that the token must carry or allow the ser= ver to derive an appropriate identity to be used as authcid.
=

From: J= ohn Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: Simon Josefsson <simon@jose= fsson.org>; "kitten@ietf.org" <kitten@ietf.org>
Sent: Wednesday, September 19, 2012 5:47 PM
Subject: Re: [kitten] Google an= d SASL OAuth

The diff= erence is that because we are starting with OAuth 1 the  oauth_token i= s being treated as if it is the Authentication identifier.   
Token    A unique identifier issued by t=
he server and used by the client=0A         to associate authenticated requ=
ests with the resource owner=0A         whose authorization is requested or=
 has been obtained by the=0A         client.  Tokens have a matching shared=
-secret that is used by=0A         the client to establish its ownership of=
 the token, and its=0A         authority to represent the resource owner.=
=0A

It is the client and not the RS that use= s the unique identifier to associate it's requests with the delegated autho= rity. 

The token may not identify the resourc= e owner or carry any specific information about the resource. 

It is proof that the possessor of the token and the token= secret have a grant to access some set of resources.

<= div>While there may be an inferred identity of the resource owner (granter = of permission) attached to the token in some cases, I would not always assu= me that semantic.

To be safe the resource should b= e fully specified and the oauth_token used as a verifier of the grant.

I think you retrying to hard to make the oauth_token/a= ccess_token fit the definition of authcid.

John B.=



On 2012-09-19, at 8:29 PM, William Mills <wmills@yahoo= -inc.com> wrote:

OAuth 1 vs. 2 in the current discussion is irrelevant, we h= ave the same functionality requesth in either case. 


=

=
From: John= Bradley <ve7jtb@ve7jtb.com>
To: Simon Josefsson <simon@josefsson.org>
Cc: "kitten@ietf.o= rg" <kitten@ietf.org>
Sent: Wednesday, September 19= , 2012 4:18 PM
Subject:= Re: [kitten] Google and SASL OAuth

In some ways try= ing to fit OAuth 1 is twisting the semantics.

Looking at it from a O= Auth 2 bearer perspective.

The email/xmpp address is the authentication identifier in the con= text of the RS API .

The bearer token is just a long password in mos= t respects.

Sending the email/resource identifier for the user as th= e authcid and the token as another parameter may have the benefit of simpli= city for OAuth 2.

Trying to map the abstract concept of the user ide= ntity at the authorization server in just adds complexity.

John B.
On 2012-09-19, at 7:13 PM, Simon Josefsson <simon@josefsson.org> wrote:

> Let's see if= we can take a=0A step back and (re-)analyze another variant.
>
&= gt; One way to resolve this issue without affecting the SASL design wrt
= > authzid would be to add another key-value field (for example) "resourc= e
> identity" that transfers the identity that Ryan could route on an= d that
> clients would have to supply.  Then Ryan's implementati= on would simply
> be unable to support a non-empty authzid, since the= routing has already
> happened and cannot be re-routed at that point= , but that is okay --
> failing on non-empty authzid is the typical r= esponse if nothing else has
> been negotiated out-of-band between use= r and service provider.  The
> "resource identity" would be a ne= w concept introduced by the OAuth
> mechanism, which is also fine.&nb= sp; The document would have to be careful in
> explaining this concep= t so there is no confusion with the authzid.
>
> I think I wou= ld prefer=0A this, if the other alternative is to always
> require th= at the authzid is non-empty.
>
> I know we have been over this= a few times, but what is the disadvantage
> with this approach? = ; Is it worse than requiring a non-empty authzid?
>
> /Simon> _______________________________________________
> Kitten maili= ng list
> Kitten@ietf.org
> <= a rel=3D"nofollow" target=3D"_blank" href=3D"https://www.ietf.org/mailman/l= istinfo/kitten">https://www.ietf.org/mailman/listinfo/kitten

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


=



--1935884094-561139530-1348104236=:2766-- From ve7jtb@ve7jtb.com Wed Sep 19 18:47: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 5AD4821F84D1 for ; Wed, 19 Sep 2012 18:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YtN8kzqla3NN for ; Wed, 19 Sep 2012 18:47: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 39FBF21F84CD for ; Wed, 19 Sep 2012 18:47:57 -0700 (PDT) Received: by qafi29 with SMTP id i29so19285qaf.10 for ; Wed, 19 Sep 2012 18:47:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Y1c1ZrJhb1GRMESm/b8cP3Sll+WgQTwrx4NBNdpgpPg=; b=S1lo9jaIAEiTI2n1A7734LOAi/FzhqfcldIPtb+jqsaxftPIjXa3yz1roOE2MLpJcd w10ugrUIrVkXMxpGJ+rauoTi8pPfr5hr1prhELnJkt2TCe00uLabU9wDChEOSky7If8R 1DYkNPyZABah02hJKdms7JyuBmD9VHtnonED5LYxO3CJtud3KpoPDkZjRiIRkjNUTrwz /EIBKENRuksPogiDUKFgggPmMBmKaiAU6uHWTmknLig+wRDp1X8huO6sRIflZ2Fqz4+M X106ZFtLB3pZqj+m7dm+k8RXx1NvwuVJrWxWWfcCeDMIAXBHGvkioZ1VrXeBnJ7XEWVP fu8A== Received: by 10.229.136.143 with SMTP id r15mr227347qct.99.1348105676455; Wed, 19 Sep 2012 18:47:56 -0700 (PDT) Received: from [192.168.1.211] (190-20-23-156.baf.movistar.cl. [190.20.23.156]) by mx.google.com with ESMTPS id et6sm6240948qab.8.2012.09.19.18.47.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Sep 2012 18:47:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D8AFA292-06ED-417E-9218-B06C982D72B0" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: <1348104236.2766.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 22:47:46 -0300 Message-Id: <67E233FF-C465-457E-A744-EB1C878E7758@ve7jtb.com> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <1348097398.58898.YahooMailNeo@web31801.mail.mud.yahoo.com> <1348104236.2766.YahooMailNeo@web31810.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQnjptEl//1QBKvEgqqyF6PCgM7I2SOoxLSVBo/fWgoVmvUthDAglMDVZl6nqUMR+Iw9PDKt Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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, 20 Sep 2012 01:47:58 -0000 --Apple-Mail=_D8AFA292-06ED-417E-9218-B06C982D72B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 That is a requirement you are adding and not something in OAuth. It may be easier to send an explicit authcid and use the access_token as = intended to convey the authorization and not the identity. It will probably require less retooling of the OAuth Authorization = server. =20 It is effectively what Google is doing with XAUTH2. I am not a SASL expert in any way, just observing you seem to be = fighting tying to fit the OAuth semantics into a box they might not = precisely fit. John B. On 2012-09-19, at 10:23 PM, William Mills wrote: > You are mistaken. The draft asserts that the token must carry or = allow the server to derive an appropriate identity to be used as = authcid. >=20 > From: John Bradley > To: William Mills =20 > Cc: Simon Josefsson ; "kitten@ietf.org" = =20 > Sent: Wednesday, September 19, 2012 5:47 PM > Subject: Re: [kitten] Google and SASL OAuth >=20 > The difference is that because we are starting with OAuth 1 the = oauth_token is being treated as if it is the Authentication identifier. = =20 >=20 > Token A unique identifier issued by the server and used by the = client > to associate authenticated requests with the resource owner > whose authorization is requested or has been obtained by the > client. Tokens have a matching shared-secret that is used by > the client to establish its ownership of the token, and its > authority to represent the resource owner. >=20 > It is the client and not the RS that uses the unique identifier to = associate it's requests with the delegated authority.=20 >=20 > The token may not identify the resource owner or carry any specific = information about the resource.=20 >=20 > It is proof that the possessor of the token and the token secret have = a grant to access some set of resources. >=20 > While there may be an inferred identity of the resource owner (granter = of permission) attached to the token in some cases, I would not always = assume that semantic. >=20 > To be safe the resource should be fully specified and the oauth_token = used as a verifier of the grant. >=20 > I think you retrying to hard to make the oauth_token/access_token fit = the definition of authcid. >=20 > John B. >=20 >=20 >=20 > On 2012-09-19, at 8:29 PM, William Mills wrote: >=20 >> OAuth 1 vs. 2 in the current discussion is irrelevant, we have the = same functionality requesth in either case. =20 >>=20 >>=20 >>=20 >>=20 >> From: John Bradley >> To: Simon Josefsson =20 >> Cc: "kitten@ietf.org" =20 >> Sent: Wednesday, September 19, 2012 4:18 PM >> Subject: Re: [kitten] Google and SASL OAuth >>=20 >> In some ways trying to fit OAuth 1 is twisting the semantics. >>=20 >> Looking at it from a OAuth 2 bearer perspective.=20 >>=20 >> The email/xmpp address is the authentication identifier in the = context of the RS API . >>=20 >> The bearer token is just a long password in most respects. >>=20 >> Sending the email/resource identifier for the user as the authcid and = the token as another parameter may have the benefit of simplicity for = OAuth 2. >>=20 >> Trying to map the abstract concept of the user identity at the = authorization server in just adds complexity. >>=20 >> John B. >>=20 >> On 2012-09-19, at 7:13 PM, Simon Josefsson = wrote: >>=20 >> > Let's see if we can take a step back and (re-)analyze another = variant. >> >=20 >> > One way to resolve this issue without affecting the SASL design wrt >> > authzid would be to add another key-value field (for example) = "resource >> > identity" that transfers the identity that Ryan could route on and = that >> > clients would have to supply. Then Ryan's implementation would = simply >> > be unable to support a non-empty authzid, since the routing has = already >> > happened and cannot be re-routed at that point, but that is okay -- >> > failing on non-empty authzid is the typical response if nothing = else has >> > been negotiated out-of-band between user and service provider. The >> > "resource identity" would be a new concept introduced by the OAuth >> > mechanism, which is also fine. The document would have to be = careful in >> > explaining this concept so there is no confusion with the authzid. >> >=20 >> > I think I would prefer this, if the other alternative is to always >> > require that the authzid is non-empty. >> >=20 >> > I know we have been over this a few times, but what is the = disadvantage >> > with this approach? Is it worse than requiring a non-empty = authzid? >> >=20 >> > /Simon >> > _______________________________________________ >> > 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 >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_D8AFA292-06ED-417E-9218-B06C982D72B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 That = is a requirement you are adding and not something in = OAuth.

It may be easier to send an explicit authcid = and use the access_token as intended to convey the authorization and not = the identity.

It will probably require less = retooling of the OAuth Authorization server. =  

It is effectively what Google is doing = with XAUTH2.

I am not a SASL expert in any way, = just observing you seem to be fighting tying to fit the OAuth semantics = into a box they might not precisely fit.

John = B.

On 2012-09-19, at 10:23 PM, William Mills = <wmills@yahoo-inc.com> = wrote:

You are mistaken.  The draft asserts that the = token must carry or allow the server to derive an appropriate identity = to be used as authcid.

=
=
From: = John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills@yahoo-inc.com> =
Cc: Simon Josefsson = <simon@josefsson.org>; "kitten@ietf.org" <kitten@ietf.org>
Sent: Wednesday, September 19, = 2012 5:47 PM
Subject: Re: [kitten] Google and SASL OAuth
=

The difference is that = because we are starting with OAuth 1 the  oauth_token is being = treated as if it is the Authentication identifier. =   

Token    A =
unique identifier issued by the server and used by the client
         to associate authenticated requests with the resource owner
         whose authorization is requested or has been obtained by the
         client.  Tokens have a matching shared-secret that is used by
         the client to establish its ownership of the token, and its
         authority to represent the resource owner.

It is the client and not the RS that = uses the unique identifier to associate it's requests with the delegated = authority. 

The token may not identify the = resource owner or carry any specific information about the = resource. 

It is proof that the possessor = of the token and the token secret have a grant to access some set of = resources.

While there may be an inferred = identity of the resource owner (granter of permission) attached to the = token in some cases, I would not always assume that = semantic.

To be safe the resource should be = fully specified and the oauth_token used as a verifier of the = grant.

I think you retrying to hard to make the = oauth_token/access_token fit the definition of = authcid.

John = B.



On 2012-09-19, at = 8:29 PM, William Mills <wmills@yahoo-inc.com> = wrote:

OAuth 1 vs. 2 in the current discussion is = irrelevant, we have the same functionality requesth in either = case. 




From: John Bradley <ve7jtb@ve7jtb.com>
To: Simon Josefsson <simon@josefsson.org> =
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Wednesday, September 19, = 2012 4:18 PM
Subject: = Re: [kitten] Google and SASL OAuth

In some ways = trying to fit OAuth 1 is twisting the semantics.

Looking at it = from a OAuth 2 bearer perspective.

The email/xmpp address is the authentication identifier in the = context of the RS API .

The bearer token is just a long password = in most respects.

Sending the email/resource identifier for the = user as the authcid and the token as another parameter may have the = benefit of simplicity for OAuth 2.

Trying to map the abstract = concept of the user identity at the authorization server in just adds = complexity.

John B.

On 2012-09-19, at 7:13 PM, Simon = Josefsson <simon@josefsson.org> = wrote:

> Let's see if we can take a step back and (re-)analyze another variant.
>
> One way to = resolve this issue without affecting the SASL design wrt
> authzid = would be to add another key-value field (for example) "resource
> = identity" that transfers the identity that Ryan could route on and = that
> clients would have to supply.  Then Ryan's = implementation would simply
> be unable to support a non-empty = authzid, since the routing has already
> happened and cannot be = re-routed at that point, but that is okay --
> failing on = non-empty authzid is the typical response if nothing else has
> = been negotiated out-of-band between user and service provider.  = The
> "resource identity" would be a new concept introduced by the = OAuth
> mechanism, which is also fine.  The document would = have to be careful in
> explaining this concept so there is no = confusion with the authzid.
>
> I think I would prefer this, if the other alternative is to always
> require that the = authzid is non-empty.
>
> I know we have been over this a = few times, but what is the disadvantage
> with this = approach?  Is it worse than requiring a non-empty authzid?
> =
> /Simon
> = _______________________________________________
> 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


=
=



=

= --Apple-Mail=_D8AFA292-06ED-417E-9218-B06C982D72B0-- From mrex@sap.com Wed Sep 19 21:10: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 DB12321F84F0 for ; Wed, 19 Sep 2012 21:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.177 X-Spam-Level: X-Spam-Status: No, score=-10.177 tagged_above=-999 required=5 tests=[AWL=0.072, 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 sI0X+lb5hNiU for ; Wed, 19 Sep 2012 21:10:50 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id DBD1021F84D6 for ; Wed, 19 Sep 2012 21:10:49 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q8K4AmjJ019732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Sep 2012 06:10:48 +0200 (MEST) In-Reply-To: <87sjbec9u4.fsf@latte.josefsson.org> To: Simon Josefsson Date: Thu, 20 Sep 2012 06:10:48 +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: <20120920041048.05B941A23F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out 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: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 04:10:51 -0000 I don't know whether your question was already answered (I'm trying to catch up on old email...) Simon Josefsson wrote: > 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. It is an error to pass a context-level token to the local context establishment iteration call (gss_init_sec_context() on the initiator side and gss_accept_sec_context() on the acceptor side) once the security context has been established, i.e. when the previous call returned GSS_S_COMPLETE. You have to pass such a context token to gss_process_context_token() instead. This situation can arise when an error is detected on the final leg of the handshake by the recipient of the final regular context level token, and the implementation wants to send back an error token. See the description of gss_process_context_token() in rfc2743, Section 2.2.4 GSS_Process_context_token call: http://tools.ietf.org/html/rfc2743#page-55 -Martin From wmills@yahoo-inc.com Wed Sep 19 21: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 1D88621F848F for ; Wed, 19 Sep 2012 21:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.587 X-Spam-Level: X-Spam-Status: No, score=-17.587 tagged_above=-999 required=5 tests=[AWL=0.011, 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 eHrCMUZ5SzMy for ; Wed, 19 Sep 2012 21:40:27 -0700 (PDT) Received: from nm6.bullet.mail.sp2.yahoo.com (nm6.bullet.mail.sp2.yahoo.com [98.139.91.76]) by ietfa.amsl.com (Postfix) with SMTP id F25DE21E8055 for ; Wed, 19 Sep 2012 21:40:25 -0700 (PDT) Received: from [98.139.91.63] by nm6.bullet.mail.sp2.yahoo.com with NNFMP; 20 Sep 2012 04:40:20 -0000 Received: from [98.139.91.11] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 20 Sep 2012 04:40:20 -0000 Received: from [127.0.0.1] by omp1011.mail.sp2.yahoo.com with NNFMP; 20 Sep 2012 04:40:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 332666.94371.bm@omp1011.mail.sp2.yahoo.com Received: (qmail 11464 invoked by uid 60001); 20 Sep 2012 04:40:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348116019; bh=dYeM+3s387wfUyj80A1Ba5LTy/T3l8J4tLl1neHdjKA=; 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=P71SWOfnCUDeq3lUwAGdD/XW3pZCVrGldG5wbCFaL81lgEVpmBXc8kX6kpu6iSrX9zhNk13cLjGiRIK19U1mImFNJjX4L7Ir0qyo3FThRhWAMAK9VgQfvP3IlYL742odeuIKghS4sCKDJ2TX6w5lfUgfCXMkf9POc+AEmYX6IVk= 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=IEE4keLhYte3JYNj0uBe8UcrAAZU8Jj8WM2sJz9rkfrjO+fvxYLAZ5VEUYgo59iJFkeaQNCD2EThzHBtKsHhEscYbygpzzHC7BXe/CutapS46Oroc3+6FGbcQkh7FGRXXaHeaA3yrCemRiSMbzqe6rdvV0tLsOgiIM+5bwyyBJs=; X-YMail-OSG: xBUqzRYVM1lp6iTMr8H52uG8nks9HrPsBAc8E0ufVbCwcwA UcmUcYoMpwAj0GuPzbRDHZRpgR38fJR42m.loUBywOhGI2jqByutc7HKBFgl jxYXzKD7pOEzG2YQiOU7J5knGrTu10qRuJuYOJSgiLGmOWJKsGgXSbtSx4Nu 5Y4kJezkoXVyaXlktxt98VJ4XU2Y6enphYoMcq8I0rvssS0h_vf84Bs0Z1an TZZz4.SFgZppw_ZhWpM1aXptIpR_urbR6PN.PvyvVOinYXaCc0iHVcfOQjl7 ngSNmZJ3Rxr8adJLc1sanRabY8K0jTb9w4MghclhrFKu2DO3Zrer74shxery iebQkfz0BzMl7bsMIjxCfjRRAE3HoZd3nGEYks35ritn05r3Fhm0DuSRpEYN QZNaXm0UpGGGiMuknbB1j_iPoc7Mgk_wIhSvTzB4PIfc- Received: from [99.31.212.42] by web31804.mail.mud.yahoo.com via HTTP; Wed, 19 Sep 2012 21:40:19 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <1348097398.58898.YahooMailNeo@web31801.mail.mud.yahoo.com> <1348104236.2766.YahooMailNeo@web31810.mail.mud.yahoo.com> <67E233FF-C465-457E-A744-EB1C878E7758@ve7jtb.com> Message-ID: <1348116019.2331.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 21:40:19 -0700 (PDT) From: William Mills To: John Bradley In-Reply-To: <67E233FF-C465-457E-A744-EB1C878E7758@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-1360300513-1348116019=:2331" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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, 20 Sep 2012 04:40:34 -0000 --835683298-1360300513-1348116019=:2331 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Now see, I think it's you that's trying to add something to OAuth in a diff= erent way that isn't there.=A0 OAuth, especially with the password grant ha= s *no* guaranteed concept of a resource identifier.=A0 In the initial stage= s there might be a signed request, a client ID, or a registered callback, b= ut that's not guaranteed.=0A=0AYes, I'm requiring that OAuth implementation= s that wish to support SASL will need the additional feature of being able = to provide an authcid.=A0 I did not think that was unreasonable.=0A=0A=0A= =0A=0A=0A>________________________________=0A> From: John Bradley =0A>To: William Mills =0A>Cc: Simon Josefs= son ; "kitten@ietf.org" =0A>Sent: We= dnesday, September 19, 2012 6:47 PM=0A>Subject: Re: [kitten] Google and SAS= L OAuth=0A> =0A>=0A>That is a requirement you are adding and not something = in OAuth.=0A>=0A>=0A>It may be easier to send an explicit authcid and use t= he access_token as intended to convey the authorization and not the identit= y.=0A>=0A>=0A>It will probably require less retooling of the OAuth Authoriz= ation server. =A0=0A>=0A>=0A>It is effectively what Google is doing with XA= UTH2.=0A>=0A>=0A>I am not a SASL expert in any way, just observing you seem= to be fighting tying to fit the OAuth semantics into a box they might not = precisely fit.=0A>=0A>=0A>John B.=0A>=0A>=0A>On 2012-09-19, at 10:23 PM, Wi= lliam Mills wrote:=0A>=0A>You are mistaken.=A0 The d= raft asserts that the token must carry or allow the server to derive an app= ropriate identity to be used as authcid.=0A>>=0A>>=0A>>=0A>>=0A>>>_________= _______________________=0A>>> From: John Bradley =0A>>>T= o: William Mills =0A>>>Cc: Simon Josefsson ; "kitten@ietf.org" =0A>>>Sent: Wednesday, Se= ptember 19, 2012 5:47 PM=0A>>>Subject: Re: [kitten] Google and SASL OAuth= =0A>>> =0A>>>=0A>>>The difference is that because we are starting with OAut= h 1 the =A0oauth_token is being treated as if it is the Authentication iden= tifier. =A0=A0=0A>>>=0A>>>=0A>>>Token A unique identifier issued by the = server and used by the client to associate authenticated requests with the = resource owner whose authorization is requested or has been obtained by the= client. Tokens have a matching shared-secret that is used by the client t= o establish its ownership of the token, and its authority to represent the = resource owner. =0A>>>=0A>>>=0A>>>It is the client and not the RS that uses= the unique identifier to associate it's requests with the delegated author= ity.=A0=0A>>>=0A>>>=0A>>>The token may not identify the resource owner or c= arry any specific information about the resource.=A0=0A>>>=0A>>>=0A>>>It is= proof that the possessor of the token and the token secret have a grant to= access some set of resources.=0A>>>=0A>>>=0A>>>While there may be an infer= red identity of the resource owner (granter of permission) attached to the = token in some cases, I would not always assume that semantic.=0A>>>=0A>>>= =0A>>>To be safe the resource should be fully specified and the oauth_token= used as a verifier of the grant.=0A>>>=0A>>>=0A>>>I think you retrying to = hard to make the oauth_token/access_token fit the definition of authcid.=0A= >>>=0A>>>=0A>>>John B.=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>On 2012-09-= 19, at 8:29 PM, William Mills wrote:=0A>>>=0A>>>OAut= h 1 vs. 2 in the current discussion is irrelevant, we have the same functio= nality requesth in either case.=A0 =0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>= >>=0A>>>>=0A>>>>=0A>>>>>________________________________=0A>>>>> From: John= Bradley =0A>>>>>To: Simon Josefsson =0A>>>>>Cc: "kitten@ietf.org" =0A>>>>>Sent: Wednesday,= September 19, 2012 4:18 PM=0A>>>>>Subject: Re: [kitten] Google and SASL OA= uth=0A>>>>> =0A>>>>>In some ways trying to fit OAuth 1 is twisting the sema= ntics.=0A>>>>>=0A>>>>>Looking at it from a OAuth 2 bearer perspective. =0A>= >>>>=0A>>>>>The email/xmpp address is the authentication identifier in the = context of the RS API .=0A>>>>>=0A>>>>>The bearer token is just a long pass= word in most respects.=0A>>>>>=0A>>>>>Sending the email/resource identifier= for the user as the authcid and the token as another parameter may have th= e benefit of simplicity for OAuth 2.=0A>>>>>=0A>>>>>Trying to map the abstr= act concept of the user identity at the authorization server in just adds c= omplexity.=0A>>>>>=0A>>>>>John B.=0A>>>>>=0A>>>>>On 2012-09-19, at 7:13 PM,= Simon Josefsson wrote:=0A>>>>>=0A>>>>>> Let's see if= we can take a=0A step back and (re-)analyze another variant.=0A>>>>>> =0A>= >>>>> One way to resolve this issue without affecting the SASL design wrt= =0A>>>>>> authzid would be to add another key-value field (for example) "re= source=0A>>>>>> identity" that transfers the identity that Ryan could route= on and that=0A>>>>>> clients would have to supply.=A0 Then Ryan's implemen= tation would simply=0A>>>>>> be unable to support a non-empty authzid, sinc= e the routing has already=0A>>>>>> happened and cannot be re-routed at that= point, but that is okay --=0A>>>>>> failing on non-empty authzid is the ty= pical response if nothing else has=0A>>>>>> been negotiated out-of-band bet= ween user and service provider.=A0 The=0A>>>>>> "resource identity" would b= e a new concept introduced by the OAuth=0A>>>>>> mechanism, which is also f= ine.=A0 The document would have to be careful in=0A>>>>>> explaining this c= oncept so there is no confusion with the authzid.=0A>>>>>> =0A>>>>>> I thin= k I would prefer=0A this, if the other alternative is to always=0A>>>>>> re= quire that the authzid is non-empty.=0A>>>>>> =0A>>>>>> I know we have been= over this a few times, but what is the disadvantage=0A>>>>>> with this app= roach?=A0 Is it worse than requiring a non-empty authzid?=0A>>>>>> =0A>>>>>= > /Simon=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>>>>>=0A>>>>>=0A>>>=0A>>>= =0A>>>=0A>=0A>=0A> --835683298-1360300513-1348116019=:2331 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Now see, = I think it's you that's trying to add something to OAuth in a different way= that isn't there.  OAuth, especially with the password grant has *no*= guaranteed concept of a resource identifier.  In the initial stages t= here might be a signed request, a client ID, or a registered callback, but = that's not guaranteed.

Yes, I'm requiring that OAuth implementations= that wish to support SASL will need the additional feature of being able t= o provide an authcid.  I did not think that was unreasonable.
=

=
From:= John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills@yahoo-inc.com>=
Cc: Simon Josefsson &= lt;simon@josefsson.org>; "kitten@ietf.org" <kitten@ietf.org>
= Sent: Wednesday, September= 19, 2012 6:47 PM
Subject:= Re: [kitten] Google and SASL OAuth

That is a requirement you are adding and not something in= OAuth.

It may be easier to send an explicit authcid and= use the access_token as intended to convey the authorization and not the i= dentity.

It will probably require less retooling o= f the OAuth Authorization server.  

It is effectively wh= at Google is doing with XAUTH2.

I am not a SASL ex= pert in any way, just observing you seem to be fighting tying to fit the OA= uth semantics into a box they might not precisely fit.

=
John B.

On 2012-09-19, at 10:23 PM, William Mi= lls <wmills@yahoo-inc.com&g= t; wrote:

You are mistaken.  The draft asserts that the token must carry or all= ow the server to derive an appropriate identity to be used as authcid.
<= div>

From: John Bradle= y <ve7jtb@ve7jtb.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: Simon Josefsson <simon@josefsson.org>;=0A "kitten@ietf.org" <kitten@ie= tf.org>
Sent: W= ednesday, September 19, 2012 5:47 PM
Subject: Re: [kitten] Google and SASL OAuth
The difference is that because we are starti= ng with OAuth 1 the  oauth_token is being treated as if it is the Auth= entication identifier.   

To=
ken    A unique identifier issued by the server and used by the client=0A  =
       to associate authenticated requests with the resource owner=0A      =
   whose authorization is requested or has been obtained by the=0A         =
client.  Tokens have a matching shared-secret that is used by=0A         th=
e client to establish its ownership of the token, and its=0A         author=
ity to represent the resource owner.=0A

It i= s the client and not the RS that uses the unique identifier to associate it= 's requests with the delegated authority. 

Th= e token may not identify the resource owner or carry any specific informati= on about the resource. 

It is proof that the = possessor of the token and the token secret have a grant to access some set= of resources.

While there may be an inferred iden= tity of the resource owner (granter of permission) attached to the token in= some cases, I would not always assume that semantic.

<= div>To be safe the resource should be fully specified and the oauth_token u= sed as a verifier of the grant.

I think you retryi= ng to hard to make the oauth_token/access_token fit the definition of authc= id.

John B.



=
On 2012-09-19, at 8:29=0A PM, William Mills <wmills@yahoo-inc.com> wrote:

OAuth 1 vs. 2 in the cu= rrent discussion is irrelevant, we have the same functionality requesth in = either case. 




From: John Bradley <ve7jtb@ve7jtb.com>
To: Simon Josefsson <simon@josefsson.org>
Cc: "kitten@ietf.o= rg" <kitten@ietf.org>
Sent: Wednesday, September 19= , 2012 4:18 PM
Subject:= Re: [kitten] Google and SASL OAuth

In some ways try= ing to fit OAuth 1 is twisting the semantics.

Looking at it from a O= Auth 2 bearer perspective.=0A

The email/xmpp address is the authent= ication identifier in the context of the RS API .

The bearer token i= s just a long password in most respects.

Sending the email/resource = identifier for the user as the authcid and the token as another parameter m= ay have the benefit of simplicity for OAuth 2.

Trying to map the abs= tract concept of the user identity at the authorization server in just adds= complexity.

John B.

On 2012-09-19, at 7:13 PM, Simon Josefss= on <simon@josefsson.org> wr= ote:

> Let's see if we can take a=0A step back and (re-)analyze a= nother variant.
>
> One way to resolve this issue without affe= cting the SASL design wrt
> authzid would be to add another key-value= field (for example) "resource
> identity" that transfers the identit= y that Ryan could route on and that
> clients would have to supply.&n= bsp; Then Ryan's implementation would simply
> be unable to support a= non-empty authzid, since the routing has already
> happened and cann= ot be re-routed at that point, but that is okay --
> failing on non-e= mpty authzid is the typical response if nothing else has
> been negot= iated out-of-band between user and service provider.  The
> "res= ource identity" would be a new concept introduced by the OAuth
> mech= anism, which is also fine.  The document would have to be careful in> explaining this concept so there is no confusion with the authzid.>
> I think I would prefer=0A this, if the other alternative is= to always
> require that the authzid is non-empty.
>
> = I know we have been over this a few times, but what is the disadvantage
= > with this approach?  Is it worse than requiring a non-empty authz= id?
>
> /Simon
> _______________________________________= ________
> Kitten mailing list
> = Kitten@ietf.org
> https://www.ietf.org/mailman/l= istinfo/kitten

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


=






= --835683298-1360300513-1348116019=:2331-- From nico@cryptonector.com Wed Sep 19 21:55: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 C372D21F84FD for ; Wed, 19 Sep 2012 21:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 k5+z3eyVbDno for ; Wed, 19 Sep 2012 21:55:38 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0585021F84FC for ; Wed, 19 Sep 2012 21:55:37 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 6AF182F4059 for ; Wed, 19 Sep 2012 21:55:37 -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=mwjvnsfx3FEn9jx04M4M irGSyvE=; b=H5jRX2+w/s+8YyfXDJd60w0MAOgEl/rwzjFd2MjnD0TGaGdibMPP VrzweEUokUB8oJzUvznF139GRMtG3zJvjiAx1l3pQ+ZHZXzf4GhxbXSiCWoAwLQy j7KYlkl8FlecuvE9uDw22O3x4Ox4CQp9AnI5hnBvDbT9zf4LMD/4fy0= 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 5A81B2F4057 for ; Wed, 19 Sep 2012 21:55:37 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1810372pbb.31 for ; Wed, 19 Sep 2012 21:55:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.82.101 with SMTP id h5mr2534694pay.15.1348116936968; Wed, 19 Sep 2012 21:55:36 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 19 Sep 2012 21:55:36 -0700 (PDT) In-Reply-To: <1348116019.2331.YahooMailNeo@web31804.mail.mud.yahoo.com> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <1348097398.58898.YahooMailNeo@web31801.mail.mud.yahoo.com> <1348104236.2766.YahooMailNeo@web31810.mail.mud.yahoo.com> <67E233FF-C465-457E-A744-EB1C878E7758@ve7jtb.com> <1348116019.2331.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Wed, 19 Sep 2012 23:55:36 -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] Google and 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, 20 Sep 2012 04:55:39 -0000 On Wed, Sep 19, 2012 at 11:40 PM, William Mills wrote: > Now see, I think it's you that's trying to add something to OAuth in a > different way that isn't there. OAuth, especially with the password grant > has *no* guaranteed concept of a resource identifier. In the initial stages > there might be a signed request, a client ID, or a registered callback, but > that's not guaranteed. > > Yes, I'm requiring that OAuth implementations that wish to support SASL will > need the additional feature of being able to provide an authcid. I did not > think that was unreasonable. Well, an authcid has to be authenticated, unlike the authz-id which need only be integrity protected. A mechanism that only authenticates an assertion of authorization (e.g., a list of group memberships, a list of labels, a list of resource IDs and access types, etcetera) but not an authcid cannot really authenticate an authcid because doing so... probably defeats the point (privacy protection for the authcid) of that mechanism. Now, an OAuth 2.0 token for accessing a mailbox surely identifies the mailbox or set of mailboxes that may be accessed, but for some resource types the set of resources (perhaps even mailboxes) to which the presenter is authorized may not be computable, and for IMAP any set with more than one member may not be trivial to provide a unified view of. Q: What to do in this case? My answer: Require an authz-id to name the desired resource, OR make the application protocol carry the resource names separately (e.g., like HTTP does). Nico -- From simon@josefsson.org Thu Sep 20 00:06: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 500D521F8652 for ; Thu, 20 Sep 2012 00:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.866 X-Spam-Level: X-Spam-Status: No, score=-99.866 tagged_above=-999 required=5 tests=[AWL=0.043, 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 tWqIiaH-wGee for ; Thu, 20 Sep 2012 00:06:12 -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 7588721F8628 for ; Thu, 20 Sep 2012 00:06: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 q8K765KZ015410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Sep 2012 09:06:07 +0200 From: Simon Josefsson To: mrex@sap.com References: <87sjbec9u4.fsf@latte.josefsson.org> <20120920041048.05B941A23F__1185.689707245$1348114263$gmane$org@ld9781.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120920:mrex@sap.com::rJrJN3qqOflmnSCc:4uEb X-Hashcash: 1:22:120920:kitten@ietf.org::tynTU5M5qhtW2axC:NIGa Date: Thu, 20 Sep 2012 09:06:04 +0200 In-Reply-To: <20120920041048.05B941A23F__1185.689707245$1348114263$gmane$org@ld9781.wdf.sap.corp> (Martin Rex's message of "Thu, 20 Sep 2012 06:10:48 +0200 (CEST)") Message-ID: <87d31hmaw3.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, 20 Sep 2012 07:06:13 -0000 mrex@sap.com (Martin Rex) writes: >> 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. > > > It is an error to pass a context-level token to the local context > establishment iteration call (gss_init_sec_context() on the initiator > side and gss_accept_sec_context() on the acceptor side) once the > security context has been established, i.e. when the previous call > returned GSS_S_COMPLETE. You have to pass such a context token > to gss_process_context_token() instead. This situation can arise > when an error is detected on the final leg of the handshake by > the recipient of the final regular context level token, and the > implementation wants to send back an error token. > > > See the description of gss_process_context_token() > in rfc2743, Section 2.2.4 GSS_Process_context_token call: > > http://tools.ietf.org/html/rfc2743#page-55 Nice observation! I had forgotten about gss_proecss_context_token. However, I don't think the OAuth GSS-API mech could use it since it has to be compatible with GS2 which would never use gss_process_context_token. I'll have to think more about how to resolve this... /Simon From ve7jtb@ve7jtb.com Thu Sep 20 05:33: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 67EC921F8781 for ; Thu, 20 Sep 2012 05:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.196 X-Spam-Level: X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 OmJ855jeisIU for ; Thu, 20 Sep 2012 05:33:31 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A877921F8768 for ; Thu, 20 Sep 2012 05:33:31 -0700 (PDT) Received: by ghbg10 with SMTP id g10so613281ghb.31 for ; Thu, 20 Sep 2012 05:33:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=bviP/hHJWjzmOfhgraDnyJlMuJ4dcL50pxDmAZ3jaTg=; b=l6VZkLYB/vglqAKsbz/idhX1qOlSnmzYBIvh1HDgZDzaQGVAPyAaZJ5TCus97Qxdmv nSGq3Utp5gFErHsIT2v77Mu/eGeW6tWpCPp9d9yUiWy3+m++HxesLh4grsXIBaCkrRZx EIZo0g6GgKtArjrMNefkNV6buOD4sRP/cTyXXXIY+l2SrkhTvbkh/03LGOgLxqDwP3FW NU/4y6bov4udZcA36Axx5zcVosj45toOYzquwPWLPaIi9bivrrmwCneEXEN073Ufl1ll FcKYyob+L7lSR6NsEm22rg3uPhWDldq3N1CiDbuEr4EJnYkmNxuIfli7fa4ExX1JNLrQ TGgQ== Received: by 10.236.179.101 with SMTP id g65mr1298347yhm.77.1348144411133; Thu, 20 Sep 2012 05:33:31 -0700 (PDT) Received: from [192.168.1.211] (190-20-23-156.baf.movistar.cl. [190.20.23.156]) by mx.google.com with ESMTPS id l35sm8356193yhi.12.2012.09.20.05.33.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Sep 2012 05:33:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: Date: Thu, 20 Sep 2012 09:33:21 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3297F5D6-51B8-46AD-A8DA-2DB6EEFACA30@ve7jtb.com> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <1348097398.58898.YahooMailNeo@web31801.mail.mud.yahoo.com> <1348104236.2766.YahooMailNeo@web31810.mail.mud.yahoo.com> <67E233FF-C465-457E-A744-EB1C878E7758@ve7jtb.com> <13 48116019.2331.YahooMailNeo@web31804.mail.mud.yahoo.com> To: Nico Williams X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQk+cxuQhTpXpQR5+xH/ecIGjIfEpbNEFRJK8CkpTx2oRK7wmurxwZjdZOEwX3Vw2fvt8uSn Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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, 20 Sep 2012 12:33:32 -0000 I think a large number of email providers have a simple one mailbox per = username mapping. As I have tried to say several times, the Authorization step of OAuth = doesn't communicate what the protected resource is=20 unless you do something strange like make a scope that is the email = address the Authorization server can't know=20 what the protected resource is unless there is only one resource of that = type for that resource owner. If the WG want to design a mechanism that is limited to a single = resource of the given type(IMAP, XMPP etc) per resource owner then other than the routing issue you are fine. If you allow multiple resources of a given type per resource owner, I = agree with Nico that you need to specify the resource name. Authz-id was originally about identity assumption in XMPP as I = understand it. Not who is authenticating but what account they want = to control. I don't know if that is still the understanding. In some ways that fits, though I would much rather always have the = client send it rather than having to depend on the client knowing if the = resource owner has multiple resources of the same type. In a IMAP situation I may permission my secretary to act on my behalf. = That person may be able to generate a access token that can access = multiple IMAP boxes, and the target resource may not be identified by = the access token given it may permission the client for a number of = resources. John B. On 2012-09-20, at 1:55 AM, Nico Williams wrote: > On Wed, Sep 19, 2012 at 11:40 PM, William Mills = wrote: >> Now see, I think it's you that's trying to add something to OAuth in = a >> different way that isn't there. OAuth, especially with the password = grant >> has *no* guaranteed concept of a resource identifier. In the initial = stages >> there might be a signed request, a client ID, or a registered = callback, but >> that's not guaranteed. >>=20 >> Yes, I'm requiring that OAuth implementations that wish to support = SASL will >> need the additional feature of being able to provide an authcid. I = did not >> think that was unreasonable. >=20 > Well, an authcid has to be authenticated, unlike the authz-id which > need only be integrity protected. A mechanism that only authenticates > an assertion of authorization (e.g., a list of group memberships, a > list of labels, a list of resource IDs and access types, etcetera) but > not an authcid cannot really authenticate an authcid because doing > so... probably defeats the point (privacy protection for the authcid) > of that mechanism. >=20 > Now, an OAuth 2.0 token for accessing a mailbox surely identifies the > mailbox or set of mailboxes that may be accessed, but for some > resource types the set of resources (perhaps even mailboxes) to which > the presenter is authorized may not be computable, and for IMAP any > set with more than one member may not be trivial to provide a unified > view of. >=20 > Q: What to do in this case? My answer: Require an authz-id to name > the desired resource, OR make the application protocol carry the > resource names separately (e.g., like HTTP does). >=20 > Nico > -- From simon@josefsson.org Thu Sep 20 06:32: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 9831F21F8674 for ; Thu, 20 Sep 2012 06:32: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=[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 BtQKp2fjEkaz for ; Thu, 20 Sep 2012 06:32:09 -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 3CCDA21F84FC for ; Thu, 20 Sep 2012 06:32:05 -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 q8KDVkgY002460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Sep 2012 15:31:47 +0200 From: Simon Josefsson To: Nico Williams References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120920:nico@cryptonector.com::72842e/UDq4PxKVn:JNKk X-Hashcash: 1:22:120920:kitten@ietf.org::CrGQOUpuqNfR2Jyu:00ruI Date: Thu, 20 Sep 2012 15:31:40 +0200 In-Reply-To: (Nico Williams's message of "Wed, 19 Sep 2012 18:22:07 -0500") Message-ID: <87ipb84y83.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] Google and 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, 20 Sep 2012 13:32:09 -0000 Nico Williams writes: > On Wed, Sep 19, 2012 at 5:24 PM, Simon Josefsson wrote: >> Nico Williams writes: >>> The problem with this is that it's a change to SASL that existing >>> implementations can't take advantage of. >> >> I don't follow. What implementations, OAuth or SASL implementations? >> >> Adding another data field from the client to the server seems >> straightforward to me. Presumably, the OAuth mechanism will require > > Adding a field is. Making it so SASL implementations know to output > it is another. I still don't follow... the OAuth SASL mechanism will need the client to be able to input (for example) an OAuth bearer token. That is a new field that SASL implementations needs to start understand. Why would adding another OAuth-specific field like a "resource identity" be more complicated? Almost all SASL mechanism introduce new fields that SASL libraries needs to deal with (DIGEST-MD5 introduced qop, realm, etc). > As long as anything new of this sort is done like GSS naming > extensions then it can work backwards-compatibly. What I would object > to is anything that would require adding variants of > sasl_server_step() and similar functions in Cyrus SASL. What I'm talking about is that the "resource identity" is a new sasl_setprop property. /Simon From wmills@yahoo-inc.com Thu Sep 20 07:48: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 8D54F21F86E4 for ; Thu, 20 Sep 2012 07:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.589 X-Spam-Level: X-Spam-Status: No, score=-17.589 tagged_above=-999 required=5 tests=[AWL=0.009, 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 Tj+1xLWbXBsE for ; Thu, 20 Sep 2012 07:48:04 -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 70AAE21F86E1 for ; Thu, 20 Sep 2012 07:48:04 -0700 (PDT) Received: from [72.30.22.92] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 20 Sep 2012 14:48:00 -0000 Received: from [98.139.91.45] by tm14.bullet.mail.sp2.yahoo.com with NNFMP; 20 Sep 2012 14:47:59 -0000 Received: from [127.0.0.1] by omp1045.mail.sp2.yahoo.com with NNFMP; 20 Sep 2012 14:47:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 914879.234.bm@omp1045.mail.sp2.yahoo.com Received: (qmail 18241 invoked by uid 60001); 20 Sep 2012 14:47:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348152479; bh=hOi+J1h5XwQjzBI0rVV6Hz247JaBg18M6wsvGiKbpAo=; 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=Vp73/eQxLESo7996Jw31c6qT8vC4WexN7MLtGiI8sAwRyfD96BW/j0Yc6uo+AsERWI9sPo6umbPRWP+wZnvjzK+OixStNlQ7wZee8/3VuXByCJTEi3F7sEdQzzojZ4Pg6MVi31qQt32l0kkKa7lwpcBigpyB6RfDyXfSJVe0nY8= 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=L93+BaQtO+/F1A4ab4dWf9dpbP05ft276YErTCqXyTmwC9qT3nOkKGZ4XNOIKrx+Ig+jX8BRwAlx8mQvuOfIjm9Cq7yg99OAXRnTGY4q5LrSFn3hGMToAKtFQP2dx/iXzfwTKQxOvFffasp6XXbqN71gTNDis7ROpTEvgfFnJZA=; X-YMail-OSG: O1tBOlsVM1lFe0pKYltWdcv8uXbV7PNpdcsRIVbNw9xjK9E FbD06uzlGNKX4GwKEDZZWtm_YgHlGF3z7lnVMH5rJ_OJp1fQFnluUKutTXpW wmP1pR43HD.37XQVQHqb7ICL7_HOneUB.xI2TVgb_6vgJbKFY8WrcN0URzrM hHHhchcdLUuEYf321J4VpinHDCZ_I0z_ed7CHvo3Us3TssCULR_6shJ2jxcY H1QdbjNEf4Ey7VKPb0l6YNOi5xV8OjmDoWUqkvEhDEmi3JlWeMT9SYIER4st F8sC8xoaZrUjdO6ZPl28FeX6CwdZSIyKe3u4J.p1okr20vUZtXGq4n2hN.lA q9xdPIFTJ9ohVPzIZizfmdWk6oMGyWQ6mcYOcvIlI4RRZtcZ_WmcD9SVtVjF _F4HIUsHIyAhDJo_EA3OnVbq9cytP04J4v4xBhmOvUmGV Received: from [99.31.212.42] by web31809.mail.mud.yahoo.com via HTTP; Thu, 20 Sep 2012 07:47:59 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <1348097398.58898.YahooMailNeo@web31801.mail.mud.yahoo.com> <1348104236.2766.YahooMailNeo@web31810.mail.mud.yahoo.com> <67E233FF-C465-457E-A744-EB1C878E7758@ve7jtb.com> <13 48116019.2331.YahooMailNeo@web31804.mail.mud.yahoo.com> Message-ID: <1348152479.227.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Thu, 20 Sep 2012 07:47:59 -0700 (PDT) From: William Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-1369950323-1348152479=:227" Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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, 20 Sep 2012 14:48:06 -0000 ---1395015409-1369950323-1348152479=:227 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I don't think anything need be done.=A0 The credential provides either an a= uthcid or a way for the server to get it.=A0 If the authz-id is provided, o= r an equivalent is carried in the app protocol, the app uses the authcid av= ailable from the SASL authentication to determine if access is allowed.=A0 = If no other identity is provided the app uses the authcid, which is authent= icated and provided by the mechanism.=0A=0A=0A=0A=0A=0A>___________________= _____________=0A> From: Nico Williams =0A>To: Willia= m Mills =0A>Cc: John Bradley ; "k= itten@ietf.org" ; Simon Josefsson = =0A>Sent: Wednesday, September 19, 2012 9:55 PM=0A>Subject: Re: [kitten] Go= ogle and SASL OAuth=0A> =0A>On Wed, Sep 19, 2012 at 11:40 PM, William Mills= wrote:=0A>> Now see, I think it's you that's trying= to add something to OAuth in a=0A>> different way that isn't there.=A0 OAu= th, especially with the password grant=0A>> has *no* guaranteed concept of = a resource identifier.=A0 In the initial stages=0A>> there might be a signe= d request, a client ID, or a registered callback, but=0A>> that's not guara= nteed.=0A>>=0A>> Yes, I'm requiring that OAuth implementations that wish to= support SASL will=0A>> need the additional feature of being able to provid= e an authcid.=A0 I did not=0A>> think that was unreasonable.=0A>=0A>Well, a= n authcid has to be authenticated, unlike the authz-id which=0A>need only b= e integrity protected.=A0 A mechanism that only authenticates=0A>an asserti= on of authorization (e.g., a list of group memberships, a=0A>list of labels= , a list of resource IDs and access types, etcetera) but=0A>not an authcid = cannot really authenticate an authcid because doing=0A>so... probably defea= ts the point (privacy protection for the authcid)=0A>of that mechanism.=0A>= =0A>Now, an OAuth 2.0 token for accessing a mailbox surely identifies the= =0A>mailbox or set of mailboxes that may be accessed, but for some=0A>resou= rce types the set of resources (perhaps even mailboxes) to which=0A>the pre= senter is authorized may not be computable, and for IMAP any=0A>set with mo= re than one member may not be trivial to provide a unified=0A>view of.=0A>= =0A>Q: What to do in this case?=A0 My answer: Require an authz-id to name= =0A>the desired resource, OR make the application protocol carry the=0A>res= ource names separately (e.g., like HTTP does).=0A>=0A>Nico=0A>--=0A>=0A>=0A= > ---1395015409-1369950323-1348152479=:227 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I don't t= hink anything need be done.  The credential provides either an authcid= or a way for the server to get it.  If the authz-id is provided, or a= n equivalent is carried in the app protocol, the app uses the authcid avail= able from the SASL authentication to determine if access is allowed.  = If no other identity is provided the app uses the authcid, which is authent= icated and provided by the mechanism.

<= br>
= From: Nico Williams <nico@crypto= nector.com>
To: Wil= liam Mills <wmills@yahoo-inc.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>; "kitten@ietf.= org" <kitten@ietf.org>; Simon Josefsson <simon@josefsson.org> <= br> Sent: Wednesday, Septe= mber 19, 2012 9:55 PM
Subject: Re: [kitten] Google and SASL OAuth

On Wed, = Sep 19, 2012 at 11:40 PM, William Mills <wmills@yahoo-inc.com&g= t; wrote:
> Now see, I think it's you that's trying to add something = to OAuth in a
> different way that isn't there.  OAuth, especial= ly with the password grant
> has *no* guaranteed concept of a resourc= e identifier.  In the initial stages
> there might be a signed re= quest, a client ID, or a registered callback, but
> that's not guaran= teed.
>
> Yes, I'm requiring that OAuth implementations that wi= sh to support SASL will
> need the additional feature of being able t= o provide an authcid.  I did not
> think that was unreasonable.<= br>
Well, an authcid has to be authenticated, unlike the authz-id which<= br>need only be integrity protected.  A mechanism that only authentica= tes
an assertion of authorization (e.g., a list of group memberships, a<= br>list of labels, a list of resource IDs and access types, etcetera) butnot an authcid cannot really authenticate an authcid because doing
so.= .. probably defeats the point (privacy protection for the authcid)
of th= at mechanism.

Now, an OAuth 2.0 token for accessing a mailbox surely= identifies the
mailbox or set of mailboxes that may be accessed, but for some
resource types the set of resources (perhaps even mailboxe= s) to which
the presenter is authorized may not be computable, and for I= MAP any
set with more than one member may not be trivial to provide a un= ified
view of.

Q: What to do in this case?  My answer: Requi= re an authz-id to name
the desired resource, OR make the application pro= tocol carry the
resource names separately (e.g., like HTTP does).
Nico
--


---1395015409-1369950323-1348152479=:227-- From nico@cryptonector.com Thu Sep 20 08:52: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 312AA21F8775 for ; Thu, 20 Sep 2012 08:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=-0.082, 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 c6UaYul0CwJc for ; Thu, 20 Sep 2012 08:52:03 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 628D521F8780 for ; Thu, 20 Sep 2012 08:52:01 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 07C1F26C07C for ; Thu, 20 Sep 2012 08:52: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=R45S0SGKqkVKkDZsBYfB p66h0Ow=; b=yQxmlcp1J9th2f5+bDk13g5D7juNZbzPbdgIZBecJkspgN6mju57 VcXuu1+QxECSB48CPUk5zYsYEZlUWjJXbGqDso/mW4p6jaM8wTkjJYB/D/JemDUY jdkOm6OIZpyQLH75+qHv4UYqghlVGRvVtI3a5XSonRrXJdRbNyrf8bk= 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-a87.g.dreamhost.com (Postfix) with ESMTPSA id E202226C06F for ; Thu, 20 Sep 2012 08:52:00 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3082820pbb.31 for ; Thu, 20 Sep 2012 08:52:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.82.101 with SMTP id h5mr6468541pay.15.1348156320277; Thu, 20 Sep 2012 08:52:00 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 08:51:59 -0700 (PDT) In-Reply-To: <87ipb84y83.fsf@latte.josefsson.org> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> <87ipb84y83.fsf@latte.josefsson.org> Date: Thu, 20 Sep 2012 10:51:59 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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, 20 Sep 2012 15:52:05 -0000 On Thu, Sep 20, 2012 at 8:31 AM, Simon Josefsson wrote: > What I'm talking about is that the "resource identity" is a new > sasl_setprop property. As long as the server can cope with not finding that property (or can derive it from other elements) then that's OK. If the server insists on that property then the server will only work with the OAuth mechanism. What I'm trying to do here is avoid requirements that make it impossible to build generic SASL applications. (Generic in the sense of supporting multiple/arbitrary mechanisms.) Nico -- From nico@cryptonector.com Thu Sep 20 08:55: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 297B621F8781 for ; Thu, 20 Sep 2012 08:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=-0.080, 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 3MLAs7KRNz1l for ; Thu, 20 Sep 2012 08:55:13 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB5D21F846F for ; Thu, 20 Sep 2012 08:55:13 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 1AD747E4075 for ; Thu, 20 Sep 2012 08:55: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=iQ8cjYhtYgyXgmlxbAux 4Qlcg8E=; b=JdKg1NxyL1/HBl6UkihUxn8/AXpXFW42ImjUdiN1aHgWyRxz13n1 BTUkzT1rAZIJNUikXoAcP9XcdRE8uCCQgi2ou8InUVGJZ4AOTOmZ4+VlgTHe8UKN jDRx+W9S1JUrC7dhI4TOCTAGK7nNMkCuIL2wsL0RITQ3w2ojn+brmUc= 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 0608E7E4058 for ; Thu, 20 Sep 2012 08:55:12 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3089239pbb.31 for ; Thu, 20 Sep 2012 08:55:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.34 with SMTP id ib2mr7716627pbc.164.1348156512691; Thu, 20 Sep 2012 08:55:12 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 08:55:12 -0700 (PDT) In-Reply-To: <1348152479.227.YahooMailNeo@web31809.mail.mud.yahoo.com> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <1348097398.58898.YahooMailNeo@web31801.mail.mud.yahoo.com> <1348104236.2766.YahooMailNeo@web31810.mail.mud.yahoo.com> <67E233FF-C465-457E-A744-EB1C878E7758@ve7jtb.com> <1348152479.227.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Thu, 20 Sep 2012 10:55: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] Google and 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, 20 Sep 2012 15:55:14 -0000 On Thu, Sep 20, 2012 at 9:47 AM, William Mills wrote: > I don't think anything need be done. The credential provides either an > authcid or a way for the server to get it. If the authz-id is provided, or > an equivalent is carried in the app protocol, the app uses the authcid > available from the SASL authentication to determine if access is allowed. > If no other identity is provided the app uses the authcid, which is > authenticated and provided by the mechanism. I'll let the OAuth experts (you, John, Ryan) deal with the authcid. If OAuth 2.0 does not provide an authcid (or not reliably) and you need either an authz-id or an authcid then you must either require that clients provide an authz-id (which, really, is not a big deal, just annoying, and for an IMAP client possible not even annoying) or add an authcid. I don't care which you choose. Nico -- From simon@josefsson.org Thu Sep 20 12:18: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 3105221F8697 for ; Thu, 20 Sep 2012 12:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.867 X-Spam-Level: X-Spam-Status: No, score=-99.867 tagged_above=-999 required=5 tests=[AWL=0.042, 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 w--QKnyYlAjy for ; Thu, 20 Sep 2012 12:18:37 -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 DCC2921F8616 for ; Thu, 20 Sep 2012 12:18:36 -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 q8KJIKjP020875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Sep 2012 21:18:21 +0200 From: Simon Josefsson To: Nico Williams References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> <87ipb84y83.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120920:nico@cryptonector.com::Fv+N4RYQC9aOaxgs:0ng1 X-Hashcash: 1:22:120920:kitten@ietf.org::r3P+wM7RRXh1tz7S:Mm0x Date: Thu, 20 Sep 2012 21:18:20 +0200 In-Reply-To: (Nico Williams's message of "Thu, 20 Sep 2012 10:51:59 -0500") Message-ID: <87zk4ka4g3.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] Google and 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, 20 Sep 2012 19:18:38 -0000 Nico Williams writes: > On Thu, Sep 20, 2012 at 8:31 AM, Simon Josefsson wrote: >> What I'm talking about is that the "resource identity" is a new >> sasl_setprop property. > > As long as the server can cope with not finding that property (or can > derive it from other elements) then that's OK. If the server insists > on that property then the server will only work with the OAuth > mechanism. The property would be set on the client side, and transferred in the mechanism from the client to the server. It would then be available for the server, as another property. > What I'm trying to do here is avoid requirements that make it > impossible to build generic SASL applications. (Generic in the sense > of supporting multiple/arbitrary mechanisms.) How would you get there? A SCRAM client will always require a username and password (or hashed password). A GSSAPI (i.e., krb5) client will require a Kerberos ticket. An OAuth client will need for example an OAuth bearer token. An OpenID client will need the OpenID URL from the user, and access to a browser. A SAML20 client will need a SAML IdP identifier and access to a browser. A SAML20EC client will need a SAML stack. And so on. This needs to come from the something outside of the mechanism, and the details of what is required will always be mechanism specific. You can shield the details from the application if your SASL library can supply the details, but I see no reason why the SASL library couldn't supply a resource identity the same way it would supply a SCRAM username or OpenID URL. I suspect I just don't follow you here... /Simon From nico@cryptonector.com Thu Sep 20 12:27: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 1869221F86A3 for ; Thu, 20 Sep 2012 12:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 aWoMOuzgw2ts for ; Thu, 20 Sep 2012 12:27:36 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 4C58421F86A2 for ; Thu, 20 Sep 2012 12:27:36 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id BB89721DE58 for ; Thu, 20 Sep 2012 12:27: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=yx/KZ+yeZqGueBISjL3S xvOJuy4=; b=Fd5Zv3gSX5jNabWrQCVRMRIQS3ImU16UrREQTkzxWHWxHJhqJLKF b5FUXRE7dS1qwWHVftCGYho2lMoruZsfpYmWJEmS/TjFkStDiG1qgvU1dVf2Igw0 5UGy1+wKa0seLsuJKCcO0jV5DrS/l/xohOJhIo/Ws/7+sYA/3ivXXuQ= Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.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 87D8D21DE65 for ; Thu, 20 Sep 2012 12:27:35 -0700 (PDT) Received: by padfb11 with SMTP id fb11so222916pad.31 for ; Thu, 20 Sep 2012 12:27:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr9179771pbc.149.1348169255047; Thu, 20 Sep 2012 12:27:35 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 12:27:34 -0700 (PDT) In-Reply-To: <87zk4ka4g3.fsf@latte.josefsson.org> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> <87ipb84y83.fsf@latte.josefsson.org> <87zk4ka4g3.fsf@latte.josefsson.org> Date: Thu, 20 Sep 2012 14:27:34 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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, 20 Sep 2012 19:27:37 -0000 On Thu, Sep 20, 2012 at 2:18 PM, Simon Josefsson wrote: > Nico Williams writes: >> As long as the server can cope with not finding that property (or can >> derive it from other elements) then that's OK. If the server insists >> on that property then the server will only work with the OAuth >> mechanism. > > The property would be set on the client side, and transferred in the > mechanism from the client to the server. It would then be available for > the server, as another property. I'm talking about the server side. A server that demands this be available will only work with this one mechanism. Nico -- From simon@josefsson.org Thu Sep 20 12:33: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 BED0321F84C8 for ; Thu, 20 Sep 2012 12:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.868 X-Spam-Level: X-Spam-Status: No, score=-99.868 tagged_above=-999 required=5 tests=[AWL=0.041, 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 iTCbkGY9x5Oa for ; Thu, 20 Sep 2012 12:33: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 B911B21F84B2 for ; Thu, 20 Sep 2012 12:33:13 -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 q8KJX383021616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Sep 2012 21:33:05 +0200 From: Simon Josefsson To: Nico Williams References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> <87ipb84y83.fsf@latte.josefsson.org> <87zk4ka4g3.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120920:nico@cryptonector.com::4wnVQ55+/gj+meR5:6XsV X-Hashcash: 1:22:120920:kitten@ietf.org::aNTxM3WlLz4xHP7J:GnkB Date: Thu, 20 Sep 2012 21:33:03 +0200 In-Reply-To: (Nico Williams's message of "Thu, 20 Sep 2012 14:27:34 -0500") Message-ID: <87vcf8a3rk.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] Google and 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, 20 Sep 2012 19:33:14 -0000 Nico Williams writes: > On Thu, Sep 20, 2012 at 2:18 PM, Simon Josefsson wrote: >> Nico Williams writes: >>> As long as the server can cope with not finding that property (or can >>> derive it from other elements) then that's OK. If the server insists >>> on that property then the server will only work with the OAuth >>> mechanism. >> >> The property would be set on the client side, and transferred in the >> mechanism from the client to the server. It would then be available for >> the server, as another property. > > I'm talking about the server side. A server that demands this be > available will only work with this one mechanism. The OAuth SASL spec would require the field to always be sent by the client, as other mechanism specific data. Naturally the server will require that the client sends things conforming to the protocol. Is your issue that you think the client cannot find out what this field should be set to? /Simon From wmills@yahoo-inc.com Thu Sep 20 12:35: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 7C22421E8090 for ; Thu, 20 Sep 2012 12:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.492 X-Spam-Level: X-Spam-Status: No, score=-17.492 tagged_above=-999 required=5 tests=[AWL=0.106, 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 Gvny2VGsKd+c for ; Thu, 20 Sep 2012 12:35:26 -0700 (PDT) Received: from nm6-vm3.bullet.mail.ne1.yahoo.com (nm6-vm3.bullet.mail.ne1.yahoo.com [98.138.91.136]) by ietfa.amsl.com (Postfix) with SMTP id 4D37D21E8091 for ; Thu, 20 Sep 2012 12:35:26 -0700 (PDT) Received: from [98.138.90.49] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2012 19:35:23 -0000 Received: from [98.138.89.172] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2012 19:35:23 -0000 Received: from [127.0.0.1] by omp1028.mail.ne1.yahoo.com with NNFMP; 20 Sep 2012 19:35:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 306636.76345.bm@omp1028.mail.ne1.yahoo.com Received: (qmail 19430 invoked by uid 60001); 20 Sep 2012 19:35:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348169722; bh=+g0aLV/8ER7sfcoVkY1hDXoBcYiZ1EtEuFXZqGRsA8k=; 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=NPE+8p51PFKLRlYGOQJ6ystns5XGjnUZNHRMmaPTP4t9v8v5lndX2nr+et5stS8fp2+XT2AbHUBJqGN+XoUt46A5597auduVMLVcSOoTzaH8Kvh3Fx62uxtt0d12Fjy914DJ9LZ92/xJQhXoQ3y0tb7OTftoDFg/uL0jC1acjEE= 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=rVOvjS3VlpBEaSqRRaQjRr8H6pMK4s9sQE+nIOozF8bgaVmtCkx6lDBC1VnOIE2HefuDwfh2u9mNZJXn0TUJwC8bIsgUExOsZX5IHrT+kqQzc756v4GGkZ2jl+MFQprWRuxxvxOTWA3RXmMgvecrPzGDE5dUgCK27eXfBP2crR0=; X-YMail-OSG: 76laOPEVM1nMO67bkf7HQZlR.jda_WiCB7828M8k1r4SOtj vNwVwRJ9axHCMkArIJ.AND73XPu2ylJyRwqS8PK94XdREF02hDqZbwbuvUbe kgFIVdNFjXzmg40fr942h7M.9p7EYUtPOKOO0xUGK6EgSJpTM5L7Fr8qQJyz K0wUpBk0d_mDoog8_iXkOFK7hYXHZjwytFNX.WaJUkdsSxouSbcqG6s_YnuG m9vYn7gub4cVs3uURgkILZFBnfCqHXFaLKNfSJ5K_jd9lSI409FuCqGgoISR ivny.W_g9kLZv6g9Kp0vnIG8H8FKMOvhowHS4Y0Ny7uArRAeGqsJnyEqCV_W KbLTVt6CH0J8Mom0SbDFEUD_95MH8tJ5g3cg7uDVgb5_pfgYCD.xpU4zvaAv AcMxhQ.F2I3uNX8mmV2ROIApiB.OoENv2b9QVvbjGtfmO.CZ_GnRZ1LShgjs D6zX0Cg-- Received: from [209.131.62.113] by web31808.mail.mud.yahoo.com via HTTP; Thu, 20 Sep 2012 12:35:22 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> <87ipb84y83.fsf@latte.josefsson.org> <87zk4ka4g3.fsf@latte.josefsson.org> Message-ID: <1348169722.15128.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Thu, 20 Sep 2012 12:35:22 -0700 (PDT) From: William Mills To: Nico Williams , Simon Josefsson In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-1386914572-1348169722=:15128" Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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, 20 Sep 2012 19:35:27 -0000 --258328648-1386914572-1348169722=:15128 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable That seems a spurious argument to me, because it argues against the way SAS= L works now.=A0 Servers will absolutely select the auth mechanism(s) they w= ant to support, but you don't have to support them all.=A0 PLAIN has differ= ent inputs from a Kerberos based mechanism.=0A=0A=0A=0A=0A=0A>_____________= ___________________=0A> From: Nico Williams =0A>To: = Simon Josefsson =0A>Cc: "kitten@ietf.org" =0A>Sent: Thursday, September 20, 2012 12:27 PM=0A>Subject: Re: [kit= ten] Google and SASL OAuth=0A> =0A>On Thu, Sep 20, 2012 at 2:18 PM, Simon J= osefsson wrote:=0A>> Nico Williams writes:=0A>>> As long as the server can cope with not finding that pr= operty (or can=0A>>> derive it from other elements) then that's OK.=A0 If t= he server insists=0A>>> on that property then the server will only work wit= h the OAuth=0A>>> mechanism.=0A>>=0A>> The property would be set on the cli= ent side, and transferred in the=0A>> mechanism from the client to the serv= er.=A0 It would then be available for=0A>> the server, as another property.= =0A>=0A>I'm talking about the server side.=A0 A server that demands this be= =0A>available will only work with this one mechanism.=0A>=0A>Nico=0A>--=0A>= _______________________________________________=0A>Kitten mailing list=0A>K= itten@ietf.org=0A>https://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> --258328648-1386914572-1348169722=:15128 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
That seem= s a spurious argument to me, because it argues against the way SASL works n= ow.  Servers will absolutely select the auth mechanism(s) they want to= support, but you don't have to support them all.  PLAIN has different= inputs from a Kerberos based mechanism.


<= div style=3D"font-family: times new roman, new york, times, serif; font-siz= e: 12pt;">
From: Nico Williams <= ;nico@cryptonector.com>
To: Simon Josefsson <simon@josefsson.org>
Cc: "kitten@ietf.org" <kitten@ietf.org>
<= b>Sent: Thursday, September 2= 0, 2012 12:27 PM
Subject:<= /b> Re: [kitten] Google and SASL OAuth

On Thu, Sep 2= 0, 2012 at 2:18 PM, Simon Josefsson <simon@josefsson.org> wrot= e:
> Nico Williams <nico@cryptonector.com> writes:>> As long as the server can cope with not finding that property (o= r can
>> derive it from other elements) then that's OK.  If t= he server insists
>> on that property then the server will only wo= rk with the OAuth
>> mechanism.
>
> The property would= be set on the client side, and transferred in the
> mechanism from the clie= nt to the server.  It would then be available for
> the server, = as another property.

I'm talking about the server side.  A serv= er that demands this be
available will only work with this one mechanism= .

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


= --258328648-1386914572-1348169722=:15128-- From nico@cryptonector.com Thu Sep 20 12:41: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 02CB721F8687 for ; Thu, 20 Sep 2012 12:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 B2jVEToW-950 for ; Thu, 20 Sep 2012 12:41:39 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 52ADA21E804A for ; Thu, 20 Sep 2012 12:41:39 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id F2AA536006D for ; Thu, 20 Sep 2012 12:41: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=7tk5tl/SZwPNf85zg4XH /4cz5vI=; b=xaEGCLBDn++lMQN+AGZd03nhN0aH4swCiJFWzgOG39rZaSBlmIJP LgY4OREVXLmaxfekrg9W7EeanubXubaEWGxN97PiAHXmZz3zC+eGh49uJuV0OR5F P6QWLopc6/MP6HnJfhhvEgPjbP2yrhuppu79f7QYMbthYXbpjoma+ns= 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 DB370360072 for ; Thu, 20 Sep 2012 12:41:38 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3488228pbb.31 for ; Thu, 20 Sep 2012 12:41:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.226.195 with SMTP id ru3mr9258371pbc.149.1348170098571; Thu, 20 Sep 2012 12:41:38 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 12:41:38 -0700 (PDT) In-Reply-To: <87vcf8a3rk.fsf@latte.josefsson.org> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> <87ipb84y83.fsf@latte.josefsson.org> <87zk4ka4g3.fsf@latte.josefsson.org> <87vcf8a3rk.fsf@latte.josefsson.org> Date: Thu, 20 Sep 2012 14:41:38 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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, 20 Sep 2012 19:41:40 -0000 On Thu, Sep 20, 2012 at 2:33 PM, Simon Josefsson wrote: > Nico Williams writes: > >> On Thu, Sep 20, 2012 at 2:18 PM, Simon Josefsson wrote: >>> Nico Williams writes: >>>> As long as the server can cope with not finding that property (or can >>>> derive it from other elements) then that's OK. If the server insists >>>> on that property then the server will only work with the OAuth >>>> mechanism. >>> >>> The property would be set on the client side, and transferred in the >>> mechanism from the client to the server. It would then be available for >>> the server, as another property. >> >> I'm talking about the server side. A server that demands this be >> available will only work with this one mechanism. > > The OAuth SASL spec would require the field to always be sent by the > client, as other mechanism specific data. Naturally the server will > require that the client sends things conforming to the protocol. Is > your issue that you think the client cannot find out what this field > should be set to? The server *app*. If it insists on something that only one mechanism provides, then that app will only work with that one mechanism. From wmills@yahoo-inc.com Thu Sep 20 12:53:29 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 C02FC21F86EF for ; Thu, 20 Sep 2012 12:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.495 X-Spam-Level: X-Spam-Status: No, score=-17.495 tagged_above=-999 required=5 tests=[AWL=0.103, 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 ePQhAd+q-N09 for ; Thu, 20 Sep 2012 12:53:17 -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 67E4E21F8686 for ; Thu, 20 Sep 2012 12:53:13 -0700 (PDT) Received: from [98.139.212.146] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 20 Sep 2012 19:53:13 -0000 Received: from [98.139.212.215] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 20 Sep 2012 19:53:13 -0000 Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 20 Sep 2012 19:53:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 168213.46762.bm@omp1024.mail.bf1.yahoo.com Received: (qmail 32607 invoked by uid 60001); 20 Sep 2012 19:53:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348170792; bh=hC94gPCAbli1XZSDuxDFc4WCqTfky2hXnjT3kVoBqLU=; 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=nimKqY7eO9TW8GB1o0oZRq192mClPjrwKnOAw5SFj/3hF6RYnHMCct+ftSI1X7VRk4GoF9TYPGaeY6KpR/lsMmhe/5SuMKXLnXvAYxDWmUM9BTi1OzyfoiXO1Eb1NbRIwUNBdpAyDoH2pRz5zPyu4+PbOYOtQHLjRuQ+TYmRAjk= 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=rk3Eu8eqiboohmlus8TgJlxDyQVSXg/dG51gddNsIFuwNUyvaxxej17QwH4saWN8nH1MhGbniuu465wLwhzuuHMpBPvtQXOCvFq4M1FUChly572fNrwh1hMAD9w2Y52z2uBkEiKJjtfFDIHGpT4sd50cfSqZfhVEq5QEy5oP0fE=; X-YMail-OSG: AotWMwAVM1lda9kSd07NnpysXRvBn9CzjaTYrkbTx0ybUpw TyEhk.4JrTCqi6gjUB8AKWmdPBKq2Jg9fx6U0zhcvTwTv9SSJHdrdBKqQ1u7 TgdUF9HNeTxqcfIKaxdRkTHuRdyAkstgHpThkhZwXlHf2cG8x8sMCCeveEcU swLCXHiqcYNg69fmng2jQgsLCyVszDcSPcc06hJO5dxrcXXaUSyfXv.fmmXI tgS5onmiRczTjgkEjqlSExB_9fkJdoCRRJQmtDmmdUzK9Xw8HvrvGWRrj1tq bO7Th.87Lsa48paoR8YlYIg7ogE907riHddRdbTdgubtLlAh614yGrZm6rqs zoZj7GMMrTyBmN45tue0XnDfiPQW_eIogSn8Qlwl_bdeUS2DffteefepKZcH 4.ihpb0jGneNZzG0OdMo36emm8FvD6PdErQwK4RGs6SgFvYvLVycpaS08QIf IsJoYvj8- Received: from [209.131.62.113] by web31804.mail.mud.yahoo.com via HTTP; Thu, 20 Sep 2012 12:53:11 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> <87ipb84y83.fsf@latte.josefsson.org> <87zk4ka4g3.fsf@latte.josefsson.org> <87vcf8a3rk.fsf@latte.josefsson.org> Message-ID: <1348170791.31901.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Thu, 20 Sep 2012 12:53:11 -0700 (PDT) From: William Mills To: Nico Williams , Simon Josefsson In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-2146558402-1348170791=:31901" Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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, 20 Sep 2012 19:53:31 -0000 --835683298-2146558402-1348170791=:31901 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Are you arguing that the OAuth SASL mechanism is breaking new ground here a= nd requiring a completely new data element?=A0 I don't think that's true.= =0A=0A=0A=0A=0A=0A>________________________________=0A> From: Nico Williams= =0A>To: Simon Josefsson =0A>C= c: "kitten@ietf.org" =0A>Sent: Thursday, September 20, 20= 12 12:41 PM=0A>Subject: Re: [kitten] Google and SASL OAuth=0A> =0A>On Thu, = Sep 20, 2012 at 2:33 PM, Simon Josefsson wrote:=0A>> = Nico Williams writes:=0A>>=0A>>> On Thu, Sep 20, 20= 12 at 2:18 PM, Simon Josefsson wrote:=0A>>>> Nico Wil= liams writes:=0A>>>>> As long as the server can cop= e with not finding that property (or can=0A>>>>> derive it from other eleme= nts) then that's OK.=A0 If the server insists=0A>>>>> on that property then= the server will only work with the OAuth=0A>>>>> mechanism.=0A>>>>=0A>>>> = The property would be set on the client side, and transferred in the=0A>>>>= mechanism from the client to the server.=A0 It would then be available for= =0A>>>> the server, as another property.=0A>>>=0A>>> I'm talking about the = server side.=A0 A server that demands this be=0A>>> available will only wor= k with this one mechanism.=0A>>=0A>> The OAuth SASL spec would require the = field to always be sent by the=0A>> client, as other mechanism specific dat= a.=A0 Naturally the server will=0A>> require that the client sends things c= onforming to the protocol.=A0 Is=0A>> your issue that you think the client = cannot find out what this field=0A>> should be set to?=0A>=0A>The server *a= pp*.=A0 If it insists on something that only one mechanism=0A>provides, the= n that app will only work with that one mechanism.=0A>_____________________= __________________________=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>htt= ps://www.ietf.org/mailman/listinfo/kitten=0A>=0A>=0A> --835683298-2146558402-1348170791=:31901 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Are you a= rguing that the OAuth SASL mechanism is breaking new ground here and requir= ing a completely new data element?  I don't think that's true.


=
From: Nico Williams <nico@cryptonector.com>
To: Simon Josefsson <simon@josefsson.org= >
Cc: "kitten@ietf.= org" <kitten@ietf.org>
Sent: Thursday, September 20, 2012 12:41 PM
Subject: Re: [kitten] Google and SASL OAuth
<= /font>

On Thu, Sep 20, 2012 at 2:33 PM, Simon Josefsson <s= imon@josefsson.org> wrote:
> Nico Williams <nico@cry= ptonector.com> writes:
>
>> On Thu, Sep 20, 2012 at 2= :18 PM, Simon Josefsson <simon@josefsson.org> wrote:
>&= gt;> Nico Williams <nico@cryptonector.com> writes:
= >>>> As long as the server can cope with not finding that prope= rty (or can
>>>> derive it from other elements) then that's OK.&nbs= p; If the server insists
>>>> on that property then the serv= er will only work with the OAuth
>>>> mechanism.
>>= >
>>> The property would be set on the client side, and tran= sferred in the
>>> mechanism from the client to the server.&nbs= p; It would then be available for
>>> the server, as another pr= operty.
>>
>> I'm talking about the server side.  A = server that demands this be
>> available will only work with this = one mechanism.
>
> The OAuth SASL spec would require the field = to always be sent by the
> client, as other mechanism specific data.&= nbsp; Naturally the server will
> require that the client sends thing= s conforming to the protocol.  Is
> your issue that you think th= e client cannot find out what this field
> should be set to?

The server *app*.  If it insists on something that only on= e mechanism
provides, then that app will only work with that one mechani= sm.
_______________________________________________
Kitten mailing li= st
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

--835683298-2146558402-1348170791=:31901-- From simon@josefsson.org Thu Sep 20 13:55: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 52FEE21F8661 for ; Thu, 20 Sep 2012 13:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.87 X-Spam-Level: X-Spam-Status: No, score=-99.87 tagged_above=-999 required=5 tests=[AWL=0.039, 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 LscELjn52nhs for ; Thu, 20 Sep 2012 13:55:01 -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 4866721F865F for ; Thu, 20 Sep 2012 13:55:00 -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 q8KKshML025775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Sep 2012 22:54:44 +0200 From: Simon Josefsson To: Nico Williams References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> <87ipb84y83.fsf@latte.josefsson.org> <87zk4ka4g3.fsf@latte.josefsson.org> <87vcf8a3rk.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120920:kitten@ietf.org::YNiwVs6GYoWRmWot:72pv X-Hashcash: 1:22:120920:nico@cryptonector.com::zyfQJXpQneE9l7im:5w4J Date: Thu, 20 Sep 2012 22:54:38 +0200 In-Reply-To: (Nico Williams's message of "Thu, 20 Sep 2012 14:41:38 -0500") Message-ID: <87k3vo9zzl.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] Google and 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, 20 Sep 2012 20:55:02 -0000 Nico Williams writes: > On Thu, Sep 20, 2012 at 2:33 PM, Simon Josefsson wrote: >> Nico Williams writes: >> >>> On Thu, Sep 20, 2012 at 2:18 PM, Simon Josefsson wrote: >>>> Nico Williams writes: >>>>> As long as the server can cope with not finding that property (or can >>>>> derive it from other elements) then that's OK. If the server insists >>>>> on that property then the server will only work with the OAuth >>>>> mechanism. >>>> >>>> The property would be set on the client side, and transferred in the >>>> mechanism from the client to the server. It would then be available for >>>> the server, as another property. >>> >>> I'm talking about the server side. A server that demands this be >>> available will only work with this one mechanism. >> >> The OAuth SASL spec would require the field to always be sent by the >> client, as other mechanism specific data. Naturally the server will >> require that the client sends things conforming to the protocol. Is >> your issue that you think the client cannot find out what this field >> should be set to? > > The server *app*. If it insists on something that only one mechanism > provides, then that app will only work with that one mechanism. Ah. Now I think I understand what you are getting at. I never intended to propose that the server application should do anything with the resource identity. The server application would normally never care about it. It is an OAuth SASL mechanism internal field. The fields' only purpose is to allow deployments like Ryan's to be able to route the connection right without having to parse other fields. Once the connection has been routed right, the server mechanism implementation will verify that the resource identity is the same as the authzid if given by the client, or the (now derived) authcid if authzid is absent. If there is a mismatch, the mechanism must fail authentication. If you now react that the field is strictly speaking unnecessary because you could deploy things in a two routing scenario as you mentioned, yes I would agree, but I think we can consider accomodating Ryan's request here if that is the simplest way to move forward and doesn't have any significant downside. For deployment that can discover the right place to route things immediately, the resource identity will just waste space on the wire and require one unnecessary comparison at the end of the server code. That's not a huge disadvantage to me. /Simon From mrex@sap.com Thu Sep 20 14:53: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 9F55B11E80A2 for ; Thu, 20 Sep 2012 14:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.184 X-Spam-Level: X-Spam-Status: No, score=-10.184 tagged_above=-999 required=5 tests=[AWL=0.065, 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 6XeAfL0p4TAi for ; Thu, 20 Sep 2012 14:53:49 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9980F11E808A for ; Thu, 20 Sep 2012 14:53:48 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q8KLrfZN008778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Sep 2012 23:53:42 +0200 (MEST) In-Reply-To: To: Nico Williams Date: Thu, 20 Sep 2012 23:53:41 +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: <20120920215341.36A4A1A246@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out 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 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: Thu, 20 Sep 2012 21:53:49 -0000 (still trying to catch up on old emails...) I agree with Nico that a GSS-API mechanism spec is supposed to specify the representation of native name form and of a canonical exported (binary) name token. But that name is really about identity and authentication, not (fine-grained) authorization. Microsoft conveys fine-grained authorization information in a "PAC" inside the ticket, but none of that is visible at the naming/identity level. (that would also not be compatible with the Kerberos gssapi mechanism rfc1964/rfc4121). How the application manages authorization is up to the application. When a gssapi mechanism works as part of the TCB (trusted computing base), then it is possible to have the TCB perform access control for access to system objects -- at least when the incoming autorization info is meaningful to the local TCB (which is not necessarily the case, and often limited to "within-organization" communication). Creating a name by concatenating (fine-grained) authorization information to me looks like a problem, rather than a solution to anything, because that information is opaque for ACLs built with the exported name token. Any change in any of the fine-grained authorization attributes would cause all ACL entries based on exported names to no longer match (require them to be updated), which does not look like the desired outcome of fine-grained ACL management. I believe, access to fine-grained authorization data should be done through TCB or additional GSS-API calls (gss_get_name_attribute), but not affect the regular name (neither exported, nor display name). -Martin Nico Williams wrote: > 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. > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From ve7jtb@ve7jtb.com Thu Sep 20 15:26: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 9F03721E80A8 for ; Thu, 20 Sep 2012 15:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 CHLXl7XmTjir for ; Thu, 20 Sep 2012 15:26:14 -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 BF8CD21E80B3 for ; Thu, 20 Sep 2012 15:26:13 -0700 (PDT) Received: by qabj40 with SMTP id j40so834335qab.10 for ; Thu, 20 Sep 2012 15:26:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=3OsbkgECOAawdk3ammkYb1lFfwgdOD+Iy4PKaBafuh0=; b=fjnWQZTPiQs8RI5yzOZGFBNncOC+DrFEiqrvhxNfwZP7Qfy404RQs2HQfkJspffbWp ezMxnRnS/mKfN99h+b0AdWbAxdZ2LyBWWaF4W/kTrkIydzYs9JZS0B0udsDBvXdVPTSY 1F9zeqgB0KXPj7djIRbv1iacjI2nPPrn31XYo9/aRMT7dggdZ7QX+jCDHWLX9a0/GPlT RgG+xd79b+scPqy3JMmQF+XEqgmQFFR5wUm0sfc5unVUjK71jzvpwBGLhRf+GCALjZFj UtM37PgN3PnUPElEI+meVjlId4MD5IWPuGNGrfivujrC8ZuyZWkxlsKt+tkkvgAxSwrq iq3Q== Received: by 10.229.135.84 with SMTP id m20mr2148276qct.89.1348179972859; Thu, 20 Sep 2012 15:26:12 -0700 (PDT) Received: from [192.168.1.211] (190-20-23-156.baf.movistar.cl. [190.20.23.156]) by mx.google.com with ESMTPS id y18sm9911192qaa.15.2012.09.20.15.26.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Sep 2012 15:26:10 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_116DC4C9-B784-4054-81A4-0FC4A13B91B2" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: <1346214892.84802.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Thu, 20 Sep 2012 19:25:59 -0300 Message-Id: <52CC2D18-F747-4382-8D2A-FC44978A8AD8@ve7jtb.com> References: <1346214892.84802.YahooMailNeo@web31804.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQkOgELaMjyC6FqeykSTTK8WNi5jKgVGR8kCjmg9rZSzL2ycnPklFoSkYe/gBYno2fzUO62o 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: Thu, 20 Sep 2012 22:26:15 -0000 --Apple-Mail=_116DC4C9-B784-4054-81A4-0FC4A13B91B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 authZ ID is the entity you are acting on behalf of. In XMPP I understand that to be I am logging in with my authcid and = password and want to act as the authzid if my authcid credential allows = it. I don't see how that would ever be the client_id. =20 I can see having the OAuth token conveying that my account X has granted = access to the client to access three mailboxes and each of those = mailboxes may be identified by two email addresses. I still think that a oauth account may have more than one resource of a = given type (mail-box) so unless you restrict that you need to specify = the resource someplace. That is not the same as authz which is the identity you want to act as. = For IMAP it may be but we don't want to limit the oauth mechanism to a = single protocol. John B. On 2012-08-29, at 12:34 AM, 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. >=20 >=20 > From: Nico Williams > To: "Cantor, Scott" =20 > Cc: "kitten@ietf.org" =20 > Sent: Tuesday, August 28, 2012 9:05 PM > Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05 >=20 > 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. >=20 > I don't see that either. Just trying to think this through. >=20 > >>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. >=20 > Good point. >=20 > 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. >=20 > Nico > -- > _______________________________________________ > 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 --Apple-Mail=_116DC4C9-B784-4054-81A4-0FC4A13B91B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 authZ = ID is the entity you are acting on behalf of.

In XMPP = I understand that to be I am logging in with my authcid and password and = want to act as the authzid if my authcid credential allows = it.

I don't see how that would ever be the = client_id.  

I can see having the OAuth = token conveying that my account X has granted access to the client to = access three mailboxes and each of those mailboxes may be identified by = two email addresses.

I still think that a oauth = account may have more than one resource of a given type (mail-box) so = unless you restrict that you need to specify the resource = someplace.

That is not the same as authz which = is the identity you want to act as.  For IMAP it may be but we = don't want to limit the oauth mechanism to a single = protocol.

John B.

On = 2012-08-29, at 12:34 AM, William Mills <wmills@yahoo-inc.com> = 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.


=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 draft -05
=
On Tue, Aug 28, 2012 at 10:59 PM, Cantor, Scott <cantor.2@osu.edu> wrote:
> = On 8/28/12 11:54 PM, "Nico Williams" <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 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
--
___________________________________= ____________
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=_116DC4C9-B784-4054-81A4-0FC4A13B91B2-- From wmills@yahoo-inc.com Fri Sep 21 08:28: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 DCD8721F8815 for ; Fri, 21 Sep 2012 08:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.498 X-Spam-Level: X-Spam-Status: No, score=-17.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 IlR3aKXmcHyg for ; Fri, 21 Sep 2012 08:28:49 -0700 (PDT) Received: from nm23-vm0.bullet.mail.sp2.yahoo.com (nm23-vm0.bullet.mail.sp2.yahoo.com [98.139.91.224]) by ietfa.amsl.com (Postfix) with SMTP id 825CF21F8812 for ; Fri, 21 Sep 2012 08:28:49 -0700 (PDT) Received: from [72.30.22.93] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 21 Sep 2012 15:28:42 -0000 Received: from [72.30.22.37] by tm15.bullet.mail.sp2.yahoo.com with NNFMP; 21 Sep 2012 15:28:42 -0000 Received: from [127.0.0.1] by omp1067.mail.sp2.yahoo.com with NNFMP; 21 Sep 2012 15:28:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 831670.5182.bm@omp1067.mail.sp2.yahoo.com Received: (qmail 72828 invoked by uid 60001); 21 Sep 2012 15:28:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348241322; bh=cHjpsL7BMF5mqruzm5Cdv5kq/mqLmp6EvuOHmQ7c428=; 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=MGuGUd931Zf+mwclX9z1iX4OZhAXAuyTArZrHx6znwghy3z3n54874QEC5DCr3bflF9Ku51UeAFOe91ozTx6NKXVkBi3rn+4i2ZnlNh5Nd2JBsUOsIhJo/o6zKioBzEu7T9PolUP4mQTx3j68htN4z0OQhG3vv/ADzuwDyC4yPA= 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=rzzzgNMdjV6OFdvk0XBBgBoHs0IEKO5WWrRyi3zMSjfhv2bXSJDGCA8ZezjmQdCFTcJposvB47yecm2mhoe8YTwmuOE7wDfoBjE2ARHJLPb14OMsdOndSBkao4lPl5JXRIl+vYwSLo6UxwKcbE6sl7ZwFNDRLS5CLy4zDqXIc48=; X-YMail-OSG: CfrNy2UVM1njkHTseNoSRzgwAEiSXm9t402exPyXmGOHBi7 S6l4MeZyY5_bgRt0zKnJggcA3A6u6GiSIthW5fq90etpU57NuG7bBoIn_g1n 9yfIPWLIUqnW4bvEZEyKn4b_Pn6BwVN1Id5F6o.3uwmgdrglYxa_QJAnK_Qx 3QqXF4aLCzu2xeuBO2Uv0SBAUNFaXHXOkCyek11Qvx5iymfss5x_C_XJ.eKJ UuT0JdeNLGsvbGZo5iPOX4J92hdVPnqL_jZ_eAeBXRfe9j6wb91UkD_Z0q2m RQFENo9LncK123gJeQAsY2eSwH97YyILM.p7EYghmn.ddU7E8Rzy1ClSrBzh BiGgdqdeBoxc3ooR.AK4CP1XKhWJUNbmi8SYKcFJgXUtmAKFhqJI2WbvPjG2 Cl_NuL7c2yWXqIJWnEgiGKxj2RjDdiDncwb3WZGMekZ4HMYq0i7xboTeG0mC gSjvMHn0L Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Fri, 21 Sep 2012 08:28:41 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <1346214892.84802.YahooMailNeo@web31804.mail.mud.yahoo.com> <52CC2D18-F747-4382-8D2A-FC44978A8AD8@ve7jtb.com> Message-ID: <1348241321.43602.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Fri, 21 Sep 2012 08:28:41 -0700 (PDT) From: William Mills To: John Bradley In-Reply-To: <52CC2D18-F747-4382-8D2A-FC44978A8AD8@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1502656925-21937965-1348241321=:43602" 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 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, 21 Sep 2012 15:28:51 -0000 --1502656925-21937965-1348241321=:43602 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OK, so after all this time, I have them reversed.=A0 In any event, the appl= ication will have to use a mechanism that allows something other than the a= uthcid to be communicated if it wants to get to additional information out = of the OAuth context.=0A=0A=0A=0A=0A=0A>________________________________=0A= > From: John Bradley =0A>To: William Mills =0A>Cc: Nico Williams ; "Cantor, Scott" ; "kitten@ietf.org" =0A>Sent: Thursday, S= eptember 20, 2012 3:25 PM=0A>Subject: Re: [kitten] Identities Re: Comma vs= . %x01 Re: OAuth SASL draft -05=0A> =0A>=0A>authZ ID is the entity you are = acting on behalf of.=0A>=0A>=0A>In XMPP I understand that to be I am loggin= g in with my authcid and password and want to act as the authzid if my auth= cid credential allows it.=0A>=0A>=0A>I don't see how that would ever be the= client_id. =A0=0A>=0A>=0A>I can see having the OAuth token conveying that = my account X has granted access to the client to access three mailboxes and= each of those mailboxes may be identified by two email addresses.=0A>=0A>= =0A>I still think that a oauth account may have more than one resource of a= given type (mail-box) so unless you restrict that you need to specify the = resource someplace.=0A>=0A>=0A>That is not the same as authz which is the i= dentity you want to act as. =A0For IMAP it may be but we don't want to limi= t the oauth mechanism to a single protocol.=0A>=0A>=0A>John B.=0A>=0A>=0A>O= n 2012-08-29, at 12:34 AM, William Mills wrote:=0A>= =0A>Just to be clear it is possible in OAuth to have *both* a client ID whi= ch would equate to an authZ ID and a ID in the token which would be an auth= N ID.=A0=A0 All this info might be carried in a Bearer token, or explicitly= called out in OAuth 1.0a as the oauth_client.=A0 If the client ID represen= ts something=A0 like a desktop client it (i.e. Flickr Uploadr client and mo= bile clients now) then that ID isn't probably really useful because it's ef= fectively 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 w= ant.=A0 I was leaving that the to the server to determine.=0A>>=0A>>=0A>>= =0A>>=0A>>=0A>>=0A>>>________________________________=0A>>> From: Nico Will= iams =0A>>>To: "Cantor, Scott" = =0A>>>Cc: "kitten@ietf.org" =0A>>>Sent: Tuesday, August 2= 8, 2012 9:05 PM=0A>>>Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL dr= aft -05=0A>>> =0A>>>On Tue, Aug 28, 2012 at 10:59 PM, Cantor, Scott wrote:=0A>>>> On 8/28/12 11:54 PM, "Nico Williams" wrote:=0A>>>>>=0A>>>>>OK, let's say that there is a GSS mechani= sm such that it makes no=0A>>>>>sense to assert an authz-id when using it a= s a SASL/GS2 mechanism.=0A>>>>=0A>>>> I don't think there's any obvious rea= son for that here.=0A>>>=0A>>>I don't see that either.=A0 Just trying to th= ink 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 t= hat the server "MUST fail the=0A>>>>>authentication attempt", or that it "M= UST ignore the authz-id=0A>>>>>assertion", or perhaps something else.=0A>>>= >=0A>>>> As I suspected, and Simon/Luke noted, you can't mandate that witho= ut=0A>>>> breaking existing GS2 code.=0A>>>=0A>>>Good point.=0A>>>=0A>>>I t= hink the best thing to do is to say that this is a SASL/GS2 (and=0A>>>there= fore GSS) mechanism and=0A then say *noting* about the SASL=0A>>>authz-id.= =0A>>>=0A>>>Nico=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.i= etf.org/mailman/listinfo/kitten=0A>>=0A>=0A>=0A> --1502656925-21937965-1348241321=:43602 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OK, so af= ter all this time, I have them reversed.  In any event, the applicatio= n will have to use a mechanism that allows something other than the authcid= to be communicated if it wants to get to additional information out of the= OAuth context.


From: John Bradley <ve7jtb@ve7jtb.com> To: William Mills <wmills@yahoo-inc.com>
Cc:= Nico Williams <nico@cryptonector.com>; "Cantor, Scott" &l= t;cantor.2@osu.edu>; "kitten@ietf.org" <kitten@ietf.org>
<= span style=3D"font-weight: bold;">Sent: Thursday, September 20, = 2012 3:25 PM
Subject: = Re: [kitten] Identities Re: Comma vs. %x01 Re: OAuth SASL draft -05

authZ ID is the entity you = are acting on behalf of.

In XMPP I understand that to be= I am logging in with my authcid and password and want to act as the authzi= d if my authcid credential allows it.

I don't see = how that would ever be the client_id.  

I can= see having the OAuth token conveying that my account X has granted access = to the client to access three mailboxes and each of those mailboxes may be identified by two email addresses.

I still think = that a oauth account may have more than one resource of a given type (mail-= box) so unless you restrict that you need to specify the resource someplace= .

That is not the same as authz which is the ident= ity you want to act as.  For IMAP it may be but we don't want to limit= the oauth mechanism to a single protocol.

John B.=

On 2012-08-29, at 12:34 AM, William Mills <wmills@yahoo-inc.com> wrote:
Just t= o be clear it is possible in OAuth to have *both* a client ID which would e= quate to an authZ ID and a ID in the token which would be an authN ID. &nbs= p; All this info might be carried in a Bearer token, or explicitly called o= ut in OAuth 1.0a as the oauth_client.  If the client ID represents som= ething  like a desktop client it (i.e. Flickr Uploadr client and mobil= e clients now) then that ID isn't probably really useful because it's effec= tively 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 w= ant.  I was leaving that the to the server to determine.


=0A

On Tue, A= ug 28, 2012 at 10:59 PM, Cantor, Scott <= cantor.2@osu.edu> wrote:
> On 8/28/12 11:54 PM, "Nico Williams= " <nico@cryptonector.com= > wrote:
>>
>>OK, let's say that there is a GSS mechan= ism 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 obvi= ous reason for that here.

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

>>What's the problem?  Well, we n= eed to say what happens if an authz-id
>>is asserted nonetheless.  We can sa= y that the server "MUST fail the
>>authentication attempt", or tha= t it "MUST ignore the authz-id
>>assertion", or perhaps something = else.
>
> As I suspected, and Simon/Luke noted, you can't manda= te that without
> breaking existing GS2 code.

Good point.
<= br>I think the best thing to do is to say that this is a SASL/GS2 (and
t= herefore GSS) mechanism and=0A then say *noting* about the SASL
authz-id= .

Nico
--
_______________________________________________
K= itten 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



--1502656925-21937965-1348241321=:43602-- From nico@cryptonector.com Fri Sep 21 08:31: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 06EE321F8812 for ; Fri, 21 Sep 2012 08:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 w2BhzK-iiMS9 for ; Fri, 21 Sep 2012 08:31:57 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 8258F21F8734 for ; Fri, 21 Sep 2012 08:31:57 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 3931A674070 for ; Fri, 21 Sep 2012 08:31: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=kcq3V2isRkn9Ey58jDV3 IMFy5U4=; b=IDZYWhtrz1RRL3vUNGSamXAbIqoR51xCuQwHIT0S6yuj/AUaJQWA XBsOZcn0E+ih22sPI65+5C+9Z+evX84C0JGWgO17sFSyy67GIGhit1S1jMmAH2nt GTeLaTeCA9mkalsxbZh72cCcskz1Cn8vxo8L+B7/HzM93i06YbBB8Eg= 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-a29.g.dreamhost.com (Postfix) with ESMTPSA id 1657F67401F for ; Fri, 21 Sep 2012 08:31:56 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so5488908pbb.31 for ; Fri, 21 Sep 2012 08:31:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.203.70 with SMTP id ko6mr929049pbc.164.1348241516577; Fri, 21 Sep 2012 08:31:56 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 21 Sep 2012 08:31:56 -0700 (PDT) In-Reply-To: <1348241321.43602.YahooMailNeo@web31803.mail.mud.yahoo.com> References: <1346214892.84802.YahooMailNeo@web31804.mail.mud.yahoo.com> <52CC2D18-F747-4382-8D2A-FC44978A8AD8@ve7jtb.com> <1348241321.43602.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Fri, 21 Sep 2012 10:31:56 -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: Fri, 21 Sep 2012 15:31:58 -0000 On Fri, Sep 21, 2012 at 10:28 AM, William Mills wrote: > OK, so after all this time, I have them reversed. In any event, the > application will have to use a mechanism that allows something other than > the authcid to be communicated if it wants to get to additional information > out of the OAuth context. And today that would be the authz-id. Nico -- From nico@cryptonector.com Fri Sep 21 08:42: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 58C8D21F86FC for ; Fri, 21 Sep 2012 08:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 9zaFleBy1WTg for ; Fri, 21 Sep 2012 08:42:00 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id AFD3521F86F4 for ; Fri, 21 Sep 2012 08:42:00 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 566981DE081 for ; Fri, 21 Sep 2012 08:42:00 -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=wrvnn63m5eUF80kbzPm7 /CJs4LQ=; b=o1txrS6htmwUUBXCLklr2zVz2MfV2cc/8HGxwDDeGcI1Mrb7KW/0 VqS6111ke63g7Kkv6nYzZVG+fUCb90MH9NFq3k7OMY3Z8H/ovbonVEv3/PRgjNwE 4411OnTcwO9rWwDEB4g4kNRNQPz0KNaAUtowFlIIqiI4iOmj6IPXv0E= 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 372CD1DE05D for ; Fri, 21 Sep 2012 08:42:00 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so5507334pbb.31 for ; Fri, 21 Sep 2012 08:41:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.236.69 with SMTP id us5mr16771520pbc.59.1348242119866; Fri, 21 Sep 2012 08:41:59 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 21 Sep 2012 08:41:59 -0700 (PDT) In-Reply-To: <87k3vo9zzl.fsf@latte.josefsson.org> References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> <87ipb84y83.fsf@latte.josefsson.org> <87zk4ka4g3.fsf@latte.josefsson.org> <87vcf8a3rk.fsf@latte.josefsson.org> <87k3vo9zzl.fsf@latte.josefsson.org> Date: Fri, 21 Sep 2012 10:41:59 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Google and 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, 21 Sep 2012 15:42:01 -0000 On Thu, Sep 20, 2012 at 3:54 PM, Simon Josefsson wrote: > Nico Williams writes: >> The server *app*. If it insists on something that only one mechanism >> provides, then that app will only work with that one mechanism. > > Ah. Now I think I understand what you are getting at. I never intended > to propose that the server application should do anything with the > resource identity. The server application would normally never care > about it. It is an OAuth SASL mechanism internal field. The fields' > only purpose is to allow deployments like Ryan's to be able to route the > connection right without having to parse other fields. Once the Because the server *app* is the one doing the routing in that case, and because it simply *must* do this routing, Ryan's server would *insist* on this value being present, thus binding itself tightly to this one mechanism. But note that this value might as well be the authz-id, which all SASL mechanisms support. Therefore it's best if we use the authz-id for this. Note that with the UI that Ryan has in mind the authz-id is actually the *perfect* thing to use anyways -- in some place in the UI the name of the mailbox will be necessary, and that's anyways what authz-id is used for in IMAP. > connection has been routed right, the server mechanism implementation > will verify that the resource identity is the same as the authzid if > given by the client, or the (now derived) authcid if authzid is absent. > If there is a mismatch, the mechanism must fail authentication. The authorization mechanism will be based on OAuth here, but that's a detail we don't care about right now. What we do care about is having the resource (mailbox) identified so that we may then use OAuth to perform authorization. The way to identify that resource is exceedingly clear to me now: it's the authz-id. > If you now react that the field is strictly speaking unnecessary because > you could deploy things in a two routing scenario as you mentioned, yes > I would agree, but I think we can consider accomodating Ryan's request Ryan has indicated that terminating the SASL exchange at the router is not a problem. So there's no need to look at this as a two-routing-problem problem. Just use the authz-id. > here if that is the simplest way to move forward and doesn't have any > significant downside. For deployment that can discover the right place > to route things immediately, the resource identity will just waste space > on the wire and require one unnecessary comparison at the end of the > server code. That's not a huge disadvantage to me. I'm not sure which request of Ryan's you're talking about. There could be protocols where the authz-id does not identify a resource, but that's OK: something else in those protocols will, and then authorization can proceed as expected. I believe it's now been established beyond doubt (certainly mine) that the authz-id *is* the one and only protocol element that Ryan needs here to identify the IMAP mailbox that the client is trying to access. Nico -- From ve7jtb@ve7jtb.com Fri Sep 21 09:23: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 C79F221F8611 for ; Fri, 21 Sep 2012 09:23:17 -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=[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 txgAoATWoxe9 for ; Fri, 21 Sep 2012 09:23:16 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3057921F85B8 for ; Fri, 21 Sep 2012 09:23:16 -0700 (PDT) Received: by ghbg10 with SMTP id g10so1083492ghb.31 for ; Fri, 21 Sep 2012 09:23:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Fb0L0g+ik62SjyW58/qNrDV5UoM/C0mDWD8SKXIHf38=; b=iD7+N9XwAywp4P+3i17PvScPR0ISzl0Thr3qDO9/US/uko9t9tQKFBog7T0aLbQJ1w 3f80NFMs3endrnq89PTvFU9OXHzAzUusr0woM4JvKvIwtXC/pvUHcLRLtYVEjgRzTC74 XBf2PTtdcMYS1P7N6k01SSJjdChuAktOFT1/NFRvNixBpVrLuASG/S64+R6VsE7Jc8QD Xph8YLpZqj3jgmoce2CySMwZWr/fCUFy7d7VWCL1BvR+0XFsHS2tvfyL+fPVPyiox4El ByMhKIpvcisz+KUHgMytyA8N3BKOR+AoUOV7sqmBeIq5rVuZ6oSxEZL7SE0sHh/v0IzW 5iHA== Received: by 10.100.245.29 with SMTP id s29mr1830470anh.48.1348244595330; Fri, 21 Sep 2012 09:23:15 -0700 (PDT) Received: from [172.20.10.4] ([201.220.233.197]) by mx.google.com with ESMTPS id o34sm13557960yhi.5.2012.09.21.09.23.12 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Sep 2012 09:23:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: Date: Fri, 21 Sep 2012 13:23:09 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> <87ipb84y83.fsf@latte.josefsson.org> <87zk4ka4g3.fsf@latte.josefsson.org> <87vcf8a3rk.fsf@latte.josefsson.org> <87k3vo9zzl.fsf@latte.josefsson.org> To: Nico Williams X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQmJYe1GD3jXOA1pUwIMP0BewsKElqtypDhtbFz0/TpEx44ZDMH0Wv0uqac+5+OHXTkY65QC Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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, 21 Sep 2012 16:23:17 -0000 Agreed. For Imap and XMPP authz looks like email address and that fits. For other protocols (perhaps calendaring or something) the authzid may = be different but that should not be a problem. I think the authzid should always be sent to avoid interoperability = issues. John B. On 2012-09-21, at 12:41 PM, Nico Williams wrote: > On Thu, Sep 20, 2012 at 3:54 PM, Simon Josefsson = wrote: >> Nico Williams writes: >>> The server *app*. If it insists on something that only one = mechanism >>> provides, then that app will only work with that one mechanism. >>=20 >> Ah. Now I think I understand what you are getting at. I never = intended >> to propose that the server application should do anything with the >> resource identity. The server application would normally never care >> about it. It is an OAuth SASL mechanism internal field. The fields' >> only purpose is to allow deployments like Ryan's to be able to route = the >> connection right without having to parse other fields. Once the >=20 > Because the server *app* is the one doing the routing in that case, > and because it simply *must* do this routing, Ryan's server would > *insist* on this value being present, thus binding itself tightly to > this one mechanism. >=20 > But note that this value might as well be the authz-id, which all SASL > mechanisms support. >=20 > Therefore it's best if we use the authz-id for this. >=20 > Note that with the UI that Ryan has in mind the authz-id is actually > the *perfect* thing to use anyways -- in some place in the UI the name > of the mailbox will be necessary, and that's anyways what authz-id is > used for in IMAP. >=20 >> connection has been routed right, the server mechanism implementation >> will verify that the resource identity is the same as the authzid if >> given by the client, or the (now derived) authcid if authzid is = absent. >> If there is a mismatch, the mechanism must fail authentication. >=20 > The authorization mechanism will be based on OAuth here, but that's a > detail we don't care about right now. What we do care about is having > the resource (mailbox) identified so that we may then use OAuth to > perform authorization. >=20 > The way to identify that resource is exceedingly clear to me now: it's > the authz-id. >=20 >> If you now react that the field is strictly speaking unnecessary = because >> you could deploy things in a two routing scenario as you mentioned, = yes >> I would agree, but I think we can consider accomodating Ryan's = request >=20 > Ryan has indicated that terminating the SASL exchange at the router is > not a problem. So there's no need to look at this as a > two-routing-problem problem. >=20 > Just use the authz-id. >=20 >> here if that is the simplest way to move forward and doesn't have any >> significant downside. For deployment that can discover the right = place >> to route things immediately, the resource identity will just waste = space >> on the wire and require one unnecessary comparison at the end of the >> server code. That's not a huge disadvantage to me. >=20 > I'm not sure which request of Ryan's you're talking about. >=20 > There could be protocols where the authz-id does not identify a > resource, but that's OK: something else in those protocols will, and > then authorization can proceed as expected. >=20 > I believe it's now been established beyond doubt (certainly mine) that > the authz-id *is* the one and only protocol element that Ryan needs > here to identify the IMAP mailbox that the client is trying to access. >=20 > Nico > -- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From wmills@yahoo-inc.com Fri Sep 21 09:35: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 DB27121F877C for ; Fri, 21 Sep 2012 09:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[AWL=0.097, 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 oGbHMJP1ibM4 for ; Fri, 21 Sep 2012 09:35:17 -0700 (PDT) Received: from nm18-vm2.bullet.mail.ne1.yahoo.com (nm18-vm2.bullet.mail.ne1.yahoo.com [98.138.91.94]) by ietfa.amsl.com (Postfix) with SMTP id 872B621F877B for ; Fri, 21 Sep 2012 09:35:17 -0700 (PDT) Received: from [98.138.226.180] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 21 Sep 2012 16:35:13 -0000 Received: from [98.138.89.193] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 21 Sep 2012 16:35:13 -0000 Received: from [127.0.0.1] by omp1051.mail.ne1.yahoo.com with NNFMP; 21 Sep 2012 16:35:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 228425.80848.bm@omp1051.mail.ne1.yahoo.com Received: (qmail 11901 invoked by uid 60001); 21 Sep 2012 16:35:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348245312; bh=VBgk5kjU15LmBI8JqDZHqJIUJqSL1BWFVZeIqJwn3m8=; 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=mAazpClHSduEkoVYJWhQiJhkgxNX7k7f4T2Ud0fmxutGbLIABa8C6HzydRtnwa8ezx8oYnOf8cx/aF/1YK9z/Amj6IqyW2ix8KmHbX3XtYGS044CEpUKxz1ZiiekZfqvhUI063A2AGcvkBG7TvLhwhvsMgzpmEAPVlu9hRM6zFQ= 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=aNN6JYORCevowp3LroUAmK/sjRuwK89UZ2PRjr7/5TO8c+778p29LhdsVcZGy77yUzcdidoCWPmr8Fhsyyr1DJI00/coxBZH43wHieaBG0Mcrr8k3vL3ta8UzUQ/mWcm6xoVbTBrB4w+aJACyRwxML0chLOHhHBaVF8C7XpC5LY=; X-YMail-OSG: jffcImwVM1nmQl2NZkxI3HadZt0qxM5DV_yYSVh6xlbhceh QpNWiNFXZCjwMLCegVJXcePn9KoZROxNX6mOYecc4kDPbTPXhMyLdEJXmX5E XX.TgO0gaHgf.2RmcbdBI16S4hkAeizEsELJ2R_HS3IHCRn0W2Sxwe3WnN18 eT3xUUn0x.WCw8By08nYyPZVW_nVrKWijFmlryUuAl40.bWbUhtg2VW2WPzf RP02tlKg.lAbi0j0KWguTSYW96K9VAeMwJ.1X2nHrauk8vJzT6_6NntBB61f OVrkzElfuohGmvkjrmKSn_9QDc5ELjTAG0Lh9Y.CCdiWHNW_heReire7QUps D5gDncuIoIZkrRctYGlOlef4vTR7IZYZAPyj0HhLZuiVkftlvKfBgBdIGBOK g4LI_v2JUqKktpbTxefyVnObr12.A2QB_9Cabios47gMjpGroUg5GdEqwpYD 0hbStTS8- Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Fri, 21 Sep 2012 09:35:11 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.434 References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> <87ipb84y83.fsf@latte.josefsson.org> <87zk4ka4g3.fsf@latte.josefsson.org> <87vcf8a3rk.fsf@latte.josefsson.org> <87k3vo9zzl.fsf@latte.josefsson.org> Message-ID: <1348245311.11345.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Fri, 21 Sep 2012 09:35:11 -0700 (PDT) From: William Mills To: John Bradley , Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-326910509-1348245311=:11345" Cc: "kitten@ietf.org" , Simon Josefsson Subject: [kitten] WGLC? Re: Google and 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, 21 Sep 2012 16:35:19 -0000 ---125733401-326910509-1348245311=:11345 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So do we have consensus?=A0 (I think so)=0A=0AThe only edit I have now for = -09 would be specifying that unknown fields are ignored, which is almost a = grace note, but easily done.=0A=0ACan w now proceed to WGLC?=0A=0AThanks,= =0A=0A-bill=0A=0A=0A=0A=0A=0A>________________________________=0A> From: Jo= hn Bradley =0A>To: Nico Williams = =0A>Cc: "kitten@ietf.org" ; Simon Josefsson =0A>Sent: Friday, September 21, 2012 9:23 AM=0A>Subject: Re: [kitt= en] Google and SASL OAuth=0A> =0A>Agreed.=0A>=0A>For Imap and XMPP authz lo= oks like email address and that fits.=0A>For other protocols (perhaps calen= daring or something) the authzid may be different but that should not be a = problem.=0A>=0A>I think the authzid should always be sent to avoid interope= rability issues.=0A>=0A>John B.=0A>=0A>On 2012-09-21, at 12:41 PM, Nico Wil= liams wrote:=0A>=0A>> On Thu, Sep 20, 2012 at 3:54 = PM, Simon Josefsson wrote:=0A>>> Nico Williams writes:=0A>>>> The server *app*.=A0 If it insists on some= thing that only one mechanism=0A>>>> provides, then that app will only work= with that one mechanism.=0A>>> =0A>>> Ah.=A0 Now I think I understand what= you are getting at.=A0 I never intended=0A>>> to propose that the server a= pplication should do anything with the=0A>>> resource identity.=A0 The serv= er application would normally never care=0A>>> about it.=A0 It is an OAuth = SASL mechanism internal field.=A0 The fields'=0A>>> only purpose is to allo= w deployments like Ryan's to be able to route the=0A>>> connection right wi= thout having to parse other fields.=A0 Once the=0A>> =0A>> Because the serv= er *app* is the one doing the routing in that case,=0A>> and because it sim= ply *must* do this routing, Ryan's server would=0A>> *insist* on this value= being present, thus binding itself tightly to=0A>> this one mechanism.=0A>= > =0A>> But note that this value might as well be the authz-id, which all S= ASL=0A>> mechanisms support.=0A>> =0A>> Therefore it's best if we use the a= uthz-id for this.=0A>> =0A>> Note that with the UI that Ryan has in mind th= e authz-id is actually=0A>> the *perfect* thing to use anyways -- in some p= lace in the UI the name=0A>> of the mailbox will be necessary, and that's a= nyways what authz-id is=0A>> used for in IMAP.=0A>> =0A>>> connection has b= een routed right, the server mechanism implementation=0A>>> will verify tha= t the resource identity is the same as the authzid if=0A>>> given by the cl= ient, or the (now derived) authcid if authzid is absent.=0A>>> If there is = a mismatch, the mechanism must fail authentication.=0A>> =0A>> The authoriz= ation mechanism will be based on OAuth here, but that's a=0A>> detail we do= n't care about right now.=A0 What we do care about is having=0A>> the resou= rce (mailbox) identified so that we may then use OAuth to=0A>> perform auth= orization.=0A>> =0A>> The way to identify that resource is exceedingly clea= r to me now: it's=0A>> the authz-id.=0A>> =0A>>> If you now react that the = field is strictly speaking unnecessary because=0A>>> you could deploy thing= s in a two routing scenario as you mentioned, yes=0A>>> I would agree, but = I think we can consider accomodating Ryan's request=0A>> =0A>> Ryan has ind= icated that terminating the SASL exchange at the router is=0A>> not a probl= em.=A0 So there's no need to look at this as a=0A>> two-routing-problem pro= blem.=0A>> =0A>> Just use the authz-id.=0A>> =0A>>> here if that is the sim= plest way to move forward and doesn't have any=0A>>> significant downside.= =A0 For deployment that can discover the right place=0A>>> to route things = immediately, the resource identity will just waste space=0A>>> on the wire = and require one unnecessary comparison at the end of the=0A>>> server code.= =A0 That's not a huge disadvantage to me.=0A>> =0A>> I'm not sure which req= uest of Ryan's you're talking about.=0A>> =0A>> There could be protocols wh= ere the authz-id does not identify a=0A>> resource, but that's OK: somethin= g else in those protocols will, and=0A>> then authorization can proceed as = expected.=0A>> =0A>> I believe it's now been established beyond doubt (cert= ainly mine) that=0A>> the authz-id *is* the one and only protocol element t= hat Ryan needs=0A>> here to identify the IMAP mailbox that the client is tr= ying to access.=0A>> =0A>> Nico=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>=0A> ---125733401-326910509-1348245311=:11345 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
So do we = have consensus?  (I think so)

The only edit I have now for -09 = would be specifying that unknown fields are ignored, which is almost a grac= e note, but easily done.

Can w now proceed to WGLC?

Thanks,
-bill


=
From: John Bradley <ve7jtb@ve7jtb.com>
= To: Nico Williams <nico@cryptonector.com>
Cc= : "kitten@ietf.org" <kitten@ietf.org>; Simon Josefsson <= ;simon@josefsson.org>
Sent: Friday, September 21, 2012 9:23 AM
Subject: Re: [kitten] Google and SASL OAuth

Agreed.

For Imap and XMPP authz looks like email addr= ess and that fits.
For other protocols (perhaps calendaring or something= ) the authzid may be different but that should not be a problem.

I t= hink the authzid should always be sent to avoid interoperability issues.
John B.

On 2012-09-21, at 12:41 PM, Nico Williams <ni= co@cryptonector.com> wrote:

> On Thu, Sep 20, 2012 at 3:54= PM, Simon Josefsson <simon@josefsson.org> wrote:
= >> Nico Williams <nico@cryptonector.com> writes:
= >>> The server *app*.  If it insists on something that only o= ne mechanism
>>> provides, then that app will only work with th= at one mechanism.
>>
>> Ah.  Now I think I understa= nd what you are getting at.  I never intended
>> to propose t= hat the server application should do anything with the
>> resource= identity.  The server application would normally never care
>&g= t; about it.  It is an OAuth SASL mechanism internal field.  The = fields'
>> only purpose is to allow deployments like Ryan's to be = able to route the
>> connection right without having to parse othe= r fields.  Once the
>
> Because the server *app* is the one doing the routing in that case,
> and because it simply *must* d= o this routing, Ryan's server would
> *insist* on this value being pr= esent, thus binding itself tightly to
> this one mechanism.
> <= br>> But note that this value might as well be the authz-id, which all S= ASL
> mechanisms support.
>
> Therefore it's best if we = use the authz-id for this.
>
> Note that with the UI that Ryan= has in mind the authz-id is actually
> the *perfect* thing to use an= yways -- in some place in the UI the name
> of the mailbox will be ne= cessary, and that's anyways what authz-id is
> used for in IMAP.
&= gt;
>> connection has been routed right, the server mechanism imp= lementation
>> will verify that the resource identity is the same = as the authzid if
>> given by the client, or the (now derived) aut= hcid if authzid is absent.
>> If there is a mismatch, the mechanism must fail authentication.
>
> The authorization mec= hanism will be based on OAuth here, but that's a
> detail we don't ca= re about right now.  What we do care about is having
> the resou= rce (mailbox) identified so that we may then use OAuth to
> perform a= uthorization.
>
> The way to identify that resource is exceedi= ngly clear to me now: it's
> the authz-id.
>
>> If yo= u now react that the field is strictly speaking unnecessary because
>= > you could deploy things in a two routing scenario as you mentioned, ye= s
>> I would agree, but I think we can consider accomodating Ryan'= s request
>
> Ryan has indicated that terminating the SASL exc= hange at the router is
> not a problem.  So there's no need to l= ook at this as a
> two-routing-problem problem.
>
> Just= use the authz-id.
>
>> here if that is the simplest way to move forward and doesn't have any
>> significant downside.=   For deployment that can discover the right place
>> to rout= e things immediately, the resource identity will just waste space
>&g= t; on the wire and require one unnecessary comparison at the end of the
= >> server code.  That's not a huge disadvantage to me.
> <= br>> I'm not sure which request of Ryan's you're talking about.
> =
> There could be protocols where the authz-id does not identify a> resource, but that's OK: something else in those protocols will, and<= br>> then authorization can proceed as expected.
>
> I beli= eve it's now been established beyond doubt (certainly mine) that
> th= e authz-id *is* the one and only protocol element that Ryan needs
> h= ere to identify the IMAP mailbox that the client is trying to access.
&g= t;
> Nico
> --
> _______________________________________________
> Kitten mailing lis= t
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitt= en

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


---125733401-326910509-1348245311=:11345-- From rtroll@google.com Fri Sep 21 11:01: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 27DCF21F8687 for ; Fri, 21 Sep 2012 11:01:42 -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 cpn-98sI6Wa8 for ; Fri, 21 Sep 2012 11:01:41 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E444521F8686 for ; Fri, 21 Sep 2012 11:01:40 -0700 (PDT) Received: by iec9 with SMTP id 9so6986839iec.31 for ; Fri, 21 Sep 2012 11:01:40 -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=+fVGj3290rO2ArfosoaVk22GjdLD2uaXjxVApl6DiLQ=; b=Bt+MsdIcXtjUs83xqQJCOErP/3jinVcyLhst+gkHiuyDhg6hF6l4bZnKvMlKWXjqsK FfvXxzIdBMuhdd4jrIFbaJLmBXkFMPalkzWjNrG6bopJuNlN5QTPFKmQ21MUzI/J2FPK TTpHZy2Bbfxcd3BeIdE9FO0XZ00voIBMUqd+c= 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=+fVGj3290rO2ArfosoaVk22GjdLD2uaXjxVApl6DiLQ=; b=Sxhtey1NE0danITuw+/qhJvwdQhMTqUJdHExqanVE6XP6mEYI31gvbC9nAhhbm//Ol f0osFyEeStTDCRj+CTWJ+APS5kTayfeHsKRQ31LouCYb91daCGm4xqbSRJPRTKFG6e9S MqU1yoZ4JsKPH3G910h8nowIvAh7i47MGG5aDmE+6KhHR3AuB79ECn+kuz2W7ouRSzm1 p0ktUSptqp6sYDoPEe5k4aWjQ3mazDu7aPJp7mgkPZOWwQlwfj405MY/QNENJtk+4usz T+Z6FPVXcCf8f/k0gSy0/z5k0y9t09uaQ7i2CQjA8qncEM3uGnCCERaxF89C2wow0mtB jfbA== Received: by 10.50.180.225 with SMTP id dr1mr2459517igc.6.1348250500313; Fri, 21 Sep 2012 11:01:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.180.225 with SMTP id dr1mr2459500igc.6.1348250500029; Fri, 21 Sep 2012 11:01:40 -0700 (PDT) Received: by 10.50.36.131 with HTTP; Fri, 21 Sep 2012 11:01:39 -0700 (PDT) In-Reply-To: References: <87pq5iij20.fsf@latte.josefsson.org> <1348070760.47728.YahooMailNeo@web31812.mail.mud.yahoo.com> <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> <87ipb84y83.fsf@latte.josefsson.org> <87zk4ka4g3.fsf@latte.josefsson.org> <87vcf8a3rk.fsf@latte.josefsson.org> <87k3vo9zzl.fsf@latte.josefsson.org> Date: Fri, 21 Sep 2012 11:01:39 -0700 Message-ID: From: Ryan Troll To: John Bradley Content-Type: multipart/alternative; boundary=14dae9340cdd1f5ead04ca3a083c X-System-Of-Record: true X-Gm-Message-State: ALoCoQk86KnE9a5bb89AAEiGwqCvz7VlOW3dEUBIAJM05FlvC/jOwmtFpsIzyZNgladrJQW0XMGPE+HpxLFl8meikOBMNtXAbRfmdbWoA54De++T6mZmTn0VHvk7hdQeCs4g34+1+fEM9tojFfJJ2s5TG+quOtDHRGgH7v/m2gsAEZZmkmE0Wq6nrcFz8wYbtJoVXi+3jnCe Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Google and 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, 21 Sep 2012 18:01:42 -0000 --14dae9340cdd1f5ead04ca3a083c Content-Type: text/plain; charset=ISO-8859-1 I've been reading this thread, and following most of it. It's been especially interesting to see the discussion about what's done [within SASL] vs in an app that uses SASL. Excellent points by all. It's also great to see that we've arrived at consensus on the authzid being required. I believe this makes a lot of sense when using OAuth, and fully support it. Thank you all for taking the time to work through this. The overall attitude of the discussion - "Let's figure out how to solve Ryan's problem" - was fantastic. This is what makes standards bodies work. And if a final proposal was made that didn't enable me to solve my problem, it certainly wouldn't have been for lack of honest discussion and trying. -R On Fri, Sep 21, 2012 at 9:23 AM, John Bradley wrote: > Agreed. > > For Imap and XMPP authz looks like email address and that fits. > For other protocols (perhaps calendaring or something) the authzid may be > different but that should not be a problem. > > I think the authzid should always be sent to avoid interoperability issues. > > John B. > > On 2012-09-21, at 12:41 PM, Nico Williams wrote: > > > On Thu, Sep 20, 2012 at 3:54 PM, Simon Josefsson > wrote: > >> Nico Williams writes: > >>> The server *app*. If it insists on something that only one mechanism > >>> provides, then that app will only work with that one mechanism. > >> > >> Ah. Now I think I understand what you are getting at. I never intended > >> to propose that the server application should do anything with the > >> resource identity. The server application would normally never care > >> about it. It is an OAuth SASL mechanism internal field. The fields' > >> only purpose is to allow deployments like Ryan's to be able to route the > >> connection right without having to parse other fields. Once the > > > > Because the server *app* is the one doing the routing in that case, > > and because it simply *must* do this routing, Ryan's server would > > *insist* on this value being present, thus binding itself tightly to > > this one mechanism. > > > > But note that this value might as well be the authz-id, which all SASL > > mechanisms support. > > > > Therefore it's best if we use the authz-id for this. > > > > Note that with the UI that Ryan has in mind the authz-id is actually > > the *perfect* thing to use anyways -- in some place in the UI the name > > of the mailbox will be necessary, and that's anyways what authz-id is > > used for in IMAP. > > > >> connection has been routed right, the server mechanism implementation > >> will verify that the resource identity is the same as the authzid if > >> given by the client, or the (now derived) authcid if authzid is absent. > >> If there is a mismatch, the mechanism must fail authentication. > > > > The authorization mechanism will be based on OAuth here, but that's a > > detail we don't care about right now. What we do care about is having > > the resource (mailbox) identified so that we may then use OAuth to > > perform authorization. > > > > The way to identify that resource is exceedingly clear to me now: it's > > the authz-id. > > > >> If you now react that the field is strictly speaking unnecessary because > >> you could deploy things in a two routing scenario as you mentioned, yes > >> I would agree, but I think we can consider accomodating Ryan's request > > > > Ryan has indicated that terminating the SASL exchange at the router is > > not a problem. So there's no need to look at this as a > > two-routing-problem problem. > > > > Just use the authz-id. > > > >> here if that is the simplest way to move forward and doesn't have any > >> significant downside. For deployment that can discover the right place > >> to route things immediately, the resource identity will just waste space > >> on the wire and require one unnecessary comparison at the end of the > >> server code. That's not a huge disadvantage to me. > > > > I'm not sure which request of Ryan's you're talking about. > > > > There could be protocols where the authz-id does not identify a > > resource, but that's OK: something else in those protocols will, and > > then authorization can proceed as expected. > > > > I believe it's now been established beyond doubt (certainly mine) that > > the authz-id *is* the one and only protocol element that Ryan needs > > here to identify the IMAP mailbox that the client is trying to access. > > > > Nico > > -- > > _______________________________________________ > > 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 > --14dae9340cdd1f5ead04ca3a083c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've been reading this thread, and following most of it. =A0It's be= en especially interesting to see the discussion about what's done [with= in SASL] vs in an app that uses SASL. =A0Excellent points by all.

<= /div>
It's also great to see that we've arrived at=A0consensus=A0on = the authzid being required. =A0I believe this makes a lot of sense when usi= ng OAuth, and fully support it. =A0

Thank you all = for taking the time to work through this. =A0The overall attitude of the di= scussion - "Let's figure out how to solve Ryan's problem"= - was fantastic. =A0This is what makes standards bodies work. =A0And if a = final proposal was made that didn't enable me to solve my problem, it c= ertainly wouldn't have been for lack of honest discussion and trying.

-R


On Fri, Sep 21, 2012 at 9:23 AM, John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:
Agreed.

For Imap and XMPP authz looks like email address and that fits.
For other protocols (perhaps calendaring or something) the authzid may be d= ifferent but that should not be a problem.

I think the authzid should always be sent to avoid interoperability issues.=

John B.

On 2012-09-21, at 12:41 PM, Nico Williams <nico@cryptonector.com> wrote:

> On Thu, Sep 20, 2012 at 3:54 PM, Simon Josefsson <simon@josefsson.org> wrote:
>> Nico Williams <nico@cr= yptonector.com> writes:
>>> The server *app*. =A0If it insists on something that only one = mechanism
>>> provides, then that app will only work with that one mechanism= .
>>
>> Ah. =A0Now I think I understand what you are getting at. =A0I neve= r intended
>> to propose that the server application should do anything with the=
>> resource identity. =A0The server application would normally never = care
>> about it. =A0It is an OAuth SASL mechanism internal field. =A0The = fields'
>> only purpose is to allow deployments like Ryan's to be able to= route the
>> connection right without having to parse other fields. =A0Once the=
>
> Because the server *app* is the one doing the routing in that case, > and because it simply *must* do this routing, Ryan's server would<= br> > *insist* on this value being present, thus binding itself tightly to > this one mechanism.
>
> But note that this value might as well be the authz-id, which all SASL=
> mechanisms support.
>
> Therefore it's best if we use the authz-id for this.
>
> Note that with the UI that Ryan has in mind the authz-id is actually > the *perfect* thing to use anyways -- in some place in the UI the name=
> of the mailbox will be necessary, and that's anyways what authz-id= is
> used for in IMAP.
>
>> connection has been routed right, the server mechanism implementat= ion
>> will verify that the resource identity is the same as the authzid = if
>> given by the client, or the (now derived) authcid if authzid is ab= sent.
>> If there is a mismatch, the mechanism must fail authentication. >
> The authorization mechanism will be based on OAuth here, but that'= s a
> detail we don't care about right now. =A0What we do care about is = having
> the resource (mailbox) identified so that we may then use OAuth to
> perform authorization.
>
> The way to identify that resource is exceedingly clear to me now: it&#= 39;s
> the authz-id.
>
>> If you now react that the field is strictly speaking unnecessary b= ecause
>> you could deploy things in a two routing scenario as you mentioned= , yes
>> I would agree, but I think we can consider accomodating Ryan's= request
>
> Ryan has indicated that terminating the SASL exchange at the router is=
> not a problem. =A0So there's no need to look at this as a
> two-routing-problem problem.
>
> Just use the authz-id.
>
>> here if that is the simplest way to move forward and doesn't h= ave any
>> significant downside. =A0For deployment that can discover the righ= t place
>> to route things immediately, the resource identity will just waste= space
>> on the wire and require one unnecessary comparison at the end of t= he
>> server code. =A0That's not a huge disadvantage to me.
>
> I'm not sure which request of Ryan's you're talking about.=
>
> There could be protocols where the authz-id does not identify a
> resource, but that's OK: something else in those protocols will, a= nd
> then authorization can proceed as expected.
>
> I believe it's now been established beyond doubt (certainly mine) = that
> the authz-id *is* the one and only protocol element that Ryan needs > here to identify the IMAP mailbox that the client is trying to access.=
>
> Nico
> --
> _______________________________________________
> 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

--14dae9340cdd1f5ead04ca3a083c-- From stephen.farrell@cs.tcd.ie Fri Sep 21 11:36: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 82A0A21E80B9 for ; Fri, 21 Sep 2012 11:36:53 -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 dJQ9b4FEMFL2 for ; Fri, 21 Sep 2012 11:36:52 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7A611E808A for ; Fri, 21 Sep 2012 11:36:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 497131044DD; Fri, 21 Sep 2012 19:36:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1348252604; bh=oIxgpkj61QJYbCW/JDaeSRzW t8Q2hHM8p9acttBNNZM=; b=DGikLjBNFaRUO3beStI2fAiHCVCZorLUZ2oLQk/B 6TXR7H83TduyeTKhI4nUpX+O7n4N3nX+ECC1ijtugLh9fh+vaz1oRV0u+lGr2MZn bhhMwL02B89pxEUuou7seuCjjZfDBmorLWMexZAZu6EIJPpxP+u9WLpdgXt5udb+ WVe7tl1w1h4nVt7BHMqLJwyoKRe+zG+1btj3LK8B7eHTT6aOnsoA3cCqqhz2lSF/ 7eP0nBU2d2XsKn2wUtRlC41yTSmc21WsWcb0hOZFPC8ckiG/cfzBgx2Q6kgcegCR Wb2HIw585AebWvRcT2aU+xvMIUnpC3bLop5JmF9Kg49SBg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id y-BAjyX7mgF9; Fri, 21 Sep 2012 19:36:44 +0100 (IST) Received: from [10.87.48.8] (unknown [86.46.20.245]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2F6461044DC; Fri, 21 Sep 2012 19:36:41 +0100 (IST) Message-ID: <505CB3B9.6040801@cs.tcd.ie> Date: Fri, 21 Sep 2012 19:36:41 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "krb-wg mailing list (ietf-krb-wg@lists.anl.gov)" , kitten@ietf.org X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [kitten] kerberos/kitten merger 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, 21 Sep 2012 18:36:53 -0000 Hi all, I'm glad to see that both WGs are meeting in Atlanta and that you're doing the joint meeting thing again, which worked well last time. The chairs of both WGs and I have been discussing the rate of progress of work items in kitten and kerberos, which has been impacted to some extent by a lack of available chair cycles in recent times. That situation shows no sign of getting better for some of the chairs so we will be making some changes in order to address this. The main thing is that we're going to merge the two WGs. As of now the best suggestion seems to be to formally close krb-wg and re-charter kitten to cover both sets of work. Both lists will remain open of course if we take that route. (Note that renaming kitten is not a good plan, that'd muck up various tools in various ways.) As part of this, we'll re-charter to revisit the set of work items with the goal of reducing the list to a set of items that we can credibly plan to get finished in the near term. (For some reasonable definition of "near term.") In terms of chairing, Sam Hartman and Shawn Emery are the current co-chairs who are best placed to provide the required cycles for now and so Sam and Shawn will be chairing the merged entity. I'll put that in place as soon as we've decided on the logistics of the merger. But we're also looking out for someone new who's got knowledge and energy and hasn't chaired a WG before as a 3rd co-chair, so please let Sam, Shawn and I know if you're interested in that. I'd like to thank Alexey, Tom, Jeff and Larry for all their great work with both WGs and look forward to seeing them continue that work along with all the rest of us. Thanks also to Sam and Shawn for their continued willingness to help us all get more good work out the door. So, the follow-up is that Sam and Shawn (with help from Jeff) will start a discussion about re-chartering the WGs to arrive at a set of work items and then we can discuss whether that's best done with two continuing WGs or whatever on the list and in Atlanta. Regards, Stephen. PS: Please note that this isn't meant to be any criticism of anyone, whether participant, author or chair. In discussing with the chairs, we felt that we needed to make some changes, could do better, and figured this seems like the best way to try for that as of now. From simon@josefsson.org Sat Sep 22 00:48: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 C787721F86A2 for ; Sat, 22 Sep 2012 00:48:25 -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 K3rYrvFMwQ+Q for ; Sat, 22 Sep 2012 00:48:25 -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 3FC6B21F847C for ; Sat, 22 Sep 2012 00:48: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 q8M7mCKS028702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 22 Sep 2012 09:48:14 +0200 From: Simon Josefsson To: Nico Williams References: <1348071262.95560.YahooMailNeo@web31805.mail.mud.yahoo.com> <692C2E0A-141E-43D8-B14F-42773B655711@ve7jtb.com> <87y5k5d8sv.fsf@latte.josefsson.org> <87mx0ld7ya.fsf@latte.josefsson.org> <87sjadmzjw.fsf@latte.josefsson.org> <87obl1mz0m.fsf@latte.josefsson.org> <87ipb84y83.fsf@latte.josefsson.org> <87zk4ka4g3.fsf@latte.josefsson.org> <87vcf8a3rk.fsf@latte.josefsson.org> <87k3vo9zzl.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120922:kitten@ietf.org::jahFYnINaRJFV2m9:60yy X-Hashcash: 1:22:120922:nico@cryptonector.com::FSPeKpyZPIxpSeRw:KkLz Date: Sat, 22 Sep 2012 09:48:11 +0200 In-Reply-To: (Nico Williams's message of "Fri, 21 Sep 2012 10:41:59 -0500") Message-ID: <87ipb65whw.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] Google and 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, 22 Sep 2012 07:48:25 -0000 Nico Williams writes: > But note that this value might as well be the authz-id, which all SASL > mechanisms support. > > Therefore it's best if we use the authz-id for this. This is okay by me -- the problem I see with this is that 1) some non-standard documentation is needed on how to setup clients, and 2) if the OAuth mechanism ends up being used through the GSS-API no authorization identity may be available. I think we can live with these issues. The second I believe we can solve with naming attributes if it becomes important to solve it. /Simon From hannes.tschofenig@gmx.net Sat Sep 22 02:17: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 D139821F86DF for ; Sat, 22 Sep 2012 02:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.327 X-Spam-Level: X-Spam-Status: No, score=-102.327 tagged_above=-999 required=5 tests=[AWL=0.272, 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 Sn8nnXhRizE6 for ; Sat, 22 Sep 2012 02:17:57 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id DFA8921F86F6 for ; Sat, 22 Sep 2012 02:17:56 -0700 (PDT) Received: (qmail invoked by alias); 22 Sep 2012 09:17:55 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.216.191] by mail.gmx.net (mp037) with SMTP; 22 Sep 2012 11:17:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+B4zsFPnWBPzWK5c7rQmLRvjR5VNh03fI7pq5+L2 0u8mnZtwRL/N2Y Message-ID: <505D823F.8050404@gmx.net> Date: Sat, 22 Sep 2012 12:17:51 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Stephen Farrell References: <505CB3B9.6040801@cs.tcd.ie> In-Reply-To: <505CB3B9.6040801@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: kitten@ietf.org Subject: Re: [kitten] kerberos/kitten merger 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, 22 Sep 2012 09:17:59 -0000 Works for me. One could even argue that it makes sense to merge EMU in here as well since it is the same group of people and it also fits topic-wise. Thank you Tom and Alexey for your work in chairing the kitten WG. On 09/21/2012 09:36 PM, Stephen Farrell wrote: > > Hi all, > > I'm glad to see that both WGs are meeting in Atlanta > and that you're doing the joint meeting thing again, > which worked well last time. > > The chairs of both WGs and I have been discussing > the rate of progress of work items in kitten and > kerberos, which has been impacted to some extent by > a lack of available chair cycles in recent times. > That situation shows no sign of getting better > for some of the chairs so we will be making some > changes in order to address this. > > The main thing is that we're going to merge the > two WGs. > > As of now the best suggestion seems to be to > formally close krb-wg and re-charter kitten to > cover both sets of work. Both lists will remain > open of course if we take that route. (Note > that renaming kitten is not a good plan, that'd > muck up various tools in various ways.) > > As part of this, we'll re-charter to revisit the > set of work items with the goal of reducing the > list to a set of items that we can credibly plan > to get finished in the near term. (For some > reasonable definition of "near term.") > > In terms of chairing, Sam Hartman and Shawn Emery > are the current co-chairs who are best placed > to provide the required cycles for now and so > Sam and Shawn will be chairing the merged entity. > I'll put that in place as soon as we've decided > on the logistics of the merger. > > But we're also looking out for someone new who's > got knowledge and energy and hasn't chaired a > WG before as a 3rd co-chair, so please let Sam, > Shawn and I know if you're interested in that. > > I'd like to thank Alexey, Tom, Jeff and Larry > for all their great work with both WGs and look > forward to seeing them continue that work along > with all the rest of us. > > Thanks also to Sam and Shawn for their continued > willingness to help us all get more good work out > the door. > > So, the follow-up is that Sam and Shawn (with > help from Jeff) will start a discussion about > re-chartering the WGs to arrive at a set of work > items and then we can discuss whether that's best > done with two continuing WGs or whatever on the > list and in Atlanta. > > Regards, > Stephen. > > PS: Please note that this isn't meant to be any > criticism of anyone, whether participant, author > or chair. In discussing with the chairs, we felt > that we needed to make some changes, could do better, > and figured this seems like the best way to try > for that as of now. > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From Josh.Howlett@ja.net Sat Sep 22 03:42: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 E749421F86CA for ; Sat, 22 Sep 2012 03:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 5Zareu8a0sP5 for ; Sat, 22 Sep 2012 03:42:04 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id E4D8321F8685 for ; Sat, 22 Sep 2012 03:42:03 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 46E7B4A6B76_5D95FAB; Sat, 22 Sep 2012 10:42:02 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 192744A6B47_5D95FAF; Sat, 22 Sep 2012 10:42:02 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Sat, 22 Sep 2012 11:42:01 +0100 From: Josh Howlett To: Hannes Tschofenig , Stephen Farrell Thread-Topic: [kitten] kerberos/kitten merger Thread-Index: AQHNmKM++eBNNrE7MU6Cr5DpbS2crJeWLF0A Date: Sat, 22 Sep 2012 10:42:01 +0000 Message-ID: In-Reply-To: <505D823F.8050404@gmx.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "kitten@ietf.org" Subject: Re: [kitten] kerberos/kitten merger 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, 22 Sep 2012 10:42:05 -0000 > >One could even argue that it makes sense to merge EMU in >here as well since it is the same group of people and it also fits >topic-wise. +1, interesting idea. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From alexey.melnikov@isode.com Sat Sep 22 23:22: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 1569C21F851B for ; Sat, 22 Sep 2012 23:22:45 -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 WLi-oC36rg0m for ; Sat, 22 Sep 2012 23:22:44 -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 3E36C21F84A1 for ; Sat, 22 Sep 2012 23:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1348381362; d=isode.com; s=selector; i=@isode.com; bh=bIx13BsKatNh4rPdbvERZlFtfwhF7kxV0IOQxjHjeZs=; 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=mKGgqNmDcKa4bAhMKFssGbDDptIQ7mosfeVy4OUeFP6ZYo8r2BZmvLZaYNILNe4iHf+imS sztaXB9afSpXqTrxSfXY7OZjZIdjbA4hjcsGvXeAyWGvLXky8EloCcM0UMJBfcSsbQziFm NQerzJ1MwxdW5/2vZHW0vwNAjEBOfS8=; Received: from [192.168.1.6] (ppp95-165-112-31.pppoe.spdop.ru [95.165.112.31]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2012 07:22:41 +0100 Message-ID: <505EAAC3.1040005@isode.com> Date: Sun, 23 Sep 2012 07:22:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "kitten@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-08.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: Sun, 23 Sep 2012 06:22:45 -0000 On behalf of Kitten WG chairs I would like to initiate 2 weeks Working Group Last Call on draft-ietf-kitten-sasl-oauth-08.txt. Please reply with your comments (positive and/or negative) directly to the mailing list or to WG chairs kitten-chairs@tools.ietf.org. Statement of support such as "I reviewed the document and it looks ready for publication" will also be appreciated. Alexey, as [outgoing] Kitten co-chair. From hartmans@mit.edu Sun Sep 23 12:16: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 E5CA521F84D5 for ; Sun, 23 Sep 2012 12:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.782 X-Spam-Level: X-Spam-Status: No, score=-97.782 tagged_above=-999 required=5 tests=[AWL=-4.670, BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.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 du7AdprbmDqO for ; Sun, 23 Sep 2012 12:16:08 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7231821F84B6 for ; Sun, 23 Sep 2012 12:16:08 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 52313202A9; Sun, 23 Sep 2012 15:15:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EA5D6414A; Sun, 23 Sep 2012 15:15:31 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org,ietf-krb-wg@anl.gov Date: Sun, 23 Sep 2012 15:15:31 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] Call for Volunteers: Adding Energy to the WG 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, 23 Sep 2012 19:16:09 -0000 As Stephen mentioned, we're looking for people who would be interested in helping to contribute to the WG. We'd be interested in finding an energetic third chair. For that position, you'd need to have some existing IETF experience--contributing to WGs, possibly writing documents--and a willingness to learn and particularly to learn IETF process. however, now is a great time to step forward and say that you're interested in what's going on in kitten or Kerberos and would like to help out. I think this set of working groups is really exciting because of the bredth of the application security space we cover. We have some folks who are really looking for light-weight no-crypto mechanisms like sasl-openid. On the other side we have the Kerberos and multi-mech GSS-API platform folks who are looking for mutual authenticationd and phishing defense and who aren't as concerned about mechanism complexity because they have shared infrastructure across a platform. I think we can all learn from each other and do great work together. So, I think now is a great time to get involved in the IETF and these working groups. If you agree, please drop Shawn and I a note and let us know what your experience is. If you have the energy we'll find a way for you to help out! --Sam From hartmans@mit.edu Sun Sep 23 12:18: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 C517721F84E4 for ; Sun, 23 Sep 2012 12:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.595 X-Spam-Level: X-Spam-Status: No, score=-98.595 tagged_above=-999 required=5 tests=[AWL=-2.883, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.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 g0qNwDy9mifL for ; Sun, 23 Sep 2012 12:18:53 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2CF21F84D5 for ; Sun, 23 Sep 2012 12:18:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 65C2C20132; Sun, 23 Sep 2012 15:18:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1ED86414A; Sun, 23 Sep 2012 15:18:17 -0400 (EDT) From: Sam Hartman To: Hannes Tschofenig References: <505CB3B9.6040801@cs.tcd.ie> <505D823F.8050404@gmx.net> Date: Sun, 23 Sep 2012 15:18:17 -0400 In-Reply-To: <505D823F.8050404@gmx.net> (Hannes Tschofenig's message of "Sat, 22 Sep 2012 12:17:51 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] kerberos/kitten merger 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, 23 Sep 2012 19:18:53 -0000 >>>>> "Hannes" == Hannes Tschofenig writes: Hannes> Works for me. One could even argue that it makes sense to Hannes> merge EMU in here as well since it is the same group of Hannes> people and it also fits topic-wise. Is there really significant kitten-emu overlap? I haven't been paying attention to that. I think that EMU has some really important work in TEAP and reasonably active chairs, so I'd hate to see that disrupted. From hotz@jpl.nasa.gov Mon Sep 24 11:17: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 3D7AD21F881E for ; Mon, 24 Sep 2012 11:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 w19+Crweh49Q for ; Mon, 24 Sep 2012 11:17:35 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id E889B21F8588 for ; Mon, 24 Sep 2012 11:17:34 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8OIHUXq032169 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 24 Sep 2012 11:17:31 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Mon, 24 Sep 2012 11:17:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8CCDEB08-0F44-4601-AD8F-F44B2B50F1E2@jpl.nasa.gov> References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] [Ietf-krb-wg] Call for Volunteers: Adding Energy to the WG 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, 24 Sep 2012 18:17:36 -0000 I can't imagine I have time for this, since I don't have time to read a = version of every draft, but I have to ask: what, exactly would the job = entail and how much time would it take? On Sep 23, 2012, at 12:15 PM, Sam Hartman wrote: > As Stephen mentioned, we're looking for people who would be interested > in helping to contribute to the WG. > We'd be interested in finding an energetic third chair. > For that position, you'd need to have some existing IETF > experience--contributing to WGs, possibly writing documents--and a > willingness to learn and particularly to learn IETF process. >=20 > however, now is a great time to step forward and say that you're > interested in what's going on in kitten or Kerberos and would like to > help out. I think this set of working groups is really exciting = because > of the bredth of the application security space we cover. We have = some > folks who are really looking for light-weight no-crypto mechanisms = like > sasl-openid. On the other side we have the Kerberos and multi-mech > GSS-API platform folks who are looking for mutual authenticationd and > phishing defense and who aren't as concerned about mechanism = complexity > because they have shared infrastructure across a platform. >=20 > I think we can all learn from each other and do great work together. > So, I think now is a great time to get involved in the IETF and these > working groups. If you agree, please drop Shawn and I a note and let = us > know what your experience is. If you have the energy we'll find a way > for you to help out! >=20 > --Sam > _______________________________________________ > ietf-krb-wg mailing list > ietf-krb-wg@lists.anl.gov > https://lists.anl.gov/mailman/listinfo/ietf-krb-wg ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From hartmans@mit.edu Tue Sep 25 03:32: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 482DC21F8883 for ; Tue, 25 Sep 2012 03:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.809 X-Spam-Level: X-Spam-Status: No, score=-97.809 tagged_above=-999 required=5 tests=[AWL=-2.097, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.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 a3z30KyMq8af for ; Tue, 25 Sep 2012 03:32:19 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id ACC9F21F883D for ; Tue, 25 Sep 2012 03:32:19 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 594CA20155 for ; Tue, 25 Sep 2012 06:25:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EC159414A; Tue, 25 Sep 2012 06:24:33 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org Date: Tue, 25 Sep 2012 06:24:33 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [kitten] [The IESG] [abfab] Last Call: (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard 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, 25 Sep 2012 10:32:20 -0000 --=-=-= hi. The GSS EAP naming draft is in last call. I wanted to make sure that people here saw the discussion. Simon has already sent review comments. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Thu, 20 Sep 2012 10:17:18 -0400 X-Sieve: CMU Sieve 2.2 Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by mail.suchdamage.org (Postfix) with ESMTP id E5A452029E for ; Thu, 20 Sep 2012 10:17:17 -0400 (EDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F192E21F86E5; Thu, 20 Sep 2012 07:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1348150647; bh=JHb6BXb9ZolGFk2cMRn9SbK7fvYrFqOhN7TrSRwx2Ng=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=SgtVtF+n8SUqKfq4R0syQLy+x5mp/NqS3/oKU4Kqnhwf/N2FqKRc6Pu+4FAir5lE1 NJNVNsFubtm3zABxIJkOkd25kypvIbEchm2FT28LFaq4DU4daojsHNrL3PGkcnXw/O bdAgzoRtYvwRXAbnN8EFMMhRaejPtc3Oj4ISkH08= X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F040421F8798; Thu, 20 Sep 2012 07:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 5E3FiVJKVCog; Thu, 20 Sep 2012 07:17:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7730221F86E5; Thu, 20 Sep 2012 07:17:17 -0700 (PDT) From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120920141717.4821.29598.idtracker@ietfa.amsl.com> Date: Thu, 20 Sep 2012 07:17:17 -0700 Cc: abfab@ietf.org Subject: [abfab] Last Call: (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: abfab-bounces@ietf.org Errors-To: abfab-bounces@ietf.org X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Sep 20 10:17:18 2012 X-DSPAM-Confidence: 0.5643 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,505b256e169696091720408 X-DSPAM-Factors: 27, From*The IESG , 0.00010, List-Subscribe* as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-10-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The naming extensions to the Generic Security Services Application Programming interface provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication/Authorization/Accounting peer to provide authorization attributes along side an authentication response. It also provides mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes the necessary information to use the naming extensions API to access that information. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap-naming/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap-naming/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab --=-=-=-- From cgrundman@gmail.com Sat Sep 29 06:35: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 4190B21F84DF for ; Sat, 29 Sep 2012 06:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 Uww9qVxb3Gf2 for ; Sat, 29 Sep 2012 06:35:49 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B3C1A21F84D8 for ; Sat, 29 Sep 2012 06:35:49 -0700 (PDT) Received: by oagn5 with SMTP id n5so4617183oag.31 for ; Sat, 29 Sep 2012 06:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=VWgT9WRIZtAjCi3M6/uneFR1rU3IdVoHyAJkt7xp0jg=; b=0K0W4UCNSTPx2zbQalriAZk9aFCiLG1ST6AQgPFOZtFUM450m2e/4GmGE8CqoNdMd/ Th4MTWy41efRImIjiHYJHLcwcrkjxxPnai50Q6wKYiMnBV54vJau8TDTa0GXb+oRHCi1 huNQDrCqJ6dzJoms9kat96PFm8QZRbNWk+6JuYSDte6SQ6HWi6lJluA3asGxXIHi3q2L E5wcpXRNlVRdPFKQppQtSzTfYmFgsgH+xKJVFrb+g03piDSg/WoKXs4UUb+ddVpqiL2V An5eRBZ5puzSs0vjhZaZG4BPrkvPy/jr4HeIHFtxTvmeg3ySbyC8aGqMZGd2RwH+8Zvw 1I5Q== MIME-Version: 1.0 Received: by 10.60.170.229 with SMTP id ap5mr7946947oec.101.1348925749338; Sat, 29 Sep 2012 06:35:49 -0700 (PDT) Received: by 10.182.59.165 with HTTP; Sat, 29 Sep 2012 06:35:49 -0700 (PDT) Date: Sat, 29 Sep 2012 09:35:49 -0400 Message-ID: From: Chaskiel Grundman To: kitten@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [kitten] OAUTH Gssapi mechanism 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, 29 Sep 2012 14:01:41 -0000 I recently read this document (after hacking on some code to use google's xoauth mechs in imap), and I have some questions/comments about the gssapi section. >OAuth mechanims security contexts always have the mutual_state flag > (GSS_C_MUTUAL_FLAG) set to TRUE. > The mutual authentication property of this mechanism relies on > successfully comparing the TLS server identity with the negotiated > target name. While this may be true of OAUTH10A when signatures are used, I don't see how it can be the case with OAUTHBEARER. What negotiated target name? > OAuth supports a standard generic name syntax for acceptors, such as > GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). These > service names MUST be associated with the "entityID" claimed by the > RP. These (SAML-ish) terms are not mentioned anywhere else in this document. From wmills@yahoo-inc.com Sat Sep 29 09:02: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 BFD4421F8619 for ; Sat, 29 Sep 2012 09:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.591 X-Spam-Level: X-Spam-Status: No, score=-17.591 tagged_above=-999 required=5 tests=[AWL=0.006, 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 X8Rbm5Q39MUR for ; Sat, 29 Sep 2012 09:02:26 -0700 (PDT) Received: from nm8-vm3.bullet.mail.ne1.yahoo.com (nm8-vm3.bullet.mail.ne1.yahoo.com [98.138.91.138]) by ietfa.amsl.com (Postfix) with SMTP id D670621F8617 for ; Sat, 29 Sep 2012 09:02:25 -0700 (PDT) Received: from [98.138.90.50] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 29 Sep 2012 16:02:17 -0000 Received: from [98.138.87.5] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 29 Sep 2012 16:02:17 -0000 Received: from [127.0.0.1] by omp1005.mail.ne1.yahoo.com with NNFMP; 29 Sep 2012 16:02:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 411344.27423.bm@omp1005.mail.ne1.yahoo.com Received: (qmail 81600 invoked by uid 60001); 29 Sep 2012 16:02:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348934536; bh=espMYGAZR/LbBQxDiHZfOXOgs0JmsEOM50emwU9C3o8=; 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=Ru9dteYx19bNWSAxoV1Nz4Jc1MHuOE4dieS+4Bhdm4pY43x5ON0a1gwaEg1OSB0dgxoFcu3eonGD8D4dBrmYH1u1jrSIN4DrWdw0tJcnPIc+8O21i+aQJEhq5ZnW+i0AFVv6W33pVbmPycEj2THfoOv7UWUTXW6Y7Lw/+7PfsYA= 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=Nzr15UoqfJGpwLnXAQBBfXZxfJsvFM771uJAk5asqqJQq+xs2++Li+005+I9qs5OEgRgZ/5OkDbxfEsWmO5m1lUfFW5yjiMbNs0FkvgfvT0+KreIXzSeCAd6I3GAFFz7S3X1lfbg6jQ6Et0EQYPnaeoSwwoE6vDB7JmVc9hYaYo=; X-YMail-OSG: bWyZ6usVM1kvSHK9vlj5ehyNl9AozDwr0x4wLWoM70g6MYe vw2RPt3rPHGOAb59k3xWMNDWx6aENqVx5I.TxVsFhPPX5AjOvD9uXPqAGa5b g.2mZ.hY0vlafCD9S.OsGILNbjdWphcHKcQDT9wA54._Q0RIU2G7xMNGUuyA DmMUBXRPPLD9c1rt0mBOZaAHWNaNoeJblGWa7kWs5nSWGESY7WBNRWxcse5m DEBDJbwtbeV1xT5Ep2JHH22xBP4eCoQyfacBI_fOEpESo_veNjbul8SBGOmr QuIPFEIpFv9K27qVK3eeCrgByd08AM.J0cD5C91tCxn4rK9wC9lFCwPV7Awp uDg1yDik1fH27mFmljIFpVeGSQ65_4_vqGC967FNXFgZDTKO0wniG_xpshzc dKQdVf6yfT1.LQOkVRpxPoEEJ2enEhfo.YENEnhRXEqIOkK6waKo1bcyNoba yyznM_WMN_8lb Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Sat, 29 Sep 2012 09:02:16 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.122.442 References: Message-ID: <1348934536.61862.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Sat, 29 Sep 2012 09:02:16 -0700 (PDT) From: William Mills To: Chaskiel Grundman , "kitten@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-460417969-1348934536=:61862" Subject: Re: [kitten] OAUTH Gssapi mechanism 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, 29 Sep 2012 16:02:26 -0000 --764183289-460417969-1348934536=:61862 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'm gonna have to defer to Hannes on this, but I believe that the negotiate= d target name in this case is the endpoint receiving the connection and aut= henticated by the SSL certificate.=A0 Not sure on entityID.=0A=0A-bill=0A= =0A=0A=0A=0A=0A>________________________________=0A> From: Chaskiel Grundma= n =0A>To: kitten@ietf.org =0A>Sent: Saturday, Septembe= r 29, 2012 6:35 AM=0A>Subject: [kitten] OAUTH Gssapi mechanism=0A> =0A>I re= cently read this document (after hacking on some code to use=0A>google's xo= auth mechs in imap), and I have some questions/comments=0A>about the gssapi= section.=0A>=0A>>OAuth mechanims security contexts always have the mutual_= state flag=0A>>=A0 (GSS_C_MUTUAL_FLAG) set to TRUE.=0A>>=A0 The mutual au= thentication property of this mechanism relies on=0A>>=A0 successfully comp= aring the TLS server identity with the negotiated=0A>>=A0 target name.=0A>= =0A>While this may be true of OAUTH10A when signatures are used, I don't=0A= >see how it can be the case with OAUTHBEARER. What negotiated target=0A>nam= e?=0A>=0A>> OAuth supports a standard generic name syntax for acceptors, su= ch as=0A>> GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1).=A0 Thes= e=0A>> service names MUST be associated with the "entityID" claimed by the= =0A>> RP.=0A>These (SAML-ish) terms are not mentioned anywhere else in this= document.=0A>_______________________________________________=0A>Kitten mai= ling list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/listinfo/kitte= n=0A>=0A>=0A> --764183289-460417969-1348934536=:61862 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I'm gonna= have to defer to Hannes on this, but I believe that the negotiated target = name in this case is the endpoint receiving the connection and authenticate= d by the SSL certificate.  Not sure on entityID.

-bill
=

=
From: Chaskiel Grundman <cgrundman@gmail.com>
To: kitten@ietf.org
Sent: Saturday, September 29, 2012 6:35 AM
Subject: [kitten] OAUTH Gssapi mech= anism

I recently read this document (after hacking o= n some code to use
google's xoauth mechs in imap), and I have some quest= ions/comments
about the gssapi section.

>OAuth mechanims secur= ity contexts always have the mutual_state flag
>  (GSS_C_MUTUAL= _FLAG) set to TRUE.
>  The mutual authentication property of th= is mechanism relies on
>  successfully comparing the TLS server = identity with the negotiated
>  target name.

While this = may be true of OAUTH10A when signatures are used, I don't
see how it can= be the case with OAUTHBEARER. What negotiated target
name?

> = OAuth supports a standard generic name syntax for acceptors, such as
>= ; GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1).  These
> service names MUST be associated with the "entityID" claimed= by the
> RP.
These (SAML-ish) terms are not mentioned anywhere el= se in this document.
_______________________________________________
= Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listi= nfo/kitten


--764183289-460417969-1348934536=:61862-- From cantor.2@osu.edu Sat Sep 29 10:06: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 AEE4321F850B for ; Sat, 29 Sep 2012 10:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.528 X-Spam-Level: X-Spam-Status: No, score=-5.528 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 d+OouuJwJtqe for ; Sat, 29 Sep 2012 10:06:52 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id E2DC821F8550 for ; Sat, 29 Sep 2012 10:06:50 -0700 (PDT) Received: from mail228-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Sat, 29 Sep 2012 17:06:49 +0000 Received: from mail228-va3 (localhost [127.0.0.1]) by mail228-va3-R.bigfish.com (Postfix) with ESMTP id 06977CC00F4; Sat, 29 Sep 2012 17:06:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.168; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT05.osuad.osu.edu; RD:cio-tnc-ht05.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: PS-4(zzbb2dI98dI9371I1432Izz1d77h1202h1d1ah1d2ahzz8275bhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h) Received-SPF: pass (mail228-va3: domain of osu.edu designates 164.107.81.168 as permitted sender) client-ip=164.107.81.168; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT05.osuad.osu.edu ; suad.osu.edu ; Received: from mail228-va3 (localhost.localdomain [127.0.0.1]) by mail228-va3 (MessageSwitch) id 1348938406490566_25685; Sat, 29 Sep 2012 17:06:46 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.238]) by mail228-va3.bigfish.com (Postfix) with ESMTP id 6AC8B540043; Sat, 29 Sep 2012 17:06:46 +0000 (UTC) Received: from CIO-TNC-HT05.osuad.osu.edu (164.107.81.168) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 29 Sep 2012 17:06:43 +0000 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; Sat, 29 Sep 2012 13:06:43 -0400 From: "Cantor, Scott" To: William Mills , Chaskiel Grundman , "kitten@ietf.org" Thread-Topic: [kitten] OAUTH Gssapi mechanism Thread-Index: AQHNnkr4zXeVO0ueGkG95HL01VCYYZehvg8A///O7gA= Date: Sat, 29 Sep 2012 17:06:43 +0000 Message-ID: In-Reply-To: <1348934536.61862.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: <33664D8B08662446968E590BF871FD9A@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: osu.edu Subject: Re: [kitten] OAUTH Gssapi mechanism 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, 29 Sep 2012 17:06:53 -0000 On 9/29/12 12:02 PM, "William Mills" wrote: > >I'm gonna have to defer to Hannes on this, but I believe that the >negotiated target name in this case is the endpoint receiving the >connection and authenticated by the SSL certificate. Not sure on >entityID. You must have copied text from my spec, that's where "entityID" came from. -- Scott From wmills@yahoo-inc.com Sat Sep 29 15:09: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 E941221F8595 for ; Sat, 29 Sep 2012 15:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.592 X-Spam-Level: X-Spam-Status: No, score=-17.592 tagged_above=-999 required=5 tests=[AWL=0.006, 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 Sno2Gyn7H7iU for ; Sat, 29 Sep 2012 15:09:55 -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 2503721F85A8 for ; Sat, 29 Sep 2012 15:09:54 -0700 (PDT) Received: from [98.138.90.55] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 29 Sep 2012 22:09:49 -0000 Received: from [98.138.226.162] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 29 Sep 2012 22:09:49 -0000 Received: from [127.0.0.1] by omp1063.mail.ne1.yahoo.com with NNFMP; 29 Sep 2012 22:09:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 508562.41103.bm@omp1063.mail.ne1.yahoo.com Received: (qmail 58176 invoked by uid 60001); 29 Sep 2012 22:09:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1348956589; bh=PFY1LitX4Ng7LOyX2GEGgD6ifyUaOYLO9GJNlDonQEQ=; 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=tIcKA+/p5b9kH8wRtn9Uetd5N/OGT8K5IEmk7Mi625/UuelPhYeg5YV7d6VrBHIkemyNTRKK4gEAWjWpVFTq1o0uCueogioIcvU7gIadph6c2by5jVYpMY0biGAAo0YZVefs+VpJ69SEeFXFUK6uDr3VZmdC9k/c5M+yv7OrnZs= 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=FoLCrKnNdg3ry/76vZJ/GQNYZNo97UJJkhVJ63k3clPh+5vvOZ8yACNWJkkHHZeGSQlsWuOWC3csis7l8ATlCZIWhrjb6qNXhsIWD6B16CY0FOv/ubrm3f864XRSApYR2N54qePBl0MWe643XCgzwt42VCz4SDDSTO61ruwXBVE=; X-YMail-OSG: A3s3WBoVM1l2JcaBZFCXsYbC13j7QrlNMb1OL0brLeTNUjx atOOZjF3pujAOtkiCOlvF5kwzdfclHwUBWbXW6atiP6Qo7FldpM8_B9WyecQ k7mHvhOsN6kjKhkdg4a_Cj4gJj0ACe4qsZDT_ENhFXiSWR01YijPLre.g3ts v7.yO4q5otOlOH0mBeUucorzEav8HIxrf6p7OWQFJHxfpCbF3om18_chwbX_ aE0snHPRSg_o2Zo.qD5y2QiwRe7MD48UlqJZv8ybVajrWwYPyGlJA7CLCqDx OXHaQN4Z_T_vIPVOGnm3yKYSKnSX8qbB4Zhil50ufYA36bu58hFBE2mAl5tJ 7Y50MPXEHu0I_NScwDirBESj9Q6BdbVHg__fckcDs0WjI06vDzFd4o1F0Bt_ mflHIWbCXnlulVeSzWQg898UvYgUgXpiw5yVG.AWidKJrEFN.3HI4hn7YLDs JLHdIl1uiKAN1ZA-- Received: from [99.31.212.42] by web31810.mail.mud.yahoo.com via HTTP; Sat, 29 Sep 2012 15:09:48 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.122.442 References: <1348934536.61862.YahooMailNeo@web31811.mail.mud.yahoo.com> Message-ID: <1348956588.88431.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Sat, 29 Sep 2012 15:09:48 -0700 (PDT) From: William Mills To: "Cantor, Scott" , Chaskiel Grundman , "kitten@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1935884094-523159234-1348956588=:88431" Subject: Re: [kitten] OAUTH Gssapi mechanism 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, 29 Sep 2012 22:09:56 -0000 --1935884094-523159234-1348956588=:88431 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'm not exactly sure where that text came from.=A0 Whether it's mine or Han= nes'.=0A=0A=0A=0A=0A=0A>________________________________=0A> From: "Cantor,= Scott" =0A>To: William Mills ; Cha= skiel Grundman ; "kitten@ietf.org" = =0A>Sent: Saturday, September 29, 2012 10:06 AM=0A>Subject: Re: [kitten] OA= UTH Gssapi mechanism=0A> =0A>On 9/29/12 12:02 PM, "William Mills" wrote:=0A>>=0A>>I'm gonna have to defer to Hannes on this, bu= t I believe that the=0A>>negotiated target name in this case is the endpoin= t receiving the=0A>>connection and authenticated by the SSL certificate.=A0= Not sure on=0A>>entityID.=0A>=0A>You must have copied text from my spec, t= hat's where "entityID" came from.=0A>=0A>-- Scott=0A>=0A>=0A>=0A>=0A> --1935884094-523159234-1348956588=:88431 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I'm not e= xactly sure where that text came from.  Whether it's mine or Hannes'.<= br>


From: "Cantor, Scott" <cantor.2@osu.edu>
To: William Mills <wmills@yahoo-in= c.com>; Chaskiel Grundman <cgrundman@gmail.com>; "kitten@ietf.org"= <kitten@ietf.org>
Sent: Saturday, September 29, 2012 10:06 AM
Subject: Re: [kitten] OAUTH Gssapi mechanism
 <= /div>
On 9/29/12 12:02 PM, "William Mills" <wmills@yahoo-inc.co= m> wrote:
>
>I'm gonna have to defer to Hannes on this, = but I believe that the
>negotiated target name in this case is the en= dpoint receiving the
>connection and authenticated by the SSL certifi= cate.  Not sure on
>entityID.

You must have copied text f= rom my spec, that's where "entityID" came from.

-- Scott


=

--1935884094-523159234-1348956588=:88431--