Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-15
Bill Mills <wmills_92105@yahoo.com> Mon, 08 September 2014 20:32 UTC
Return-Path: <wmills_92105@yahoo.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065A51A029C for <kitten@ietfa.amsl.com>; Mon, 8 Sep 2014 13:32:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.151
X-Spam-Level:
X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCLIifcwoFs3 for <kitten@ietfa.amsl.com>; Mon, 8 Sep 2014 13:32:20 -0700 (PDT)
Received: from nm39-vm9.bullet.mail.bf1.yahoo.com (nm39-vm9.bullet.mail.bf1.yahoo.com [72.30.239.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1A61A034F for <kitten@ietf.org>; Mon, 8 Sep 2014 13:32:19 -0700 (PDT)
Received: from [98.139.212.150] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 08 Sep 2014 20:32:19 -0000
Received: from [98.139.212.229] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 08 Sep 2014 20:32:18 -0000
Received: from [127.0.0.1] by omp1038.mail.bf1.yahoo.com with NNFMP; 08 Sep 2014 20:32:18 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 926954.29240.bm@omp1038.mail.bf1.yahoo.com
Received: (qmail 66616 invoked by uid 60001); 8 Sep 2014 20:32:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1410208338; bh=WCtMvH/N2mXYKzif5SBOWOMgNA6KpAk5oCKExC65Wcg=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=I2Vzh6kk/qMHBWme5LnQgB5QilK+C0wFitXwHMZy3pJzmhjbA/OYPfDDLpiRqLb+wlhY9fTFUpH98zIW4IcyRl0zI23grGDJ3fnYrvP7+LDUqJtL06m2pk0gSJy/W90DNORTva+eSj8CDQfRHSY5/fGs1flsUx7ZC0C+K1UinSU=
X-YMail-OSG: E_YxSKUVM1nL4n6RD..Nproa.EeKIqCTBpL5TDz1YqEIA_a cVrLEdFphwms597WIGQpkXhVtq.nILV1GYA4En1VrQBD6a3ze9FoIB2l2_dp MSs.lpnR.t11fqg_stcSw0uKrxcpXQyysisxgp8C6q0IAVZAHrV2ujRuU5fc D9xKvpEghSaxlX_hFp25os4tiinkMVV57_KcV9MqDLDBRRQF0JnNYwV4D39P mSIScLQCxVgwnyY3JGGfzow1lTMB5jO6FxaCIUCOhp1QzwFmQ7bh_OqYwKJP 4bygdihlkNjsZpKEXcF.OJ.m8olOGwlULlPCW37.tZa.0Sdwepqv_lVsaKkP Z0UDdkau4_J3Gu1053cG3Rlck5ufF2lqWi1BmUHizHVmVHiygD3uo50XCsaM Lwa3O3sA_nm6GhGEIV5tn44dbSQGppK.DaXaB7DMtGrHnto_Uq59PehQu7Vu HPzkZJFNXR5WunEaOQHwSquVd7EA4YUZhW3EAUVUzZDUGH1L0P5oxqe65kik i2n5wa.gVWDJYHv_66frq5y3RXxkxu3benIdLVnq4YNT2uI1a2Nunmddl
Received: from [167.220.24.57] by web142804.mail.bf1.yahoo.com via HTTP; Mon, 08 Sep 2014 13:32:18 PDT
X-Rocket-MIMEInfo: 002.001, Q2hhbmdlZCB0byB5b3VyIHRleHQgb24gdGhlIGhvc3QvcG9ydCB0aGluZy4KClRoYW5rcyBhZ2FpbiEKCgpPbiBNb25kYXksIFNlcHRlbWJlciA4LCAyMDE0IDEwOjAwIEFNLCBCZW5qYW1pbiBLYWR1ayA8a2FkdWtATUlULkVEVT4gd3JvdGU6CiAKCgpPbiBGcmksIDUgU2VwIDIwMTQsIEJpbGwgTWlsbHMgd3JvdGU6Cgo.IE9uIEZyaWRheSwgU2VwdGVtYmVyIDUsIDIwMTQgMTA6MDUgQU0sIEJlbmphbWluIEthZHVrIDxrYWR1a0BNSVQuRURVPiB3cm90ZToKPgo.Cj4gSSBzZWUgdGhhdCB0aGUgbm90YXRpb24BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.203.696
References: <52AE9A65.1010700@oracle.com> <53F53D1F.7010305@oracle.com> <alpine.GSO.1.10.1409042219260.21571@multics.mit.edu> <1409962498.54315.YahooMailNeo@web142804.mail.bf1.yahoo.com> <alpine.GSO.1.10.1409081240310.21571@multics.mit.edu>
Message-ID: <1410208338.40585.YahooMailNeo@web142804.mail.bf1.yahoo.com>
Date: Mon, 08 Sep 2014 13:32:18 -0700
From: Bill Mills <wmills_92105@yahoo.com>
To: Benjamin Kaduk <kaduk@MIT.EDU>
In-Reply-To: <alpine.GSO.1.10.1409081240310.21571@multics.mit.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-2129327256-1876670983-1410208338=:40585"
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/xUn7-SmlX8IgN3w-vPjadEcwLos
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-15
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills <wmills_92105@yahoo.com>
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Sep 2014 20:32:22 -0000
Changed to your text on the host/port thing. Thanks again! On Monday, September 8, 2014 10:00 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote: On Fri, 5 Sep 2014, Bill Mills wrote: > On Friday, September 5, 2014 10:05 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote: > > > I see that the notation "%x01" is used throughout to indicate the octet > with value 0x01, and this is used without comment in RFC 7159 (the JSON > spec). I guess this is standard in ABNF-land, but section 2 doesn't > mention that we assume familiarity with such terminology. > > *** > [bill] that's actually HTTP (URI?) entity encoding. > *** So we think that familiarity with RFC 6749 (OAuth 2.0) implies an understanding of this usage? If so, that's fine by me. > In section 6, the example is given of "when SASL is used in the context of > IMAP the resource server may assert the resource owner's email address to > the IMAP server for usage in an email-based application.". But isn't the > IMAP server the resource server here? Maybe it is the authorization > server which is making this assertion? > > *** > [bill] it's the client asserting the email address, this now reads "in the > context of IMAP the client may assert the resource owner's email address". > *** Okay, thanks. > Also in 3.1, the sentence mandating that the server MUST fail requests > that do not have host and port values but use keyed message digests could > be made more clear. I'm uncertain which sort of requests do require keyed > message digests, so I don't really have any suggestions. > > *** > [bill] Changed to: "For OAuth token types such as OAuth 1.0a that use keyed > message digests" > *** That helps some. I think it was the text which is normative for the server's actions that left me unsatisfied, though. Seeing this now, I suggest "server MUST fail an authorization request requiring keyed message digests that is not accompanied by host and port values" (so, changing from "do not have" to "is not accompanied by"). This does slightly change the assumption of what blob of data is an "authorization request", i.e., is it the client response, or the value corresponding to the auth key. If it's the former, then my suggestion is probably not correct. > In 3.2.1, I would be more comfortable if the second paragraph gave me some > reason to think that doing so is possible. Is there prior art, or some > other specification for a similar thing that gives an example? We don't > need to enumerate every way it could be done, but it seems useful to give > an indication that this is not going to end up dropping a heraculean task > on the developer. > > *** > [bill] OAuth 1.0a tokens may well (and commonly have in some implementations) > either carried or has access to the client identity. > > For the question of whether both identities can be communicated to the app, it > would be a new capability you'd have to add to the SASL implementation you're > using. Not herculean, but not trivial if you're going to patch something like > Cyrus SASL and keep it in sync with current releases. > *** So, an extension to the SASL library's API? I'm not immediately coming up with a good way to include that in the text, so maybe we can leave it as-is. > Editorial minutiae: > > The first paragraph of page 4 has the sentence "The framework also > provides a protocol for security subsequent protocol exchanges within a > data security layer.", which uses the word 'protocol' twice with two > different usages. It is probably best to add a qualifier to at least one > occurrence. > > *** > [bill] IIRC this is lifted from the SASL spec itself. That said, deleting the > second usage seems to do the trick, " The framework also provides a protocol for > securing subsequent exchanges within a data security layer." > *** Yup, that seems to work well. > The end of section 1 notes that "In band discovery is not tenable if > clients support the OAuth 2.0 password grant." It would be nice to say > something about why. > > *** > [bill] Now there's a fun topic. There are folks that assert that allowing in > band discovery if the password grant is in play might lead to an effective > phishing attack. Other's disagree. No one hated the current language. I'm > really tempted to leave it alone. > *** Okay. I don't want to go from uncontroversial text to controversial text. > In section 3.1, replace "or may be empty" with "which may be empty". > > *** > [bill] no, because the empty client response containing only the 0x01 has no GS2 > header, now reads, "header followed by zero or more key/value pairs, or may be > empty." > *** Ah, I see now. Sorry for the confusion. -Ben
- [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 Shawn M Emery
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Matt Miller (mamille2)
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Matt Miller (mamille2)
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Matt Miller (mamille2)
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Ryan Troll
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Ryan Troll
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-s… Shawn M Emery
- Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hm… Benjamin Kaduk
- Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hm… Peck, Michael A
- Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hm… Benjamin Kaduk
- Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hm… Simon Josefsson
- Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hm… Benjamin Kaduk
- Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hm… Greg Hudson
- [kitten] WGLC on draft-ietf-krb-wg-cammac-08 Shawn M Emery
- Re: [kitten] WGLC on draft-ietf-krb-wg-cammac-08 Zheng, Kai
- Re: [kitten] WGLC on draft-ietf-krb-wg-cammac-08 Tom Yu
- Re: [kitten] WGLC on draft-ietf-krb-wg-cammac-08 Zheng, Kai
- [kitten] WGLC on draft-ietf-kitten-sasl-oauth-15 Shawn M Emery
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Benjamin Kaduk
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Benjamin Kaduk
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills