From nobody Tue Sep 2 10:13:26 2014 Return-Path: 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 BA68E1A0700; Tue, 2 Sep 2014 10:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 b9N9-bo68ov7; Tue, 2 Sep 2014 10:13:17 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609861A068E; Tue, 2 Sep 2014 10:13:11 -0700 (PDT) X-AuditID: 12074424-f79346d000004923-58-5405faa6046d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 29.23.18723.6AAF5045; Tue, 2 Sep 2014 13:13:10 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s82HD9Tk012808; Tue, 2 Sep 2014 13:13:09 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s82HD7T8016465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Sep 2014 13:13:08 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s82HD64C025044; Tue, 2 Sep 2014 13:13:06 -0400 (EDT) Date: Tue, 2 Sep 2014 13:13:06 -0400 (EDT) From: Benjamin Kaduk To: "Adamson, Andy" In-Reply-To: Message-ID: References: <20140730163006.GG26316@fieldses.org> <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-67061960-1409677986=:21571" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsUixCmqrLvsF2uIwZ2lIhZHN69isZj9/hGr xfRFVg7MHkuW/GTymPHpC1sAUxSXTUpqTmZZapG+XQJXxtoz/SwFx2UrLt9az9rAuE68i5GT Q0LAROJFxz5mCFtM4sK99WxdjFwcQgKzmST2L/7JBOFsYJTYufMeVOYgk8SmpQeAWjiAnHqJ NVtrQLpZBLQk/u9azgRiswmoSMx8s5ENpEREwEBi41JVkDCzgL1Ez65XbCC2sICFxMNpi8AW cwo4Sbxt/MoCYvMKOErs77zBDrFqJ5PE5udfGEESogI6Eqv3T4EqEpQ4OfMJC8RQf4lPk38w T2AUnIUkNQtJCsJWlzjw6SIjhK0tcf9mG9sCRpZVjLIpuVW6uYmZOcWpybrFyYl5ealFuuZ6 uZkleqkppZsYQQHO7qKyg7H5kNIhRgEORiUeXokfLCFCrIllxZW5hxglOZiURHnL3rGGCPEl 5adUZiQWZ8QXleakFh9ilOBgVhLhdf4KlONNSaysSi3Kh0lJc7AoifO+tbYKFhJITyxJzU5N LUgtgsnKcHAoSfBO+gnUKFiUmp5akZaZU4KQZuLgBBnOAzT8BEgNb3FBYm5xZjpE/hSjLse6 zm/9TEIsefl5qVLivBwgRQIgRRmleXBzYInpFaM40FvCvFdAqniASQ1u0iugJUxAS9xywJaU JCKkpBoYN6/rbqibvGBit+m3L0UNDdpuf9eFdG346uriK6wq/f/pc2azBwVJOkUijRFFvSXX nkd5/n+ZkiN5PXjxyi87pm1v6P64oPYl54treU4z9fbuaOUoVihjjPqkorxH/GSoRG7oGfY3 iT0fDBS+hYa4nvwTMEmTq+VecmLM//r/9bUdAm6XPfYosRRnJBpqMRcVJwIAJ7qPUicDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/yOMUt3jLHXbpcXrXyxinvzH-K8I Cc: "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 17:13:21 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-67061960-1409677986=:21571 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE It would be nice if someone could confirm or contradict my conclusion that the triple of (opaque inner handle, nonce, mic) is a bearer token for performing multi-principal authentication. -Ben On Wed, 20 Aug 2014, Benjamin Kaduk wrote: > I'm starting a new thread for this, since I think it is the most importan= t > item revealed by my review, but it seems to have been lost amidst the > other discussions. > > On Sun, 3 Aug 2014, Benjamin Kaduk wrote: > > > On Fri, 1 Aug 2014, Adamson, Andy wrote: > > > > > > > > I have always thought of Multi-principal authentication in terms of i= t=E2=80=99s use > > > in NFSv4.2 Inter server to server copy, where all of the RPCSEC_GSS_C= REATE > > > messages MUST use rpc_gss_svc_privacy=E2=80=99=E2=80=A6. Good catch B= ruce. > > > > > > So for this attack to occur the rgmp_nonce must be re-used by the sam= e > > > rgmp_handle (same user-principal). Insisting on using a random number > > > generator to create nounce could be by-passed by a bad implementation= =2E.. > > > > > > Bruces suggestion of using the new reply verifier data (rpc-header) s= hould > > > do the trick. Any objections to this approach? > > I don't think I correctly understand this proposal. Can someone try to > explain it in more detail, please? > > > If I understand correctly, the child RPCSEC contex handle will use the = same > > GSS context as the parent RPCSEC context handle (i.e., using the host's > > credentials, not the user's credentials). This means that when creatin= g the > > child RPCSEC context, there must be some proof that the RPC client cont= rols > > the GSS context corresponding to the inner RPCSEC context handle, since= the > > child RPCSEC context will perform operations acting as the user specifi= ed by > > the GSS context of the inner RPCSEC context. > > > > My reading of the current draft is that the only attempt to do this is = by > > presenting a random nonce and a GSS_GetMIC of that nonce, created using= the > > GSS context of the inner RPCSEC context. The server must verify that t= he MIC > > is a valid mic, but I do not see any other binding to this GSS context.= In > > particular, the nonce+MIC could be eavesdropped on the wire, and insert= ed into > > an attacker's RPCSEC_GSS_CREATE call, where the attacker provides its o= wn > > parent RPCSEC context but does not actually have an inner context at al= l. The > > attacker can reuse the valid nonce+MIC that it has intercepted, which w= ill > > validate correctly on the server, and the server will issue a child RPC= SEC > > context that acts as the user indicated by the GSS context of the inner= RPCSEC > > context but uses the key material from the attacker's GSS context. > > Basically, my reading is that the triple of (opaque inner handle, nonce, > mic) is a bearer token that is valid as long as the inner rpcsec context > is valid, as specified in the -08. The inner handle is only used to > lookup the GSS security context to use to verify the MIC of the nonce, so > if all three are passed together, there is no binding to anything else > that I can see. > > An attacker who gets a copy of this bearer token could then use it to > create its own child context from a parent context that the attacker > controls, and perform actions as the user corresponding to the GSS > security context of the inner context handle. > > -Ben ---559023410-67061960-1409677986=:21571-- From nobody Tue Sep 2 21:12:57 2014 Return-Path: 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 772D71A89D2; Tue, 2 Sep 2014 21:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 jTTcfIUvtsE4; Tue, 2 Sep 2014 21:12:43 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9C18A1A89C9; Tue, 2 Sep 2014 21:12:42 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id 7FCC720078710; Tue, 2 Sep 2014 21:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=juXnC3JNN1v5Gr i7wHyL5+Xf1X0=; b=VsZ1Iu+RfyeIHjl9H0QuKCAhXggsdRbaWhaPn9TyezfhZX DAYppZDpkqmE/40Mm5zxL0vkSudDxRj68VsPYCtt3PSM5eUgAyDVXU6/nPnFzvZr NL7YaVIRhgzMMUcKkBfq+7AtNnoWJAi7S+iTqoIl3tvbk3TardqbNY9e4+aIs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPA id 20CEE2007870F; Tue, 2 Sep 2014 21:12:42 -0700 (PDT) Date: Tue, 2 Sep 2014 23:12:41 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20140903041240.GG2664@localhost> References: <20140730163006.GG26316@fieldses.org> <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/EWJFYh442_KPheUApn8YOprHCP4 Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 04:12:44 -0000 On Tue, Sep 02, 2014 at 01:13:06PM -0400, Benjamin Kaduk wrote: > It would be nice if someone could confirm or contradict my conclusion that > the triple of (opaque inner handle, nonce, mic) is a bearer token for > performing multi-principal authentication. Sorry, let's look at this: - As I had it the client sends an integrity-protected message that contains a MIC of a nonce. The outer message is protected by a GSS security context authenticating the client host. The inner MIC is made with the user's context. Both contexts having the same acceptor. - The *new* RPCSEC_GSS security context uses the same GSS security context as the outer message in the establishment (see above) of this new context. - When the client sends an RPC on behalf of a user, then, it sends something like (simplifying): - RPC header: - program, procedure, XID - credential - *new* context ID - verifier - MIC taken over the header (minus verifier) with the old outer context - payload (possibly wrapped) There's no bearer token here. There's nothing in the credential or verifier that a man in the wire can use to replay against the server and get the same rights with a different payload (well, assuming we're providing at least integrity protection to the payload). The man in the wire would have to be able to manufacture a MIC and Wrap tokens without having the related security context's session keys. Could an attacker find a MIC made with a context authenticating the user (to the same acceptor) of a payload that looks like a nonce? Yes, perhaps, but the client would have to pick that same nonce, so, not really. OK, now let's see if the same is true for the current draft. [reads] This section of the draft got rewritten, but my reading is that the gist is the same. Nico -- From nobody Wed Sep 3 09:35:15 2014 Return-Path: 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 201591A0077; Wed, 3 Sep 2014 09:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.57 X-Spam-Level: X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, 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 ZZMV-QOeWZe8; Wed, 3 Sep 2014 09:35:09 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE4E1A0004; Wed, 3 Sep 2014 09:35:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,458,1406617200"; d="scan'208";a="186077895" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx12-out.netapp.com with ESMTP; 03 Sep 2014 09:35:07 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 3 Sep 2014 09:34:57 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com ([::1]) by hioexcmbx08-prd.hq.netapp.com ([fe80::3405:c28f:f61a:e768%21]) with mapi id 15.00.0913.011; Wed, 3 Sep 2014 09:34:45 -0700 From: "Adamson, Andy" To: Benjamin Kaduk Thread-Topic: rpcsec-gssv3 multi-principal authentication Thread-Index: AQHPvIu/oTjXtXsIRU6yu54YN8rMk5vunpMAgAGHnoA= Date: Wed, 3 Sep 2014 16:34:45 +0000 Message-ID: <7F59B011-C2A7-4222-80A9-5FDC49901145@netapp.com> References: <20140730163006.GG26316@fieldses.org> <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1874) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/kyrHzh3kThGb_GTX6WSKdL7OQDw Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 16:35:12 -0000 On Sep 2, 2014, at 1:13 PM, Benjamin Kaduk wrote: > It would be nice if someone could confirm or contradict my conclusion tha= t > the triple of (opaque inner handle, nonce, mic) is a bearer token for > performing multi-principal authentication. >=20 > -Ben Hi Ben=20 Vacation. Thanks for the review. Comments inline... >=20 > On Wed, 20 Aug 2014, Benjamin Kaduk wrote: >=20 >> I'm starting a new thread for this, since I think it is the most importa= nt >> item revealed by my review, but it seems to have been lost amidst the >> other discussions. >>=20 >> On Sun, 3 Aug 2014, Benjamin Kaduk wrote: >>=20 >>> On Fri, 1 Aug 2014, Adamson, Andy wrote: >>>=20 >>>>=20 >>>> I have always thought of Multi-principal authentication in terms of it= =92s use >>>> in NFSv4.2 Inter server to server copy, where all of the RPCSEC_GSS_CR= EATE >>>> messages MUST use rpc_gss_svc_privacy=92=85. Good catch Bruce. >>>>=20 >>>> So for this attack to occur the rgmp_nonce must be re-used by the same >>>> rgmp_handle (same user-principal). Insisting on using a random number >>>> generator to create nounce could be by-passed by a bad implementation.= .. >>>>=20 >>>> Bruces suggestion of using the new reply verifier data (rpc-header) sh= ould >>>> do the trick. Any objections to this approach? >>=20 >> I don't think I correctly understand this proposal. Can someone try to >> explain it in more detail, please? >>=20 >>> If I understand correctly, the child RPCSEC contex handle will use the = same >>> GSS context as the parent RPCSEC context handle (i.e., using the host's >>> credentials, not the user's credentials). This means that when creatin= g the >>> child RPCSEC context, there must be some proof that the RPC client cont= rols >>> the GSS context corresponding to the inner RPCSEC context handle, since= the >>> child RPCSEC context will perform operations acting as the user specifi= ed by >>> the GSS context of the inner RPCSEC context. >>>=20 >>> My reading of the current draft is that the only attempt to do this is = by >>> presenting a random nonce and a GSS_GetMIC of that nonce, created using= the >>> GSS context of the inner RPCSEC context. The server must verify that t= he MIC >>> is a valid mic, but I do not see any other binding to this GSS context.= In >>> particular, the nonce+MIC could be eavesdropped on the wire, and insert= ed into >>> an attacker's RPCSEC_GSS_CREATE call, where the attacker provides its o= wn >>> parent RPCSEC context draft-08 section 2.6.1.1. Multi-principal Authentication RPCSEC_GSSv3 clients MAY assert a multi-principal authentication of the client host principal and a user principal. This feature is needed, for example, when a client wishes to use authority assertions that the server may only grant if a user and a client are authenticated together to the server. Thus a server may refuse to grant requested authority to a user acting alone (e.g., via an unprivileged user-space program), or to a client acting alone (e.g. when a client is acting on behalf of a user) but may grant requested authority to a client acting on behalf of a user if the server identifies the user and trusts the client. It is assumed that an unprivileged user-space program would not have access to client host credentials needed to establish a GSS-API security context authenticating the client to the server, therefore an unprivileged user-space program could not create an RPCSEC_GSSv3 RPCSEC_GSS_CREATE message that successfully binds a client and a user security context. I believe the above last paragraph addresses this issue. Do we need to mak= e this section stronger, or perhaps clarify? Indeed, an attacker that has it=92s own parent RPCSEC context ( e.g. a prov= eable client machine-credential context ) can have her way. This is nothing new as an attacker with such a context has =91root=92 for t= hat machine in the RPCSEC world and can do a whole bunch of mischief :) That said, I suppose we could replace the nonce with the RPCSEC_GSS_CREATE = reply verifier data and prevent such an attacker from acting on behalf of a= user. =97>Andy >>> but does not actually have an inner context at all. The >>> attacker can reuse the valid nonce+MIC that it has intercepted, which w= ill >>> validate correctly on the server, and the server will issue a child RPC= SEC >>> context that acts as the user indicated by the GSS context of the inner= RPCSEC >>> context but uses the key material from the attacker's GSS context. >>=20 >> Basically, my reading is that the triple of (opaque inner handle, nonce, >> mic) is a bearer token that is valid as long as the inner rpcsec context >> is valid, as specified in the -08. The inner handle is only used to >> lookup the GSS security context to use to verify the MIC of the nonce, s= o >> if all three are passed together, there is no binding to anything else >> that I can see. >>=20 >> An attacker who gets a copy of this bearer token could then use it to >> create its own child context from a parent context that the attacker >> controls, and perform actions as the user corresponding to the GSS >> security context of the inner context handle. >>=20 >> -Ben From nobody Wed Sep 3 10:47:51 2014 Return-Path: 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 D7A751A0394; Wed, 3 Sep 2014 10:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 RX9ZdJfP2X0j; Wed, 3 Sep 2014 10:47:47 -0700 (PDT) Received: from fieldses.org (fieldses.org [174.143.236.118]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D34A1A0369; Wed, 3 Sep 2014 10:47:47 -0700 (PDT) Received: from bfields by fieldses.org with local (Exim 4.76) (envelope-from ) id 1XPEej-0006UD-VL; Wed, 03 Sep 2014 13:47:41 -0400 Date: Wed, 3 Sep 2014 13:47:41 -0400 To: Nico Williams Message-ID: <20140903174741.GA24790@fieldses.org> References: <20140730163006.GG26316@fieldses.org> <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> <20140903041240.GG2664@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140903041240.GG2664@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) From: "J. Bruce Fields" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/vYZLF30b8iSHVc_GOAvdHgX2Nss Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 17:47:49 -0000 On Tue, Sep 02, 2014 at 11:12:41PM -0500, Nico Williams wrote: > On Tue, Sep 02, 2014 at 01:13:06PM -0400, Benjamin Kaduk wrote: > > It would be nice if someone could confirm or contradict my conclusion that > > the triple of (opaque inner handle, nonce, mic) is a bearer token for > > performing multi-principal authentication. > > Sorry, let's look at this: > > - As I had it the client sends an integrity-protected message that > contains a MIC of a nonce. The outer message is protected by a GSS > security context authenticating the client host. The inner MIC is > made with the user's context. Both contexts having the same > acceptor. > > - The *new* RPCSEC_GSS security context uses the same GSS security > context as the outer message in the establishment (see above) of this > new context. > > - When the client sends an RPC on behalf of a user, then, it sends > something like (simplifying): > > - RPC header: > - program, procedure, XID > - credential > - *new* context ID > - verifier > - MIC taken over the header (minus verifier) with the old outer > context > - payload (possibly wrapped) > > There's no bearer token here. There's nothing in the credential or > verifier that a man in the wire can use to replay against the server and > get the same rights with a different payload (well, assuming we're > providing at least integrity protection to the payload). > > The man in the wire would have to be able to manufacture a MIC and Wrap > tokens without having the related security context's session keys. > > Could an attacker find a MIC made with a context authenticating the user > (to the same acceptor) of a payload that looks like a nonce? Yes, > perhaps, but the client would have to pick that same nonce, so, not > really. Sorry, I haven't been thinking about this, I'm probably confused, but I think I was imagining an attack something like: - I, a rogue client, sniff some random krb5 traffic from the user. - That traffic includes at least one (rpc header, mic of rpc header) pair. - I send a CREATE call using that rpc header as the nonce data. ? --b. > > OK, now let's see if the same is true for the current draft. [reads] > > This section of the draft got rewritten, but my reading is that the gist > is the same. > > Nico > -- > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www.ietf.org/mailman/listinfo/nfsv4 From nobody Wed Sep 3 11:32:52 2014 Return-Path: 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 569EE1A038C; Wed, 3 Sep 2014 11:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 w7WgYWINNxpz; Wed, 3 Sep 2014 11:32:48 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A83221A0366; Wed, 3 Sep 2014 11:32:48 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 4F2AE2007F026; Wed, 3 Sep 2014 11:32:48 -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=mjpDUO/xRB02RVK9c06Y qseOZQ8=; b=uaPhqaI0Z3Ww8qlbAEX0kjCGrvblk21TYbFWSSELp+JdKJKLUkCV m/8tMvUwfOJ/SbVRIilQ1bfs6cWSQ5xQ309NTr1YNJx0FwcoX9Q2IM9tYvNeA73p wRLQJv8IelykfzUJwQ2QrdSe5Z3+LhECvW4qreclDgaKZCFUKVBrsRg= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id C63462007F006; Wed, 3 Sep 2014 11:32:47 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id z2so10379835wiv.15 for ; Wed, 03 Sep 2014 11:32:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.123.1 with SMTP id lw1mr49848010wjb.4.1409769166493; Wed, 03 Sep 2014 11:32:46 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 11:32:46 -0700 (PDT) In-Reply-To: <20140903174741.GA24790@fieldses.org> References: <20140730163006.GG26316@fieldses.org> <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> <20140903041240.GG2664@localhost> <20140903174741.GA24790@fieldses.org> Date: Wed, 3 Sep 2014 13:32:46 -0500 Message-ID: From: Nico Williams To: "J. Bruce Fields" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/V3MZsCgd4Z_mMxMUzFr6JWLdenk Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 18:32:49 -0000 On Wed, Sep 3, 2014 at 12:47 PM, J. Bruce Fields wrote: > Sorry, I haven't been thinking about this, I'm probably confused, but I > think I was imagining an attack something like: > > - I, a rogue client, sniff some random krb5 traffic from the > user. > - That traffic includes at least one (rpc header, mic of rpc > header) pair. > - I send a CREATE call using that rpc header as the nonce data. > > ? It almost works, but remember, the server must have the security context to verify the MIC with, and that context will have to be tied to the same NFSv4 client ID (same session). Oh, but maybe some servers have a global RPCSEC_GSS context handle? If so, that would be a problem. In that case the server could pick the nonce. Or the MIC could be taken over more content (e.g., also a MIC made with the client context). Just in case, this would be a good change to make. Nico -- From nobody Wed Sep 3 12:29:04 2014 Return-Path: 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 5F7AD1A6F14; Wed, 3 Sep 2014 12:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 NsgYYcc2Ms-n; Wed, 3 Sep 2014 12:28:58 -0700 (PDT) Received: from fieldses.org (fieldses.org [174.143.236.118]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F231A6F01; Wed, 3 Sep 2014 12:28:58 -0700 (PDT) Received: from bfields by fieldses.org with local (Exim 4.76) (envelope-from ) id 1XPGEh-0006uw-S0; Wed, 03 Sep 2014 15:28:55 -0400 Date: Wed, 3 Sep 2014 15:28:55 -0400 From: "J. Bruce Fields" To: Nico Williams Message-ID: <20140903192855.GA25363@fieldses.org> References: <20140730163006.GG26316@fieldses.org> <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> <20140903041240.GG2664@localhost> <20140903174741.GA24790@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/bEdywVCFAjfvsuK2Jq6x2zQAjY4 Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:29:00 -0000 On Wed, Sep 03, 2014 at 01:32:46PM -0500, Nico Williams wrote: > On Wed, Sep 3, 2014 at 12:47 PM, J. Bruce Fields wrote: > > Sorry, I haven't been thinking about this, I'm probably confused, but I > > think I was imagining an attack something like: > > > > - I, a rogue client, sniff some random krb5 traffic from the > > user. > > - That traffic includes at least one (rpc header, mic of rpc > > header) pair. > > - I send a CREATE call using that rpc header as the nonce data. > > > > ? > > It almost works, but remember, the server must have the security > context to verify the MIC with, and that context will have to be tied > to the same NFSv4 client ID (same session). Argh, I'm totally confused. Which context (inner or outer) is "the security context" in the above? So the server will reject my attempt above because the inner context is associated with a different clientid than the outer context? I'm not even sure what it means for a gss context to be tied to a client ID. Maybe I'm just dense, but at a minimum I think this needs a much more careful explanation. > Oh, but maybe some servers have a global RPCSEC_GSS context handle? > If so, that would be a problem. In that case the server could pick > the nonce. Or the MIC could be taken over more content (e.g., also a > MIC made with the client context). Just in case, this would be a good > change to make. Fundamentally the (nonce, mic) pair here looks meaningless. The network is presumably already full of (data, mic(data)) pairs using this context, what does it prove that you can supply me with one when you get to choose the data? --b. From nobody Wed Sep 3 12:35:02 2014 Return-Path: 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 EB5B31A6F49; Wed, 3 Sep 2014 12:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 Wbyg-Z8UkuxE; Wed, 3 Sep 2014 12:34:56 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104751A0B84; Wed, 3 Sep 2014 12:34:55 -0700 (PDT) X-AuditID: 1209190d-f79c06d000006f95-c1-54076d5e4903 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 3E.03.28565.E5D67045; Wed, 3 Sep 2014 15:34:54 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s83JYrN3032560; Wed, 3 Sep 2014 15:34:54 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s83JYmY0002845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Sep 2014 15:34:51 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s83JYmhV016650; Wed, 3 Sep 2014 15:34:48 -0400 (EDT) Date: Wed, 3 Sep 2014 15:34:48 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20140903041240.GG2664@localhost> Message-ID: References: <20140730163006.GG26316@fieldses.org> <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> <20140903041240.GG2664@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42IR4hRV1o3LZQ8x+PRQx+Lo5lUsFrPfP2K1 OHXtCJvF9EVWDiweL0+dY/RYsuQnk8eMT1/YApijuGxSUnMyy1KL9O0SuDImXuItaJaouPL2 NmsD4wahLkZODgkBE4nFx6ezQthiEhfurWfrYuTiEBKYzSRx4tQsRghnA6PExVl/WSGcg0wS O/vPsYC0CAnUSyxZdJIRxGYR0JK4fP8BG4jNJqAiMfPNRjBbREBT4vq8pWA2s0CZRPe0drB1 wgIOEgsW3wbr5RTQk5g+/QZQDQcHr4CjxIzfzhC7JjJLrD13EaxGVEBHYvX+KWB7eQUEJU7O fMICMVNLYvn0bSwTGAVnIUnNQpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdILzezRC81 pXQTIziIJXl3ML47qHSIUYCDUYmH18OPLUSINbGsuDL3EKMkB5OSKG9oOnuIEF9SfkplRmJx RnxRaU5q8SFGCQ5mJRHeNdJAOd6UxMqq1KJ8mJQ0B4uSOO9ba6tgIYH0xJLU7NTUgtQimKwM B4eSBK92DlCjYFFqempFWmZOCUKaiYMTZDgP0HBdkBre4oLE3OLMdIj8KUZdjnWd3/qZhFjy 8vNSpcR5e7OBigRAijJK8+DmwJLPK0ZxoLeEebeDVPEAExfcpFdAS5iAlrjlsIIsKUlESEk1 MDJ9kxNzvTLz4Ta5guovE9haJsQsOh/ydGVex+HVURdemSyV+hR9lrfz3fOV8WXsJgGmLTMM Gy8UR9gdet/I+DB20aMHN/5cf7vrXqPXtb0uof5s6oG7bSRsXhSZZGw8G+ujcHL13pU/2J19 vXLfZHy4sm7pvYo1flMVPtbXPV8ivfdYUn763w9KLMUZiYZazEXFiQCy4/X1GQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/a132Sqa23UE3kR-Z8DBuTU4bE-c Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:34:59 -0000 On Wed, 3 Sep 2014, Nico Williams wrote: > On Tue, Sep 02, 2014 at 01:13:06PM -0400, Benjamin Kaduk wrote: > > It would be nice if someone could confirm or contradict my conclusion that > > the triple of (opaque inner handle, nonce, mic) is a bearer token for > > performing multi-principal authentication. > > Sorry, let's look at this: > > - As I had it the client sends an integrity-protected message that > contains a MIC of a nonce. The outer message is protected by a GSS > security context authenticating the client host. The inner MIC is > made with the user's context. Both contexts having the same > acceptor. Check. The inner mic is an ordinary GSS_GetMic(), correct? > - The *new* RPCSEC_GSS security context uses the same GSS security > context as the outer message in the establishment (see above) of this > new context. Check. > - When the client sends an RPC on behalf of a user, then, it sends > something like (simplifying): > > - RPC header: > - program, procedure, XID > - credential > - *new* context ID This part is, I think, the problem. > - verifier > - MIC taken over the header (minus verifier) with the old outer > context (I don't think 'old' is needed here; it's just the outer GSS context.) > - payload (possibly wrapped) > > There's no bearer token here. There's nothing in the credential or > verifier that a man in the wire can use to replay against the server and > get the same rights with a different payload (well, assuming we're > providing at least integrity protection to the payload). I don't think that there's a bearer token used to authenticate RPCs on behalf of a user. I think that the process of obtaining a new/child context ID involves a bearer token that identifies the user which will be associated with the child context. The message to obtain the child context ID is integrity protected, but if I have my own credentials to make my own parent context, and I can read the contents of the RPCSEC_GSS_CREATE request, I can make my own RPCSEC_GSS_CREATE request that contains the handle ID, nonce, and mic that I observed over the wire. So, I guess the question becomes, does the server do anything to verify that the inner handle ID is associated with the connection/peer that the server is currently talking to. > The man in the wire would have to be able to manufacture a MIC and Wrap > tokens without having the related security context's session keys. > > Could an attacker find a MIC made with a context authenticating the user > (to the same acceptor) of a payload that looks like a nonce? Yes, > perhaps, but the client would have to pick that same nonce, so, not > really. If the attacker has their own (rpcsec) client, they can choose whatever nonce they want. -Ben > OK, now let's see if the same is true for the current draft. [reads] > > This section of the draft got rewritten, but my reading is that the gist > is the same. From nobody Wed Sep 3 12:39:36 2014 Return-Path: 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 10A9F1A6EDC; Wed, 3 Sep 2014 12:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 6yHLLWVOK7o6; Wed, 3 Sep 2014 12:39:31 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9D61A0B09; Wed, 3 Sep 2014 12:39:31 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id EA6A920047B8B; Wed, 3 Sep 2014 12:39: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=0JbfBKbJFR+aTdepX2w5 jDI1grI=; b=DRly/Aa9vqT/ZZYJUGolfkPuceHG1mAiYYm9HPVKelLYJLEfhXda GvOB8+iKcnEBkNB2cKOzpqutjzGsIrVhlmObdY3jSom7cRoiqih1EIaMCZHeRceG Lptt/zi1E//w151IzKQOZytB1xHFUL9joKDw/pGQ0pZP3RYj97RE3WI= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id 6EDB920047B88; Wed, 3 Sep 2014 12:39:30 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id u56so9200067wes.2 for ; Wed, 03 Sep 2014 12:39:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.58.244 with SMTP id u20mr50230302wjq.36.1409773169110; Wed, 03 Sep 2014 12:39:29 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 12:39:29 -0700 (PDT) In-Reply-To: <20140903192855.GA25363@fieldses.org> References: <20140730163006.GG26316@fieldses.org> <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> <20140903041240.GG2664@localhost> <20140903174741.GA24790@fieldses.org> <20140903192855.GA25363@fieldses.org> Date: Wed, 3 Sep 2014 14:39:29 -0500 Message-ID: From: Nico Williams To: "J. Bruce Fields" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/qsaDquuA_IYZR2u9Dk0zNfI-jek Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:39:32 -0000 On Wed, Sep 3, 2014 at 2:28 PM, J. Bruce Fields wrote: > On Wed, Sep 03, 2014 at 01:32:46PM -0500, Nico Williams wrote: >> On Wed, Sep 3, 2014 at 12:47 PM, J. Bruce Fields wrote: >> > Sorry, I haven't been thinking about this, I'm probably confused, but I >> > think I was imagining an attack something like: >> > >> > - I, a rogue client, sniff some random krb5 traffic from the >> > user. >> > - That traffic includes at least one (rpc header, mic of rpc >> > header) pair. >> > - I send a CREATE call using that rpc header as the nonce data. >> > >> > ? >> >> It almost works, but remember, the server must have the security >> context to verify the MIC with, and that context will have to be tied >> to the same NFSv4 client ID (same session). > > Argh, I'm totally confused. > > Which context (inner or outer) is "the security context" in the above? Inner. The one authenticating the user. > So the server will reject my attempt above because the inner context is > associated with a different clientid than the outer context? Yes: because the inner security context is not known in ... this context (English sense of the word). > I'm not even sure what it means for a gss context to be tied to a client > ID. To a session, connection, ... Maybe I assumed too much about that? I'd have to go look at Illumos source to see if maybe I was led astray by that. It's been a while. > Maybe I'm just dense, but at a minimum I think this needs a much more > careful explanation. I agree. >> Oh, but maybe some servers have a global RPCSEC_GSS context handle? >> If so, that would be a problem. In that case the server could pick >> the nonce. Or the MIC could be taken over more content (e.g., also a >> MIC made with the client context). Just in case, this would be a good >> change to make. > > Fundamentally the (nonce, mic) pair here looks meaningless. The network > is presumably already full of (data, mic(data)) pairs using this > context, what does it prove that you can supply me with one when you get > to choose the data? There should be a bit more structure to it to prevent aliasing, and the server could be the source of the nonce (adding a round-trip) or we could add more to the message to be MICed (e.g., the client ID). Nico -- From nobody Wed Sep 3 12:49:36 2014 Return-Path: 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 109221A6F9E; Wed, 3 Sep 2014 12:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 3EkmMWm40qND; Wed, 3 Sep 2014 12:49:23 -0700 (PDT) Received: from fieldses.org (fieldses.org [174.143.236.118]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10C91A6F92; Wed, 3 Sep 2014 12:49:09 -0700 (PDT) Received: from bfields by fieldses.org with local (Exim 4.76) (envelope-from ) id 1XPGYD-00070J-HA; Wed, 03 Sep 2014 15:49:05 -0400 Date: Wed, 3 Sep 2014 15:49:05 -0400 From: "J. Bruce Fields" To: Nico Williams Message-ID: <20140903194905.GB25363@fieldses.org> References: <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> <20140903041240.GG2664@localhost> <20140903174741.GA24790@fieldses.org> <20140903192855.GA25363@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/EZ-6GkD4wzvYe0baonMmgPL69bo Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:49:25 -0000 On Wed, Sep 03, 2014 at 02:39:29PM -0500, Nico Williams wrote: > On Wed, Sep 3, 2014 at 2:28 PM, J. Bruce Fields wrote: > > On Wed, Sep 03, 2014 at 01:32:46PM -0500, Nico Williams wrote: > >> On Wed, Sep 3, 2014 at 12:47 PM, J. Bruce Fields wrote: > >> > Sorry, I haven't been thinking about this, I'm probably confused, but I > >> > think I was imagining an attack something like: > >> > > >> > - I, a rogue client, sniff some random krb5 traffic from the > >> > user. > >> > - That traffic includes at least one (rpc header, mic of rpc > >> > header) pair. > >> > - I send a CREATE call using that rpc header as the nonce data. > >> > > >> > ? > >> > >> It almost works, but remember, the server must have the security > >> context to verify the MIC with, and that context will have to be tied > >> to the same NFSv4 client ID (same session). > > > > Argh, I'm totally confused. > > > > Which context (inner or outer) is "the security context" in the above? > > Inner. The one authenticating the user. > > > So the server will reject my attempt above because the inner context is > > associated with a different clientid than the outer context? > > Yes: because the inner security context is not known in ... this > context (English sense of the word). > > > I'm not even sure what it means for a gss context to be tied to a client > > ID. > > To a session, connection, ... Maybe I assumed too much about that? > I'd have to go look at Illumos source to see if maybe I was led astray > by that. It's been a while. A gss context is created by an INIT_SEC_CONTEXT call before it's ever used with any particular NFS client (do we even know it's necessarily going to be used for NFS at that point?). Then it may be used for some NFS RPC call, which may or may not be associated with a client id. So I guess you'd want the rules to be that a gss context is either tied to a client id or not, that the first RPC call referring to some clientid or sessionid ties the context to a client, at which point it's forbidden from being associated to any other client, and that only contexts tied to client id's can be used in CREATE calls? This all seems a little ad-hoc. And it mixes up the RPC and NFS layers in ways I'm not sure I understand. > > Maybe I'm just dense, but at a minimum I think this needs a much more > > careful explanation. > > I agree. > > >> Oh, but maybe some servers have a global RPCSEC_GSS context handle? > >> If so, that would be a problem. In that case the server could pick > >> the nonce. Or the MIC could be taken over more content (e.g., also a > >> MIC made with the client context). Just in case, this would be a good > >> change to make. > > > > Fundamentally the (nonce, mic) pair here looks meaningless. The network > > is presumably already full of (data, mic(data)) pairs using this > > context, what does it prove that you can supply me with one when you get > > to choose the data? > > There should be a bit more structure to it to prevent aliasing, and > the server could be the source of the nonce (adding a round-trip) or > we could add more to the message to be MICed (e.g., the client ID). Sounds like there's work to do. --b. From nobody Wed Sep 3 13:52:53 2014 Return-Path: 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 1F3C61A6FD4; Wed, 3 Sep 2014 13:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 s6RdKV-hvGEv; Wed, 3 Sep 2014 13:52:46 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978B01A06E0; Wed, 3 Sep 2014 13:51:57 -0700 (PDT) X-AuditID: 12074424-f79346d000004923-87-54077f6bd381 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 49.D9.18723.B6F77045; Wed, 3 Sep 2014 16:51:55 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s83Kpsdb004731; Wed, 3 Sep 2014 16:51:55 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s83Kpq0O001912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Sep 2014 16:51:54 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s83Kpqme026440; Wed, 3 Sep 2014 16:51:52 -0400 (EDT) Date: Wed, 3 Sep 2014 16:51:51 -0400 (EDT) From: Benjamin Kaduk To: "Adamson, Andy" In-Reply-To: <7F59B011-C2A7-4222-80A9-5FDC49901145@netapp.com> Message-ID: References: <20140730163006.GG26316@fieldses.org> <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> <7F59B011-C2A7-4222-80A9-5FDC49901145@netapp.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-102982122-1409777512=:21571" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsUixG6nrptdzx5i0PNS3eLo5lUsFrPfP2K1 mL7IyoHZY8mSn0weMz59YQtgiuKySUnNySxLLdK3S+DKmLs2omCKTMWkWU/ZGxi3inUxcnJI CJhIHOl5yAZhi0lcuLceyObiEBKYzSSxZMIUZpCEkMAGRomJfUUQiYNMEm/mfWOHSNRLfH63 BKybRUBLov/DfBYQm01ARaKh+zJQMweHiICBxMalqiBhZgF7iZ5dr8DKhQUsJB5OWwQ2n1PA TuLd37dgI3kFHCUu7/nEDLFrIbPEj+kXWEESogI6Eqv3T2GBKBKUODnzCQvE0ACJCd8nM09g FJyFJDULSQrC1pO4NbsTytaWuH+zjW0BI8sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXXO93MwS vdSU0k2M4PB2UdnB2HxI6RCjAAejEg+vhx9biBBrYllxZe4hRkkOJiVR3qZa9hAhvqT8lMqM xOKM+KLSnNTiQ4wSHMxKIrw1IDnelMTKqtSifJiUNAeLkjjvW2urYCGB9MSS1OzU1ILUIpis DAeHkgSvYx1Qo2BRanpqRVpmTglCmomDE2Q4D9BwsBre4oLE3OLMdIj8KUZdjnWd3/qZhFjy 8vNSpcR5hUGKBECKMkrz4ObA0tIrRnGgt4R57UCqeIApDW7SK6AlTEBL3HJYQZaUJCKkpBoY J5g9ZIp2N/3Bc+L7s+brZZN/2Bqm7yrdlGfeL2Fvy1xwcekEy93lBb7mi/5vKsvKD9kpdoTl 0QVG/cNPK/xDwiOWTin/+XXR7QlLYnVUr53ivloedTJAwtLthk3vvtNek4Lvrpzzsa6qWotB geuEfWvQmw3zORk/xR9cfu6Vd0HbyxR2TyVJJZbijERDLeai4kQAnXoxLyYDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ZhHk-y45v71epjEMW-rhtaZZUog Cc: "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 20:52:48 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-102982122-1409777512=:21571 Content-Type: TEXT/PLAIN; charset=Windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 3 Sep 2014, Adamson, Andy wrote: > > On Sep 2, 2014, at 1:13 PM, Benjamin Kaduk wrote: > > Hi Ben > > Vacation. Thanks for the review. Comments inline... Ah, understood. Hope it was relaxing :) > > draft-08 section 2.6.1.1. Multi-principal Authentication > > RPCSEC_GSSv3 clients MAY assert a multi-principal authentication of > the client host principal and a user principal. This feature is > needed, for example, when a client wishes to use authority assertions > that the server may only grant if a user and a client are > authenticated together to the server. Thus a server may refuse to > grant requested authority to a user acting alone (e.g., via an > unprivileged user-space program), or to a client acting alone (e.g. > when a client is acting on behalf of a user) but may grant requested > authority to a client acting on behalf of a user if the server > identifies the user and trusts the client. > > It is assumed that an unprivileged user-space program would not have > access to client host credentials needed to establish a GSS-API > security context authenticating the client to the server, therefore > an unprivileged user-space program could not create an RPCSEC_GSSv3 > RPCSEC_GSS_CREATE message that successfully binds a client and a user > security context. > > I believe the above last paragraph addresses this issue. Do we need to > make this section stronger, or perhaps clarify? > > Indeed, an attacker that has it=92s own parent RPCSEC context ( e.g. a > proveable client machine-credential context ) can have her way. > > This is nothing new as an attacker with such a context has =91root=92 for > that machine in the RPCSEC world and can do a whole bunch of mischief :) I'm not considering the same machine; I'm thinking about a different machine. Maybe I can be more clear with an explicit example using NFS, instead of talking about rpcsec-gss in the abstract. Alice is a mortal user on machine A, and machine A runs an NFS client. Machine A has its secure host-specific credentials (nfs/A@REALM or host/A@REALM or whatever), and Alice has credentials for alice@REALM. Eve doesn't even have an account on machine A, but has root on machine B, which also has host-specific credentials (host/B@REALM), and Eve can spy on the NFS traffic between A and the NFS server (call it S). A's NFS client has to do an RPCSEC_GSS_CREATE RPC to be able to act as Alice. My claim is that Eve can see the network traffic from that RPC (just the request; the reply should not be needed), and use an evil NFS client on her machine B, to make her own RPCSEC_GSS_CREATE request, that contains the same rca_mp_auth field as the RPC from A, and with the result of that RPC, Eve's NFS client has an rpcsec-gss context handle that lets Eve read and write files as alice@REALM. > That said, I suppose we could replace the nonce with the > RPCSEC_GSS_CREATE reply verifier data and prevent such an attacker from > acting on behalf of a user. Hmm, if the verifier is signed using the outer context's GSS context, that might be enough to produce the required binding. I would need to think about it more. -Ben ---559023410-102982122-1409777512=:21571-- From nobody Wed Sep 3 13:54:46 2014 Return-Path: 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 4CD061A069C; Wed, 3 Sep 2014 13:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 dAiQb9ZHBC1d; Wed, 3 Sep 2014 13:54:42 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060BF1A700B; Wed, 3 Sep 2014 13:54:21 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-e7-54077ffcc117 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id E7.6F.13180.CFF77045; Wed, 3 Sep 2014 16:54:20 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s83KsKSS005063; Wed, 3 Sep 2014 16:54:20 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s83KsINu003124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Sep 2014 16:54:19 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s83KsHVc026770; Wed, 3 Sep 2014 16:54:17 -0400 (EDT) Date: Wed, 3 Sep 2014 16:54:17 -0400 (EDT) From: Benjamin Kaduk To: "J. Bruce Fields" In-Reply-To: <20140903194905.GB25363@fieldses.org> Message-ID: References: <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> <20140903041240.GG2664@localhost> <20140903174741.GA24790@fieldses.org> <20140903192855.GA25363@fieldses.org> <20140903194905.GB25363@fieldses.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixG6nrvunnj3E4PxkY4sXU6Isjm5exWIx +/0jVgdmjw1Tm9g8liz5yRTAFMVlk5Kak1mWWqRvl8CVceHHHMaCVRwVD7Z/YGpg3MbWxcjJ ISFgItF5dieULSZx4d56IJuLQ0hgNpPE4u2nmSCcDYwSi2YshMocZJKY++QTK0iLkEC9xKX3 f5hAbBYBLYlzszcwgthsAioSM99sBBsrIqAjseHzO7AaZgF7iZ5dr8DiwgKeEhdOvmQHsTkF jCT2TnwC1ssr4Cix5sNCZohl21kkFp5+CLZMFGjQ6v1TWCCKBCVOznzCAjFUS2L59G0sExgF ZyFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXTC83s0QvNaV0EyM4aF2UdzD+Oah0 iFGAg1GJh3dBAFuIEGtiWXFl7iFGSQ4mJVHetXXsIUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVE eGtqgXK8KYmVValF+TApaQ4WJXHet9ZWwUIC6YklqdmpqQWpRTBZGQ4OJQnebSBDBYtS01Mr 0jJzShDSTBycIMN5gIZXgtTwFhck5hZnpkPkTzHqcqzr/NbPJMSSl5+XKiXOKwxSJABSlFGa BzcHlmxeMYoDvSXMux2kigeYqOAmvQJawgS0xC2HFWRJSSJCSqqBsdk34GjUgnbjhXPPW/+f c+bUBS2ef3fXKr1l/6sn9H2BlMxi9dDZGvNPJbl/Urj41qaAWX9dzg7TDZ6/9s6ykF5m8HS7 G6+i+yrN+AgB0ao35hrcb8WydeJyUt77Ji/jOiC+9dv8Q/MENKqzLYwsfR5rhCs1zFxlqjlB f5tjfn3ZfP2M3pgSJZbijERDLeai4kQA9BKJdxEDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/nZi8nieCHjsCNeY1id4b-_cXV_4 Cc: "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 20:54:44 -0000 On Wed, 3 Sep 2014, J. Bruce Fields wrote: > On Wed, Sep 03, 2014 at 02:39:29PM -0500, Nico Williams wrote: > > On Wed, Sep 3, 2014 at 2:28 PM, J. Bruce Fields wrote: > > So I guess you'd want the rules to be that a gss context is either tied > to a client id or not, that the first RPC call referring to some > clientid or sessionid ties the context to a client, at which point it's > forbidden from being associated to any other client, and that only > contexts tied to client id's can be used in CREATE calls? > > This all seems a little ad-hoc. And it mixes up the RPC and NFS layers > in ways I'm not sure I understand. I agree; it doesn't feel like a good path forward (but I do believe it would solve the problems we are worried about). > > There should be a bit more structure to it to prevent aliasing, and > > the server could be the source of the nonce (adding a round-trip) or > > we could add more to the message to be MICed (e.g., the client ID). > > Sounds like there's work to do. I agree. -Ben From nobody Wed Sep 3 14:23:16 2014 Return-Path: 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 4CF9C1A871C; Wed, 3 Sep 2014 14:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 csjdSJfU4zvB; Wed, 3 Sep 2014 14:23:14 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D61901A6FCA; Wed, 3 Sep 2014 14:17:32 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 9B8EC1638; Wed, 3 Sep 2014 14:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=hOWJJ9NjH/OLFbIw9bVX ri+wHMc=; b=CaoHsgZB5s9UQdVczEJQ2ewTvHPm7b1U7MXZIuiy38EQk05YQC0K MMRTpQqPjfh7vC8BIoKfYgZOuMR+aPQttoCL3ttgmMBb1Id2AgaMQ/1kHUYxUSXk tZV0dY2UVbnKfJ45l2NF1XwNY1eAKtSN9n0ApJQoAN8whGMWBKV8pb4= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 18826161A; Wed, 3 Sep 2014 14:17:31 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id w62so9323641wes.27 for ; Wed, 03 Sep 2014 14:17:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.75.17 with SMTP id y17mr119924wiv.3.1409779050691; Wed, 03 Sep 2014 14:17:30 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 14:17:30 -0700 (PDT) In-Reply-To: References: <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> <20140903041240.GG2664@localhost> <20140903174741.GA24790@fieldses.org> <20140903192855.GA25363@fieldses.org> <20140903194905.GB25363@fieldses.org> Date: Wed, 3 Sep 2014 16:17:30 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/I47U7bZ_ptTjM6Rc46IVGTG6J_w Cc: "J. Bruce Fields" , "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 21:23:15 -0000 On Wed, Sep 3, 2014 at 3:54 PM, Benjamin Kaduk wrote: > On Wed, 3 Sep 2014, J. Bruce Fields wrote: >> Sounds like there's work to do. > > I agree. I agree. I wrote this eons ago and never got to implement. Multi-principal authentication is critical for security on multi-user clients. We should get it right. Nico -- From nobody Wed Sep 3 14:38:15 2014 Return-Path: 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 9AADD1A06AD for ; Wed, 3 Sep 2014 14:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no 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 wuk7enT4eX-u for ; Wed, 3 Sep 2014 14:38:12 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60FD41A6FBE for ; Wed, 3 Sep 2014 14:36:52 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id lx4so10557821iec.18 for ; Wed, 03 Sep 2014 14:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A+HMRy6kgI1D2R2EC1rHQ5jD+s7ND+flKtGeARJdlrc=; b=hEK1HwwoduKpPOdhdKhkBXh39dQXvl3OaSiZAkw23Q181kYXzBfdQRXyugZufRbkgZ NEVvOg7WMJdMRBKEa994jWKFer9WeIdM8au26vIs35as3sXDJ5S+b9y+Xr75pvVONb3O SJBmKmivsJJ6y9hbfKKM1mIYF3gYVtlj6uTBrz8v452utMBxmWLcNAnKaNzBtQCKHiBO R7S1BNTeNK73ZawYEAyojDHrhPQ9XZ38n9UwcaCj0sC5bgznQgoRXgNP4FNxk8KSgwi1 OL0dKOA1wInGh63lQDLfjl1uEN0fkWnoa8oSG/MmWcwC3uPflGm0PnJ5it7jsVs0Mfpg Th7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=A+HMRy6kgI1D2R2EC1rHQ5jD+s7ND+flKtGeARJdlrc=; b=e4IrZmm3oGn6pOjYsG9QnWHUGsbRrYa2dPo82m2O5baMRv7KxVKHjvAxQELU3OrxKd TNesUcLuQAMHaJVMKeUvcpiefA25e9dZdcjV5xd1mSzBNykWKsEn9xZuXKP4pL2TqbVX aSWBCX80CJ7ClERc2xxwr3K3Lukz7UnEdQCp7bPZIsv1KGr/xO81fT7wCnO3X55503X2 3Pa53qGgRnaxSfcvSsKxP5Ncjvylc2bf46/ygeEbQdmTWXJrL3iTXBmOCjSpfu3xm05V pSaylX5fmzkfOmCEcRxRrpo9HOYpdqJFg7q4NbNIVWuLZrD5ISotuqVw1M9jlTfsbr81 AWaQ== X-Gm-Message-State: ALoCoQkx/kkL8XtMS5KdvplFtP9PBfP+JsKYpRrK9egFK7/EOQKmFxjGpE/E4AM2MgjAww4gMn8V X-Received: by 10.50.43.193 with SMTP id y1mr258625igl.32.1409780211698; Wed, 03 Sep 2014 14:36:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.62.78 with HTTP; Wed, 3 Sep 2014 14:36:21 -0700 (PDT) In-Reply-To: <1407443152.85652.YahooMailNeo@web142802.mail.bf1.yahoo.com> References: <1407443152.85652.YahooMailNeo@web142802.mail.bf1.yahoo.com> From: =?UTF-8?B?SmFtaWUgTmljb2xzb24gKOWAquW/l+aYjik=?= Date: Wed, 3 Sep 2014 14:36:21 -0700 Message-ID: To: Bill Mills Content-Type: multipart/alternative; boundary=089e0111d1bebaeea505023008fe Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/FL30ANtuK3LUetXzLGa0WbVj6do Cc: "kitten@ietf.org" Subject: Re: [kitten] next steps on oauth sasl draft? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 21:38:13 -0000 --089e0111d1bebaeea505023008fe Content-Type: text/plain; charset=UTF-8 Hope this isn't too late: Section 3.2.2 describes the "status" portion of the error response as being an error code from the OAuth Extensions Error Registry. That registry lists codes like "invalid_request", "invalid_token", etc. However, in section 4.3, there is an example of an error response that has "status":"401". I don't see any way of mapping between the OAuth string error codes and numeric, http-style codes like 401. Am I missing something or is this a typo? On Thu, Aug 7, 2014 at 1:25 PM, Bill Mills wrote: > The OAuth SASL draft was in WGLC, but we made significant changes. We've > had one brief review of it since -15, that doesn't seem like enough to say > it might be close to WGLC eligible again. I'd especially like it if one or > more of the folks at Google could take a look as they're the major > implementor so far. > > Hoping to wrap this up. > > Thanks, > > -bill > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > --089e0111d1bebaeea505023008fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hope this isn't too late:

Section 3= .2.2 describes the "status" portion of the error response as bein= g an error code from the OAuth Extensions Error Registry. That registry lis= ts codes like "invalid_request", "invalid_token", etc. = However, in section 4.3, there is an example of an error response that has = "status":"401". I don't see any way of mapping betw= een the OAuth string error codes and numeric, http-style codes like 401. Am= I missing something or is this a typo?


On Thu, Aug 7, 2014 at 1:25 PM, Bill = Mills <wmills_92105@yahoo.com> wrote:
The OAuth SASL draft was in WGLC, but we made signifi= cant changes. =C2=A0We've had one brief review of it since -15, that do= esn't seem like enough to say it might be close to WGLC eligible again.= =C2=A0I'd especially like it if one or more of the folks at Google cou= ld take a look as they're the major implementor so far.

<= /div>
Hoping t= o wrap this up.

Thanks,


--089e0111d1bebaeea505023008fe-- From nobody Thu Sep 4 04:58:07 2014 Return-Path: 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 8CF691A875A; Thu, 4 Sep 2014 04:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.57 X-Spam-Level: X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, 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 QhWP5EkThRdI; Thu, 4 Sep 2014 04:58:00 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C67C1A0AF2; Thu, 4 Sep 2014 04:58:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,465,1406617200"; d="scan'208";a="144252377" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx11-out.netapp.com with ESMTP; 04 Sep 2014 04:57:49 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 4 Sep 2014 04:57:44 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com ([::1]) by hioexcmbx08-prd.hq.netapp.com ([fe80::3405:c28f:f61a:e768%21]) with mapi id 15.00.0913.011; Thu, 4 Sep 2014 04:57:43 -0700 From: "Adamson, Andy" To: Nico Williams Thread-Topic: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication Thread-Index: AQHPvIu/oTjXtXsIRU6yu54YN8rMk5vunpMAgAC4SYCAAOO2gIAADJgAgAAPsICAAAL0gIAAAq+AgAASN4CAAAZ9AIAA9fQA Date: Thu, 4 Sep 2014 11:57:43 +0000 Message-ID: References: <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> <20140903041240.GG2664@localhost> <20140903174741.GA24790@fieldses.org> <20140903192855.GA25363@fieldses.org> <20140903194905.GB25363@fieldses.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1874) x-originating-ip: [10.120.60.34] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4A5358F60BCE3A4F9C37AB7E31B3519A@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/knx5sDu0ol0wtgZQ4rn_09nkfho Cc: "J. Bruce Fields" , "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 11:58:01 -0000 On Sep 3, 2014, at 5:17 PM, Nico Williams wrote: > On Wed, Sep 3, 2014 at 3:54 PM, Benjamin Kaduk wrote: >> On Wed, 3 Sep 2014, J. Bruce Fields wrote: >>> Sounds like there's work to do. >>=20 >> I agree. >=20 > I agree. I wrote this eons ago and never got to implement. >=20 > Multi-principal authentication is critical for security on multi-user > clients. We should get it right. Yes. But! If we add more structure to prevent aliasing - e.g. attach it to = a client machine (or clientid) then it will prevent it=92s use in NFSv4.2 I= nter server to server copy where the user principal on one client machine i= s permitting another client (the destination server acting as a client) to = act on it=92s behalf. I say we keep the current nonce and simply insist on privacy. This will pre= vent aliasing and yet allow ti=92s only current use case. =97>Andy >=20 > Nico > -- >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Thu Sep 4 08:33:51 2014 Return-Path: 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 1BA8D1A0375; Thu, 4 Sep 2014 08:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 Y4H-I8mjtOxU; Thu, 4 Sep 2014 08:33:48 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 856591A034A; Thu, 4 Sep 2014 08:33:48 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 5C6D74012D68C; Thu, 4 Sep 2014 08:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=8y+ubvpTHQ1DplTDgelB408wOP4=; b=jYj/9h+7+Q9 rDpdj2nfU8MJeqI91dSgjWydqxViS7BUxvcA9+PN2n6Lz28LSbwprtP1kqvnreWp 2rcnrg7gzVE7cahqhJ42wZX3/MKUOwFYVL8LDYLF48WaCi72ocf1STTbvxdUzSod mT1iEqMAhPLPZX/vV1pmD2/0nOuKSjbA= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id D9FF3400F8A2A; Thu, 4 Sep 2014 08:33:47 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so1323854wib.9 for ; Thu, 04 Sep 2014 08:33:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.37.241 with SMTP id b17mr6749906wik.70.1409844826692; Thu, 04 Sep 2014 08:33:46 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Thu, 4 Sep 2014 08:33:46 -0700 (PDT) In-Reply-To: References: <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> <20140903041240.GG2664@localhost> <20140903174741.GA24790@fieldses.org> <20140903192855.GA25363@fieldses.org> <20140903194905.GB25363@fieldses.org> Date: Thu, 4 Sep 2014 10:33:46 -0500 Message-ID: From: Nico Williams To: "Adamson, Andy" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/kps2XXUjUlSWKQlgvy4-wJ36C_c Cc: "J. Bruce Fields" , "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:33:49 -0000 On Thu, Sep 4, 2014 at 6:57 AM, Adamson, Andy wrote: > > On Sep 3, 2014, at 5:17 PM, Nico Williams wrote: > >> On Wed, Sep 3, 2014 at 3:54 PM, Benjamin Kaduk wrote: >>> On Wed, 3 Sep 2014, J. Bruce Fields wrote: >>>> Sounds like there's work to do. >>> >>> I agree. >> >> I agree. I wrote this eons ago and never got to implement. >> >> Multi-principal authentication is critical for security on multi-user >> clients. We should get it right. > > Yes. But! If we add more structure to prevent aliasing - e.g. attach it t= o a client machine (or clientid) then it will prevent it=E2=80=99s use in N= FSv4.2 Inter server to server copy where the user principal on one client m= achine is permitting another client (the destination server acting as a cli= ent) to act on it=E2=80=99s behalf. Huh? I don't see the connection. > I say we keep the current nonce and simply insist on privacy. This will p= revent aliasing and yet allow ti=E2=80=99s only current use case. That's too risky. From nobody Thu Sep 4 09:38:33 2014 Return-Path: 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 EF3551A0503; Thu, 4 Sep 2014 09:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.57 X-Spam-Level: X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, 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 QMO4EAQb06Zn; Thu, 4 Sep 2014 09:38:21 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D861A6F64; Thu, 4 Sep 2014 09:38:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,467,1406617200"; d="scan'208";a="186418055" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx12-out.netapp.com with ESMTP; 04 Sep 2014 09:37:59 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 4 Sep 2014 09:37:52 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com ([::1]) by hioexcmbx08-prd.hq.netapp.com ([fe80::3405:c28f:f61a:e768%21]) with mapi id 15.00.0913.011; Thu, 4 Sep 2014 09:37:52 -0700 From: "Adamson, Andy" To: Nico Williams Thread-Topic: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication Thread-Index: AQHPvIu/oTjXtXsIRU6yu54YN8rMk5vunpMAgAC4SYCAAOO2gIAADJgAgAAPsICAAAL0gIAAAq+AgAASN4CAAAZ9AIAA9fQAgAA8VwCAABHvgA== Date: Thu, 4 Sep 2014 16:37:51 +0000 Message-ID: <1C1901CB-8F67-4E5C-8B62-DF3C5990539D@netapp.com> References: <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> <20140903041240.GG2664@localhost> <20140903174741.GA24790@fieldses.org> <20140903192855.GA25363@fieldses.org> <20140903194905.GB25363@fieldses.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1874) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/nXm3sFPl0lr_L-07Y3vSCkeyoLs Cc: "J. Bruce Fields" , "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 16:38:23 -0000 On Sep 4, 2014, at 11:33 AM, Nico Williams wrote: > On Thu, Sep 4, 2014 at 6:57 AM, Adamson, Andy > wrote: >>=20 >> On Sep 3, 2014, at 5:17 PM, Nico Williams wrote: >>=20 >>> On Wed, Sep 3, 2014 at 3:54 PM, Benjamin Kaduk wrote: >>>> On Wed, 3 Sep 2014, J. Bruce Fields wrote: >>>>> Sounds like there's work to do. >>>>=20 >>>> I agree. >>>=20 >>> I agree. I wrote this eons ago and never got to implement. >>>=20 >>> Multi-principal authentication is critical for security on multi-user >>> clients. We should get it right. >>=20 >> Yes. But! If we add more structure to prevent aliasing - e.g. attach it = to a client machine (or clientid) then it will ^^^ should be =93could=94 not necessarily =93will" >> prevent it=92s use in NFSv4.2 Inter server to server copy where the user= principal on one client machine is permitting another client (the destinat= ion server acting as a client) to act on it=92s behalf. >=20 > Huh? I don't see the connection. Have you read the NFSv4.2 use of GSSv3 for inter server to server copy? The= destination server (acting as an NFS client) needs to READ the file from t= he source server. It needs to do so on behalf of the user-principal that s= tarts the copy from the client. The destination server does not have a GSS = context for the user-principal, as the user is logged onto the client, not = the destination server. The multi-principal nonce, MIC of nonce using the = user-principal context is created on the client and sent with the user-prin= cipal context handle in a privacy protected structured privilege to the det= ination server which then uses it in a privacy protected multi-principal (p= lus structured privilege) assertion to the source server. If the multi-principal nonce was replaced by data that tied the multi-princ= ipal use to a client machine, then in the above passing of the multi-princi= pal data from the inter server to server client to the destination server (= to allow the destination server to act on behalf of the user-principal) wou= ld not work. In essence, NFSv4.2 inter server to server copy=92s use of multi-principal = assertion is aliasing. >=20 >> I say we keep the current nonce and simply insist on privacy. This will = prevent aliasing and yet allow ti=92s only current use case. >=20 > That's too risky. Perhaps we allow a multi-principal aliasing mode. =97>Andy >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Fri Sep 5 08:02:24 2014 Return-Path: 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 267BD1A070F for ; Fri, 5 Sep 2014 08:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 m-8LknOX76zk for ; Fri, 5 Sep 2014 08:01:56 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705D61A0711 for ; Fri, 5 Sep 2014 08:01:56 -0700 (PDT) X-AuditID: 1209190e-f79d46d000003643-f5-5409d0630c5c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id E2.06.13891.360D9045; Fri, 5 Sep 2014 11:01:55 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s85F1sno014290 for ; Fri, 5 Sep 2014 11:01:55 -0400 Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s85F1rRe016455 for ; Fri, 5 Sep 2014 11:01:54 -0400 From: Greg Hudson To: kitten@ietf.org References: <1409243818.9966.3.camel@redhat.com> Date: Fri, 05 Sep 2014 10:57:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRmVeSWpSXmKPExsUixCmqrZt8gTPEoP0iv8XRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfbzXqaC5+wVOz9/Zm1g3MXWxcjJISFgIvH9/kkoW0ziwr31 QDYXh5DAbCaJBbN/sIAkhASOMUpsuSQOkWhnknj9+jgTSIJNQFli/f6tYEUiAsISu7e+Ywax hQWcJGYuuQU0iQOowUDi7Q9pkDCLgKrEzhdzGEFsXgFDiRlvP7FA2IISJ2c+AbOZBbQkbvx7 yTSBkXcWktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdI31cjNL9FJTSjcxgkNGkm8H 49eDSocYBTgYlXh4F37mCBFiTSwrrsw9xCjJwaQkyht9ijNEiC8pP6UyI7E4I76oNCe1+BCj BAezkgiv7W6gHG9KYmVValE+TEqag0VJnPettVWwkEB6YklqdmpqQWoRTFaGg0NJgnfxeaBG waLU9NSKtMycEoQ0EwcnyHAeoOEzQGp4iwsSc4sz0yHypxiNOVqa3vYycazr/NbPJMSSl5+X KiXOm3cOqFQApDSjNA9uGizuXzGKAz0nzDsXZCAPMGXAzXsFtIoJaJV5OtiqkkSElFQDY/q6 qEM7jeONjy5IiZpQ1FMw0fTBqsOcnnsXzWBQZlxakPzz3NQ1b6sV5ZOFnmaZbTc6ze3wcbW1 w3Mn91BX8U+6W0qN1QLdJ9sWGD1juOl1zFrravR6z4T078miv3fv09G8wDUr1OxoNIfbYw8m qztrTzbPCuDLrZBYWld//+GSywvilW2slFiKMxINtZiLihMB4v8puNYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mlEEQLr0dnzA6ofdt7d2IAg0cys Subject: Re: [kitten] Authentication Indicator in Kerberos tickets X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:02:05 -0000 > I have submitted a new draft for Kerberos Authentication Indicators > and I'd like to start a discussion about moving the draft through the > process. I think the working group should adopt this document. It's relatively simple and it provides a first consumer for the CAMMAC container. It fits easily within the "new authorization data types" item in the working group charter. The general use case has plenty of history. Deployments like MIT's have been doing something similar with "root instance" principals for a long time: people have one principal for day-to-day use, and another principal with a name like "ghudson/root" with greater access. Originally, root instance principals just had different (hopefully better) passwords which don't get typed as often, but these days root instance principals often require two-factor authentication. The authentication indicator allows the same kind of restriction without requiring a separate principal for elevated access. From nobody Fri Sep 5 10:05:18 2014 Return-Path: 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 A2FFD1A0B08 for ; Fri, 5 Sep 2014 10:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 63wnzlNO-sVD for ; Fri, 5 Sep 2014 10:05:11 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD401A0AE2 for ; Fri, 5 Sep 2014 10:05:11 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-a3-5409ed46a624 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id E9.73.27750.64DE9045; Fri, 5 Sep 2014 13:05:10 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s85H594E027245 for ; Fri, 5 Sep 2014 13:05:10 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s85H57Ci000581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 5 Sep 2014 13:05:09 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s85H569N026751; Fri, 5 Sep 2014 13:05:06 -0400 (EDT) Date: Fri, 5 Sep 2014 13:05:06 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <53F53D1F.7010305@oracle.com> Message-ID: References: <52AE9A65.1010700@oracle.com> <53F53D1F.7010305@oracle.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixG6nouv2ljPEYM19QYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr48Tlm2wF66wqDnWuYG5g/K/XxcjJISFgIrHr11R2CFtM4sK9 9WxdjFwcQgKzmSTu7fvMCuEcY5RoP72FHcK5ziRx+norK0iLkEC9xJTG52A2i4CWxP4Ln5lA bDYBFYmZbzaygdgiAsISu7e+YwaxhQVsJY6vawOr5wSqfzFjGdhqXgFHiXtHb0HNdJf49nIl WL2ogI7E6v1TWCBqBCVOznwCZjMD9S6fvo1lAqPALCSpWUhSCxiZVjHKpuRW6eYmZuYUpybr Ficn5uWlFuka6uVmluilppRuYgSFH6ckzw7GNweVDjEKcDAq8fAu+MwRIsSaWFZcmXuIUZKD SUmUd+trzhAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzHLgHleFMSK6tSi/JhUtIcLErivG+t rYKFBNITS1KzU1MLUotgsjIcHEoSvDZvgBoFi1LTUyvSMnNKENJMHJwgw3mAhluD1PAWFyTm FmemQ+RPMepyrOv81s8kxJKXn5cqJc57EuQ6AZCijNI8uDmwtPGKURzoLWFeLpBRPMCUAzfp FdASJqAl5ulgS0oSEVJSDYxTovJunpvRlR1qtPnrj5rfQTdsy1bePlKy5/c6Fe+J6SkMhQJa /1Vft1pyRlXXz7+7+H3PlbrMdeaPT6mb1NRJmV5xOV43N+9MbTT/hmureN6eydXIcvtgLOac um1+BFup4aMTZUsfStWENKjmit77mFJy4r7WYte2EgP7XDntngTLO1ktXUosxRmJhlrMRcWJ AF+fOOr2AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/RCNKuTIbDa84ByPz1MGi-RcGBPo Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-15 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 17:05:18 -0000 On Wed, 20 Aug 2014, Shawn M Emery wrote: > This message officially starts the 3rd kitten Working Group Last Call > for the following document: > > A set of SASL Mechanisms for OAuth > http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-15 > > The Working Group Last Call for this document starts today on Wednesday, > August 20th and will end on Wednesday, September 3rd. Oops, I'm late. Sorry. I'm neither a SASL expert nor an OAuth one, but I think I can get the general sense of things here. OAuth is already well established for webapps, and there's a desire to repurpose it for authorizing access to resources over non-http protocols, in particular protocols using SASL for authentication. This document, then, specifies how to represent the OAuth messages inside SASL mechanisms, for messages between the parties described in the OAuth terminology as the "client" and "resource server". Since the OAuth messages are already specified, this is mostly just a translation, along with specifying which pieces are required. The most significant comment I have concerns section 3.2.2, the server response to failed authentication. I fear that it is under-specified, and inconsistent with the example in section 4.3: Section 3.2.2 leaves me wishing there was more detail. I see that section 4.3 includes an example of this JSON object, but I think that more detail is appropriate in a protocol specification. Are all of the values always going to be strings? (Is the "OAuth 2 core specification" just RFC 6749? If so, it's better to cite it by number.) The IANA OAuth Extensions Error Registry seems to give errors by name, e.g., "invalid_token". Pulling up RFC 6750, it seemse that when invalid_token is used, "the resource SHOULD respond with the HTTP 401 (Unauthorized) status code". But the example in section 4.3 uses the string "401", not the JSON number, nor the string form of the name! This is very confusing. Likewise, for the 'scope' named value, what are valid values? Is there a list of them somewhere? Are they arbitrary, chosen by the application? This needs to be specified. The oauth-configuration named value is in better shape, as a URL is pretty inherently a string, but that could still be made explicit. My other comments are largely editorial; I have placed the more important ones first and the stuff that's probably very minor at the end (after a note). However, it's a fairly significant issue that all of the IMAP examples do not actually indicate they are for IMAP. The SMTP exchanges are indicated as such, which makes me suspect that originally only IMAP examples were present, with the SMTP examples added later and the IMAP examples not adjusted to reflect that they are only one class of example. In particular, this affects the top of sections 4.1, and 4.3. 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. The C/S exchanges in section 4.3 seems to have lost the "Server Ready" and "t0 CAPABILITY" lines that are present in the previous examples. At the end of section 4.3, I would clarify that the required dummy response (as seen in the example as "AQ==") is the base64 encoding of %x01, which was mentioned earlier in the text. This happens again at the end of section 4.4, but may not need the additional clarification at the second occurrence. In section 5, under "Access tokens have a lifetime", I think that "The client may request a new access token" should use the RFC 2119 "MAY". 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? In section 3.1, for 'host', can we be more specific? Is this a DNS name? The name that would have been presented in an HTTP header if this was being carried out over HTTP? Vague text like this could lead to interoperability issues. 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. The first sentence of section 3.1.1 mentions the query string, which is covered in the previous section (3.1); I think one should be moved so they are in the same place. 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. Editorial minutiae: The phrase "or by allowing the third-party application to obtain access on its own behalf", used in both the abstract and introduction, seems a little confusing to me. Is this just supposed to be differentiating between flows where the user sees a prompt page from the authorization server and flows where the user does not? 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. 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. The text in the first paragraph of 3.1 about "carry the equivalent values from an HTTP context [...]" could be more clear. I might say that these key/value pairs "take the place of the corresponding HTTP headers and values to convey the information necessary to complete [...]". I would probably replace "The following key/value pairs are defined in the client response" with "The following keys and corresponding values are defined in the client response", since the list is not of key/value pairs but rather a list of keys, with the text content for each item being a description of the value to be used for that key. For 'auth', "for an equivalent HTTP OAuth authorization" is an awkward phrasing, since "equivalent" is not really specified; I might use something like "The payload that would be in the HTTP Authorization header if this OAuth exchange was being carried out over HTTP". Please insert a comma before "Figure" in the first sentence of the fourth paragraph of section 1. On page 5, in the large paragraph, "a discovery mechanisms" is a singular/plural mismatch. In section 3.1, replace "or may be empty" with "which may be empty". In section 3.2, I would replace "per the specification" with "according to the specification". In section 3.2.2 (last sentence), "presume an empty scope (unscoped token) is needed" is a little odd; it might be better to say "should be used" instead of "is needed". -Ben From nobody Fri Sep 5 12:57:58 2014 Return-Path: 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 B449F1A0087; Fri, 5 Sep 2014 12:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 oCrUDt2ZjQz8; Fri, 5 Sep 2014 12:57:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECA01A008C; Fri, 5 Sep 2014 12:57:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140905195755.12365.12570.idtracker@ietfa.amsl.com> Date: Fri, 05 Sep 2014 12:57:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/-MeZZ1I_H0cEUgbeNKowdRnVZAI Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-krb-wg-cammac-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 19:57:56 -0000 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 Working Group of the IETF. Title : Kerberos Authorization Data Container Authenticated by Multiple MACs Authors : Simo Sorce Tom Yu Thomas Hardjono Filename : draft-ietf-krb-wg-cammac-09.txt Pages : 9 Date : 2014-09-05 Abstract: Abstract: This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-krb-wg-cammac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-cammac-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 5 13:03:07 2014 Return-Path: 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 22D5E1A009C; Fri, 5 Sep 2014 13:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 ursP7WC7Gf32; Fri, 5 Sep 2014 13:02:51 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46261A008C; Fri, 5 Sep 2014 13:02:50 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-b0-540a16e9ce56 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 5E.DB.13180.9E61A045; Fri, 5 Sep 2014 16:02:49 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s85K2mmg006225; Fri, 5 Sep 2014 16:02:49 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s85K2k9x007512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Sep 2014 16:02:47 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s85K2j0j019268; Fri, 5 Sep 2014 16:02:45 -0400 (EDT) Date: Fri, 5 Sep 2014 16:02:45 -0400 (EDT) From: Benjamin Kaduk To: "Adamson, Andy" , NFSv4 In-Reply-To: <20140804164302.GJ3579@localhost> Message-ID: References: <20140801055401.GA7409@localhost> <8FD0C272-6FD3-44FE-BD3D-BAB220E0FF13@netapp.com> <20140801221535.GA3579@localhost> <20140804160016.GC23341@fieldses.org> <20140804164302.GJ3579@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixCmqrPtSjCvE4HqPjsXRzatYLGa/f8Rq MX2RlQOzx5IlP5k8Znz6whbAFMVlk5Kak1mWWqRvl8CV8WbeFOaCJs6KrXueMzcwTmHvYuTk kBAwkfhzqIkJwhaTuHBvPRuILSQwm0ni22H7LkYuIHsDo8SJn6vYIZyDTBJzb8yCqqqXuN92 EsxmEdCSOH2uhxXEZhNQkZj5ZiNYXETAQ+LYnqNg25gF1CW+nXnDCGILC7hJNL/6xQxicwro SfR2fQSL8wo4SnSu/ccIsWwzk8TCI31g54kK6Eis3j+FBaJIUOLkzCcsEEO1JJZP38YygVFw FpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9HIzS/RSU0o3MYJClt1FeQfjn4NK hxgFOBiVeHgXfOYIEWJNLCuuzD3EKMnBpCTKKyTIFSLEl5SfUpmRWJwRX1Sak1p8iFGCg1lJ hDftB2eIEG9KYmVValE+TEqag0VJnPettVWwkEB6YklqdmpqQWoRTFaGg0NJgldDFGioYFFq empFWmZOCUKaiYMTZDgP0PBQkBre4oLE3OLMdIj8KUZdjnWd3/qZhFjy8vNSpcR5F4gAFQmA FGWU5sHNgaWaV4ziQG8J80aDjOIBpim4Sa+AljABLTFPB/mguCQRISXVwDg17nFIdezrjUsu fH4097VCtIbVk0D3QB3TlHKH2Bj+xh4254gVW8S4a65GnsoQKPndIOcRUF679vTKx5nPP0tM d61+UTJ3w2WPA4vPyWoe9xD+oz3NyOWzU/O1zPJpz4Llt8m1ahuqcS437yry4P4Ver1FPePZ 5nMbti6O+XH70btdSsL7/ZVYijMSDbWYi4oTAZhdZfUQAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/AipEsWwQXte53us-1fF7R4GJTMw Cc: "kitten@ietf.org" Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 20:02:55 -0000 On Mon, 4 Aug 2014, Nico Williams wrote: > On Mon, Aug 04, 2014 at 12:00:16PM -0400, J. Bruce Fields wrote: > > On Fri, Aug 01, 2014 at 05:15:36PM -0500, Nico Williams wrote: > > > It was always my intention that traditional (read: multi-user > > > shared-cache) NFS client implementations would just always use > > > "multi-principal" contexts when doing any RPCs on a user's behalf. > > > > > > That is, addressing the "user can impersonate the server to the client" > > > problem was always my first and foremost goal with this protocol, though > > > I didn't always say so explicitly (since at the time the attack was not > > > well-known, I didn't want to publicize it). > > > > Oh, that's really helpful to know. > > Yeah :( I mentioned it several times at meetings. The cat has been > out of the bag for a long time as to the vulnerability for shared-cache > clients, so we might as well state this motivation clearly. I don't remember seeing new text clarifying the potential attack going by, so I'll note that what we did for rxgk is in section 7 of https://tools.ietf.org/html/draft-wilkinson-afs3-rxgk-afs-06 -Ben From nobody Fri Sep 5 13:34:24 2014 Return-Path: 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 E8DE61A00AE for ; Fri, 5 Sep 2014 13:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 A2a08VZoVC9Y for ; Fri, 5 Sep 2014 13:34:20 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BDE1A00E2 for ; Fri, 5 Sep 2014 13:34:20 -0700 (PDT) X-AuditID: 1209190f-f79aa6d000005b45-19-540a1e4a4029 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id D0.2C.23365.A4E1A045; Fri, 5 Sep 2014 16:34:18 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s85KYHeB030015 for ; Fri, 5 Sep 2014 16:34:18 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s85KYG9d019643 for ; Fri, 5 Sep 2014 16:34:17 -0400 From: Tom Yu To: kitten@ietf.org References: <20140905195755.12365.12570.idtracker@ietfa.amsl.com> Date: Fri, 05 Sep 2014 16:34:15 -0400 In-Reply-To: <20140905195755.12365.12570.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Fri, 5 Sep 2014 12:57:55 -0700") Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLIsWRmVeSWpSXmKPExsUixCmqreslxxVisK9HwOLo5lUsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuPpsCXPBMpaK9T3tLA2Mh5i7GDk4JARMJP4stuli5AQyxSQu 3FvP1sXIxSEkMJtJ4sbeuVDOMUaJ0w/fMkI4jUwSX1qfs4K0sAlISxy/vIsJxBYREJbYvfUd M4gtLOAosaDrP5gtBGQvbPzBDmKzCKhKXFk/iR1kEKdAP6PE9tObwZp5BXQl/i3vZgOxeQQ4 Jdb3P2OEiAtKnJz5hAXEZhbQkrjx7yXTBEb+WUhSs5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5O zMtLLdI10cvNLNFLTSndxAgOM0n+HYzfDiodYhTgYFTi4V3wmSNEiDWxrLgy9xCjJAeTkijv ZBmuECG+pPyUyozE4oz4otKc1OJDjBIczEoivGk/OEOEeFMSK6tSi/JhUtIcLErivG+trYKF BNITS1KzU1MLUotgsjIcHEoSvG9BhgoWpaanVqRl5pQgpJk4OEGG8wANF5EFquEtLkjMLc5M h8ifYjTmaGl628vEsa7zWz+TEEtefl6qlDgvK0ipAEhpRmke3DRYqnjFKA70nDCvHEgVDzDN wM17BbSKCWiVeTrIH8UliQgpqQZGxZQirwsHPxvx8Acc1Eld69y/RcZimlNQbbD9z5h/Mzax m5uu4qxISHlvaJ2/rsnNvMVC7vWJjse/1LoNtjHmSXTpiU+Lsni39Jro7sIPe+37r/xt7jXk X+ndXXLW+fmTgljj2THdPHae5hHWO1KlrSOevJjz+sWquQuy3ltaKof3tNSbfVdiKc5INNRi LipOBAAX1LoA8AIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/1nXs196NJlHrVKJA_mRzEhgsvjA Subject: Re: [kitten] I-D Action: draft-ietf-krb-wg-cammac-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 20:34:22 -0000 This revision makes some editorial wording changes in responses to feedback. At Greg's suggestion, kdc-verifier is now optional, and I have documented the relevant security considerations for this. I've also specified the non-criticality semantics. I appear to have forgotten to add text documenting the service principal binding issue. Does someone want to suggest wording? I believe these changes all have at least rough WG consensus behind them, but the chairs are welcome to clarify whether they agree that there is consensus. From nobody Fri Sep 5 14:19:03 2014 Return-Path: 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 529891A0303 for ; Fri, 5 Sep 2014 14:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 IxtCL9qhLgaC for ; Fri, 5 Sep 2014 14:18:59 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB401A02EB for ; Fri, 5 Sep 2014 14:18:59 -0700 (PDT) X-AuditID: 12074425-f79e46d000002583-db-540a28c2b239 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 67.95.09603.2C82A045; Fri, 5 Sep 2014 17:18:58 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s85LIvnA016541 for ; Fri, 5 Sep 2014 17:18:57 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s85LIt6W003998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 5 Sep 2014 17:18:57 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s85LItkb028845; Fri, 5 Sep 2014 17:18:55 -0400 (EDT) Date: Fri, 5 Sep 2014 17:18:55 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: <1409243818.9966.3.camel@redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUixCmqrHtIgyvE4MU5Voujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY+fdR4wFp1kqTj47xdjAuJO5i5GTQ0LAROLmwguMELaYxIV7 69m6GLk4hARmM0nMubQEyjnGKPFk2WpWCOc6k8TTF9tYQVqEBOolGg4fYQexWQS0JFZ9e88C YrMJqEjMfLORDcQWERCW2L31Hdg6YQEniZlLboHFOQWMJBad2Aw0h4ODV8BRYlKbOsTIMIkp 25cxgdiiAjoSq/dPARvJKyAocXLmEzCbGWjV8unbWCYwCsxCkpqFJLWAkWkVo2xKbpVubmJm TnFqsm5xcmJeXmqRroVebmaJXmpK6SZGUPCxu6juYJxwSOkQowAHoxIP74LPHCFCrIllxZW5 hxglOZiURHlvqXOFCPEl5adUZiQWZ8QXleakFh9ilOBgVhLhTfvBGSLEm5JYWZValA+TkuZg URLnfWttFSwkkJ5YkpqdmlqQWgSTleHgUJLg/QwyVLAoNT21Ii0zpwQhzcTBCTKcB2j4E5Aa 3uKCxNzizHSI/ClGY46Wpre9TBzrOr/1Mwmx5OXnpUqJ8/5TAyoVACnNKM2DmwZLIK8YxYGe E+Z9AzKQB5h84Oa9AlrFBLTKPB3kj+KSRISUVAOjfNSc44ub913Y++eXtvIqrvuhGbtTciW0 y6VvqX28/eucxx7d3zFuF9b+Pd7fY3V+7sXf26tYM/8853uypr3yBuOVpVqOJ29sdjCL+q8Y f73hKJdgHjP7O84Xy1y2+z1ta976zUXnTI0Am+/RQ54SFofZ9j0TYbf58kNTYUWcx/fQ2ftS t7n+VGIpzkg01GIuKk4EAH4E8cT7AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/l8CYdlDmt7Wz5AhR3pi9Ll6prRE Subject: Re: [kitten] Authentication Indicator in Kerberos tickets X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 21:19:02 -0000 On Fri, 5 Sep 2014, Greg Hudson wrote: > fits easily within the "new authorization data types" item in the > working group charter. I agree that it's in the charter: % Prepare, review, and advance standards-track and informational % specifications defining new authorization data types for carrying % supplemental information about the client to which a Kerberos % ticket has been issued and/or restrictions on what the ticket can % be used for. This seems to be information about the client to which a ticket will be issued. -Ben From nobody Fri Sep 5 15:29:45 2014 Return-Path: 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 D0A4C1A02F1 for ; Fri, 5 Sep 2014 15:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.833 X-Spam-Level: X-Spam-Status: No, score=0.833 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, 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 LWD1EnXhf4Up for ; Fri, 5 Sep 2014 15:29:42 -0700 (PDT) Received: from nm27-vm1.bullet.mail.bf1.yahoo.com (nm27-vm1.bullet.mail.bf1.yahoo.com [98.139.213.148]) (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 643821A0115 for ; Fri, 5 Sep 2014 15:29:42 -0700 (PDT) Received: from [98.139.212.152] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 05 Sep 2014 22:29:41 -0000 Received: from [98.139.212.237] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 05 Sep 2014 22:29:41 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 05 Sep 2014 22:29:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 571083.14245.bm@omp1046.mail.bf1.yahoo.com Received: (qmail 62175 invoked by uid 60001); 5 Sep 2014 22:29:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1409956181; bh=i6pq0Y/TqOgL/TMAbyqRp9Vx0lIEYAaCm8VbN7g2lK4=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YgA6Tgbn4WyyHn+rT/qbvWMHVh/tSi6uN66wQc1DrzzGXVA+kAUFnLC90PA/L7knB6a40NWl+hQ5si102hUCr1zCadIFKvHDjT2YiAMpAmYxkIIVoNAB7TJocpWZSXzy9CsEHTEZP/FXfh0vVRDdrvcZS483y6xNJYti0HHXOcE= X-YMail-OSG: TUy.Q5EVM1lRdqJI3yMzqh4XNufsqYGFywjIpjr8uAsvaHy rtl.5_PdTCi0BrpRfwmEkYVwP12MEYzpdfRfJntS17X0us8CAI3cAi47TQqB 2xV3Vc2BpUepPrxjMfL0yZ4etRr_aM2uN2BJBQ2Pk2qA.eAXMszg8UveSbXb dCzA87TtwI9tfo2Og0DqhX1C0EdLotdqdKeB3qHun0wEAUH1Elt2uh_OmKKh S9nRkqnBxbcdgdNqwQKI2cxpzFeITuOtBmcD_NW5VELE2QbvzH48.AjBHpVi jPugqysAD6nOqw1ZKP2RMqZ.WCVbw5HMu3RAXivQ61_c.bxoXybsHWLxfkik 5FmdljAJDv8Tbaoa7WwjZHU7gn.mhiFepBjh0lz8lECchJiB_eef1jXGOEuk .kPNakEgcw20cW0QdutRvBpxXZMktfXWCzjyADAw5VlFotPRYzL85TZT1195 3DfQmYdlYq4JPIxNQYj1i565vbAfzy4drsXwz5tv.aS5DFgtHfjXa2b8UlIn JspTHqCnTOAnsvvh_HPEQ1IhQ_RP7rdkZH9sP9UlMlqMiphygYTh6xYoPjw- - Received: from [167.220.24.57] by web142802.mail.bf1.yahoo.com via HTTP; Fri, 05 Sep 2014 15:29:41 PDT X-Rocket-MIMEInfo: 002.001, WWVwLCA0MDEgaXMgd3JvbmcuICBDaGFuZ2VkIHRvICJpbnZhbGlkX3Rva2VuIiBpbiB0aGUgZXhhbXBsZSAocGVuZGluZyAtMTYpLgoKVGhhbmtzIQoKLWJpbGwKCgpPbiBXZWRuZXNkYXksIFNlcHRlbWJlciAzLCAyMDE0IDI6MzYgUE0sIEphbWllIE5pY29sc29uICjlgKrlv5fmmI4pIDxuaWNvbHNvbkBnb29nbGUuY29tPiB3cm90ZToKIAoKCkhvcGUgdGhpcyBpc24ndCB0b28gbGF0ZToKClNlY3Rpb24gMy4yLjIgZGVzY3JpYmVzIHRoZSAic3RhdHVzIiBwb3J0aW9uIG9mIHRoZSBlcnJvciByZXNwb25zZSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <1407443152.85652.YahooMailNeo@web142802.mail.bf1.yahoo.com> Message-ID: <1409956181.98646.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Fri, 5 Sep 2014 15:29:41 -0700 From: Bill Mills To: =?utf-8?B?SmFtaWUgTmljb2xzb24gKOWAquW/l+aYjik=?= In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-1103238567-1409956181=:98646" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/3fN6s7drA8yGk-0vdHk8LKy6Jtk Cc: "kitten@ietf.org" Subject: Re: [kitten] next steps on oauth sasl draft? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 22:29:44 -0000 --1397251415-1103238567-1409956181=:98646 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yep, 401 is wrong. Changed to "invalid_token" in the example (pending -16)= .=0A=0AThanks!=0A=0A-bill=0A=0A=0AOn Wednesday, September 3, 2014 2:36 PM, = Jamie Nicolson (=E5=80=AA=E5=BF=97=E6=98=8E) wrote:= =0A =0A=0A=0AHope this isn't too late:=0A=0ASection 3.2.2 describes the "st= atus" portion of the error response as being an error code from the OAuth E= xtensions Error Registry. That registry lists codes like "invalid_request",= "invalid_token", etc. However, in section 4.3, there is an example of an e= rror response that has "status":"401". I don't see any way of mapping betwe= en the OAuth string error codes and numeric, http-style codes like 401. Am = I missing something or is this a typo?=0A=0A=0A=0AOn Thu, Aug 7, 2014 at 1:= 25 PM, Bill Mills wrote:=0A=0AThe OAuth SASL draft= was in WGLC, but we made significant changes. We've had one brief review = of it since -15, that doesn't seem like enough to say it might be close to = WGLC eligible again. I'd especially like it if one or more of the folks at= Google could take a look as they're the major implementor so far.=0A>=0A>= =0A>Hoping to wrap this up.=0A>=0A>=0A>Thanks,=0A>=0A>=0A>-bill=0A>________= _______________________________________=0A>Kitten mailing list=0A>Kitten@ie= tf.org=0A>https://www.ietf.org/mailman/listinfo/kitten=0A>=0A> --1397251415-1103238567-1409956181=:98646 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yep, 401 is wrong.  Changed to "invalid_token= " in the example (pending -16).

Thanks!

-bill


<= div style=3D"font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial= , 'Lucida Grande', sans-serif; font-size: 12pt;">
On Wednesday, September 3, 2014 2:36 PM, Jamie Nicolson (=E5=80=AA=E5=BF= =97=E6=98=8E) <nicolson@google.com> wrote:

Hope this isn't too late:

Sectio= n 3.2.2 describes the "status" portion of the error response as being an error code from the OAuth Extensions Err= or Registry. That registry lists codes like "invalid_request", "invalid_tok= en", etc. However, in section 4.3, there is an example of an error response= that has "status":"401". I don't see any way of mapping between the OAuth = string error codes and numeric, http-style codes like 401. Am I missing som= ething or is this a typo?


On Thu, Aug 7, 2014 at 1:25 PM, Bill Mills <wmills_92105@yahoo.co= m> wrote:
The OAuth SASL draft was in WGLC, but we= made significant changes.  We've had one brief review of it since -15= , that doesn't seem like enough to say it might be close to WGLC eligible a= gain.  I'd especially like it if one or more of the folks at Google co= uld take a look as they're the major implementor so far.

Hoping to wrap this up.

Thanks,

-bill

__________________________________________= _____
=0AKitten mailing list
=0AKitten@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/= kitten
=0A



--1397251415-1103238567-1409956181=:98646-- From nobody Fri Sep 5 17:15:21 2014 Return-Path: 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 E77581A06CB for ; Fri, 5 Sep 2014 17:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 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=-0.668, 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 u_y7Syqc7hdu for ; Fri, 5 Sep 2014 17:14:59 -0700 (PDT) Received: from nm39-vm1.bullet.mail.bf1.yahoo.com (nm39-vm1.bullet.mail.bf1.yahoo.com [72.30.239.145]) (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 3ECA91A06A6 for ; Fri, 5 Sep 2014 17:14:59 -0700 (PDT) Received: from [66.196.81.172] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 06 Sep 2014 00:14:58 -0000 Received: from [98.139.212.247] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 06 Sep 2014 00:14:58 -0000 Received: from [127.0.0.1] by omp1056.mail.bf1.yahoo.com with NNFMP; 06 Sep 2014 00:14:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 255235.15894.bm@omp1056.mail.bf1.yahoo.com Received: (qmail 57284 invoked by uid 60001); 6 Sep 2014 00:14:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1409962498; bh=VSjY15EN2NBHrMeUsh/teCC3+5gdrSTgYya62gRmjjE=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=RmThjI0V6FHBu7T50O18gtGpeel+LRYBIR7GGJz6u5GsJXv+XPAyYH87Cd0vxMPMl5kjvRBkxfcaInMP7i1M+BLLIwo2A5juOuNUaDEagjS1yw4Mo5+6ShWNcHwY1NhhOOX+NE9kZoVwqT4Qq49D1MumNmlJyW5FzwVpMLIysfY= X-YMail-OSG: Br8_Zm0VM1kGOTNTM_EAdhhrzBv04YoIQtVmZ0387gKC2BT eHpN0K0y9fZBFOL6yJb4YAhymJA5qjMjFt7Hb7qnoLj5AAko9NBMGniEPlfV taLaKwt7iab1HDdVPIVwebWFW1kUI.rEOLlMJv457LBkrxbSRU_P.N2Xjkoj 8lHtgzUuKS.ukG46qJ4oFjwHOhzeUvSRqZs0hLbmTcPxmyiaWLILgY1Qv_G4 ILLa5bOqWLxBjaM.K.DNYsMn6mCNX4pGIXHY0m4hzTGag92rJBaPnTvkfrv4 4u9FXi8AGOoiTz0j6zbS4Mdb562yZVGb80xPrMQINhqxlTURIZsQKrEeE_Aq OBNLbvwHDwCIUURpaFhB67eP98b1rcj9rFJMB_5x3fiVm.u1k4uupuNsYQfF Rn.sn69RLdbvmExmutS8pVQGNuWK_.g6OHAc9W1B6mYgPM9dsWKvrTic.VRm AW4FalwXCQWRKiV6IbhlSJW4lTNglqf5wMl2ShJXHuEPesOQXutXZUGfteJA U4X7cH44bb0ARr9bRPtO26tu0CZfnMp4DlLLeHI0SaFtRr_ZJF8zYKcrLdxM F_mwxlDT6K9hBzh2LH8e0yuSA7_mzxjGGuSA3ROmJWcfmSuQQav5SvnmM8u0 bLwcRLz.UVy0.WnUDnD20K0f.6TKzf4yy9x6wbsi9E4WF_R.YdETxfngolhT s21Ygu1vsNcSZhWsBD3upxI8- Received: from [167.220.24.57] by web142804.mail.bf1.yahoo.com via HTTP; Fri, 05 Sep 2014 17:14:58 PDT X-Rocket-MIMEInfo: 002.001, CgpDb21tZW50cy9yZXNwb25zZXMgaW5saW5lIGJlbG93LgoKVXBkYXRlZCAgcHJlIC0xNiBjb3B5IGF2YWlsYWJsZSBhdCAKCnRleHQ6IGh0dHBzOi8vZHJpdmUuZ29vZ2xlLmNvbS9maWxlL2QvMEI5OVlTa3hTNlplZmRIRktUVWhvZHpZM2NqQS9lZGl0P3VzcD1zaGFyaW5nCmh0bWw6IGh0dHBzOi8vZHJpdmUuZ29vZ2xlLmNvbS9maWxlL2QvMEI5OVlTa3hTNlplZmVqRlNMVTkzVDFObGRtYy9lZGl0P3VzcD1zaGFyaW5nCgpZb3UnbGwgbmVlZCB0byBkb3dubG9hZCB0aGUgSFRNTCB0byB2aWV3IGl0IGluIGEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <52AE9A65.1010700@oracle.com> <53F53D1F.7010305@oracle.com> Message-ID: <1409962498.54315.YahooMailNeo@web142804.mail.bf1.yahoo.com> Date: Fri, 5 Sep 2014 17:14:58 -0700 From: Bill Mills To: Benjamin Kaduk , "kitten@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2129327256-357860453-1409962498=:54315" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/blfY1akHpDt9Ntb5nYqy7Tq8jyI 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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 00:15:09 -0000 ---2129327256-357860453-1409962498=:54315 Content-Type: text/plain; charset=us-ascii Comments/responses inline below. Updated pre -16 copy available at text: https://drive.google.com/file/d/0B99YSkxS6ZefdHFKTUhodzY3cjA/edit?usp=sharing html: https://drive.google.com/file/d/0B99YSkxS6ZefejFSLU93T1Nldmc/edit?usp=sharing You'll need to download the HTML to view it in a browser. On Friday, September 5, 2014 10:05 AM, Benjamin Kaduk wrote: On Wed, 20 Aug 2014, Shawn M Emery wrote: > This message officially starts the 3rd kitten Working Group Last Call > for the following document: > > A set of SASL Mechanisms for OAuth > http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-15 > > The Working Group Last Call for this document starts today on Wednesday, > August 20th and will end on Wednesday, September 3rd. Oops, I'm late. Sorry. *** [bill] no worries *** I'm neither a SASL expert nor an OAuth one, but I think I can get the general sense of things here. OAuth is already well established for webapps, and there's a desire to repurpose it for authorizing access to resources over non-http protocols, in particular protocols using SASL for authentication. This document, then, specifies how to represent the OAuth messages inside SASL mechanisms, for messages between the parties described in the OAuth terminology as the "client" and "resource server". Since the OAuth messages are already specified, this is mostly just a translation, along with specifying which pieces are required. The most significant comment I have concerns section 3.2.2, the server response to failed authentication. I fear that it is under-specified, and inconsistent with the example in section 4.3: Section 3.2.2 leaves me wishing there was more detail. I see that section 4.3 includes an example of this JSON object, but I think that more detail is appropriate in a protocol specification. Are all of the values always going to be strings? (Is the "OAuth 2 core specification" just RFC 6749? If so, it's better to cite it by number.) The IANA OAuth Extensions Error Registry seems to give errors by name, e.g., "invalid_token". Pulling up RFC 6750, it seemse that when invalid_token is used, "the resource SHOULD respond with the HTTP 401 (Unauthorized) status code". But the example in section 4.3 uses the string "401", not the JSON number, nor the string form of the name! This is very confusing. *** [bill] Yep, this was wrong and 401 is being changed to "invalid_token" in the example. *** Likewise, for the 'scope' named value, what are valid values? Is there a list of them somewhere? Are they arbitrary, chosen by the application? This needs to be specified. The oauth-configuration named value is in better shape, as a URL is pretty inherently a string, but that could still be made explicit. *** [bill] Scope is defined in OAuth 2.0 and is a string, and it may be a list of space separated scope names. There are no predefined scopes other than the blank/empty one.. *** My other comments are largely editorial; I have placed the more important ones first and the stuff that's probably very minor at the end (after a note). However, it's a fairly significant issue that all of the IMAP examples do not actually indicate they are for IMAP. The SMTP exchanges are indicated as such, which makes me suspect that originally only IMAP examples were present, with the SMTP examples added later and the IMAP examples not adjusted to reflect that they are only one class of example. In particular, this affects the top of sections 4.1, and 4.3. *** [bill] yep. fixing. *** 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. *** The C/S exchanges in section 4.3 seems to have lost the "Server Ready" and "t0 CAPABILITY" lines that are present in the previous examples. *** [bill] yep. fixing. *** At the end of section 4.3, I would clarify that the required dummy response (as seen in the example as "AQ==") is the base64 encoding of %x01, which was mentioned earlier in the text. This happens again at the end of section 4.4, but may not need the additional clarification at the second occurrence. *** [bill] yep. fixing. *** In section 5, under "Access tokens have a lifetime", I think that "The client may request a new access token" should use the RFC 2119 "MAY". *** [bill] OK *** 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". *** In section 3.1, for 'host', can we be more specific? Is this a DNS name? The name that would have been presented in an HTTP header if this was being carried out over HTTP? Vague text like this could lead to interoperability issues. *** [bill] Changed to: "Contains the host name to which the client connected, in an HTTP context this is the value of the HTTP Host header. *** 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" *** The first sentence of section 3.1.1 mentions the query string, which is covered in the previous section (3.1); I think one should be moved so they are in the same place. *** [bill] moved qs to the "reserved for future use section 3.1.1 *** 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. *** Editorial minutiae: The phrase "or by allowing the third-party application to obtain access on its own behalf", used in both the abstract and introduction, seems a little confusing to me. Is this just supposed to be differentiating between flows where the user sees a prompt page from the authorization server and flows where the user does not? *** [bill] the difference is whether you're allowing FaceBook to access your mailbox, or whether its a desktop app like Thunderbird. *** 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." *** 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. *** The text in the first paragraph of 3.1 about "carry the equivalent values from an HTTP context [...]" could be more clear. I might say that these key/value pairs "take the place of the corresponding HTTP headers and values to convey the information necessary to complete [...]". *** [bill] OK *** I would probably replace "The following key/value pairs are defined in the client response" with "The following keys and corresponding values are defined in the client response", since the list is not of key/value pairs but rather a list of keys, with the text content for each item being a description of the value to be used for that key. *** [bill] sure, why not. *** For 'auth', "for an equivalent HTTP OAuth authorization" is an awkward phrasing, since "equivalent" is not really specified; I might use something like "The payload that would be in the HTTP Authorization header if this OAuth exchange was being carried out over HTTP". *** [bill] OK *** Please insert a comma before "Figure" in the first sentence of the fourth paragraph of section 1. *** [bill] and in the XML it's 'environment, ' *** On page 5, in the large paragraph, "a discovery mechanisms" is a singular/plural mismatch. *** [bill] OK *** 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." *** In section 3.2, I would replace "per the specification" with "according to the specification". *** [bill] OK *** In section 3.2.2 (last sentence), "presume an empty scope (unscoped token) is needed" is a little odd; it might be better to say "should be used" instead of "is needed". *** [bill] Now reads, "If the resource server provides no scope to the client then the client SHOULD presume an empty scope (unscoped token) is required to access the resource." *** -Ben *** [bill] Many thanks! *** _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ---2129327256-357860453-1409962498=:54315 Content-Type: text/html; charset=us-ascii

Comments/responses inline below.

Updated  pre -16 copy available at 

text: https://drive.google.com/file/d/0B99YSkxS6ZefdHFKTUhodzY3cjA/edit?usp=sharing

You'll need to download the HTML to view it in a browser.





On Friday, September 5, 2014 10:05 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:


On Wed, 20 Aug 2014, Shawn M Emery wrote:

> This message officially starts the 3rd kitten Working Group Last Call
> for the following document:
>
> A set of SASL Mechanisms for OAuth
> http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-15
>
> The Working Group Last Call for this document starts today on Wednesday,
> August 20th and will end on Wednesday, September 3rd.

Oops, I'm late.  Sorry.

***
[bill] no worries
***

I'm neither a SASL expert nor an OAuth one, but I think I can get the
general sense of things here.  OAuth is already well established for
webapps, and there's a desire to repurpose it for authorizing access to
resources over non-http protocols, in particular protocols using SASL for
authentication.  This document, then, specifies how to represent the OAuth
messages inside SASL mechanisms, for messages between the parties
described in the OAuth terminology as the "client" and "resource server".
Since the OAuth messages are already specified, this is mostly just a
translation, along with specifying which pieces are required.

The most significant comment I have concerns section 3.2.2, the server
response to failed authentication.  I fear that it is under-specified, and
inconsistent with the example in section 4.3:

Section 3.2.2 leaves me wishing there was more detail.  I see that section
4.3 includes an example of this JSON object, but I think that more detail
is appropriate in a protocol specification.  Are all of the values always
going to be strings?  (Is the "OAuth 2 core specification" just RFC 6749?
If so, it's better to cite it by number.)  The IANA OAuth Extensions Error
Registry seems to give errors by name, e.g., "invalid_token".  Pulling up
RFC 6750, it seemse that when invalid_token is used, "the resource SHOULD
respond with the HTTP 401 (Unauthorized) status code".  But the example in
section 4.3 uses the string "401", not the JSON number, nor the string
form of the name!  This is very confusing.

***
[bill] Yep, this was wrong and 401 is being changed to "invalid_token" in the example.
***

Likewise, for the 'scope' named value, what are valid values?  Is there a
list of them somewhere?  Are they arbitrary, chosen by the application?
This needs to be specified.
The oauth-configuration named value is in better shape, as a URL is pretty
inherently a string, but that could still be made explicit.

***
[bill] Scope is defined in OAuth 2.0 and is a string, and it may be a list of space separated 
scope names.  There are no predefined scopes other than the blank/empty one..
***

My other comments are largely editorial; I have placed the more important
ones first and the stuff that's probably very minor at the end (after a
note).

However, it's a fairly significant issue that all of the IMAP examples do
not actually indicate they are for IMAP.  The SMTP exchanges are indicated
as such, which makes me suspect that originally only IMAP examples were
present, with the SMTP examples added later and the IMAP examples not
adjusted to reflect that they are only one class of example.  In
particular, this affects the top of sections 4.1, and 4.3.


***
[bill]  yep.  fixing.
***

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.
***

The C/S exchanges in section 4.3 seems to have lost the "Server Ready" and
"t0 CAPABILITY" lines that are present in the previous examples.

***
[bill]  yep.  fixing.
***

At the end of section 4.3, I would clarify that the required dummy
response (as seen in the example as "AQ==") is the base64 encoding of
%x01, which was mentioned earlier in the text.  This happens again at the
end of section 4.4, but may not need the additional clarification at the
second occurrence.

***
[bill]  yep.  fixing.
***

In section 5, under "Access tokens have a lifetime", I think that "The

client may request a new access token" should use the RFC 2119 "MAY".

***
[bill]  OK
***


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".
***

In section 3.1, for 'host', can we be more specific?  Is this a DNS name?
The name that would have been presented in an HTTP header if this was
being carried out over HTTP?  Vague text like this could lead to
interoperability issues.

***
[bill]  Changed to: "Contains the host name to which the client connected, in an HTTP context this is the value of the HTTP Host header.
***


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"
***

The first sentence of section 3.1.1 mentions the query string, which is
covered in the previous section (3.1); I think one should be moved so they
are in the same place.

***
[bill]  moved qs to the "reserved for future use section 3.1.1
***


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.
***


Editorial minutiae:

The phrase "or by allowing the third-party application to obtain access on
its own behalf", used in both the abstract and introduction, seems a
little confusing to me.  Is this just supposed to be differentiating
between flows where the user sees a prompt page from the authorization
server and flows where the user does not?


***
[bill] the difference is whether you're allowing FaceBook to access your mailbox, or whether its a desktop app like Thunderbird.
***

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."
***

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.
***

The text in the first paragraph of 3.1 about "carry the equivalent values
from an HTTP context [...]" could be more clear.  I might say that these
key/value pairs "take the place of the corresponding HTTP headers and
values to convey the information necessary to complete [...]".

***
[bill]  OK
***

I would probably replace "The following key/value pairs are defined in the
client response" with "The following keys and corresponding values are
defined in the client response", since the list is not of key/value pairs
but rather a list of keys, with the text content for each item being a
description of the value to be used for that key.

***
[bill]  sure, why not.
***

For 'auth', "for an equivalent HTTP OAuth authorization" is an awkward
phrasing, since "equivalent" is not really specified; I might use
something like "The payload that would be in the HTTP Authorization header
if this OAuth exchange was being carried out over HTTP".

***
[bill]  OK
***

Please insert a comma before "Figure" in the first sentence of the fourth
paragraph of section 1.

***
[bill]  and in the XML it's 'environment, <xref target="overview"/>'
***


On page 5, in the large paragraph, "a discovery mechanisms" is a
singular/plural mismatch.

***
[bill]  OK
***

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."
***


In section 3.2, I would replace "per the specification" with "according to
the specification".

***
[bill]  OK
***

In section 3.2.2 (last sentence), "presume an empty scope (unscoped token)
is needed" is a little odd; it might be better to say "should be used"
instead of "is needed".

***
[bill]  Now reads, "If the resource server provides no scope to the client then the client SHOULD presume an empty scope (unscoped token) is required to access the resource."
***


-Ben


***
[bill]  Many thanks!
***


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


 
---2129327256-357860453-1409962498=:54315-- From nobody Mon Sep 8 09:29:18 2014 Return-Path: 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 E4F8F1A88B8 for ; Mon, 8 Sep 2014 09:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.153 X-Spam-Level: X-Spam-Status: No, score=-3.153 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 FdR52yZ_NtrS for ; Mon, 8 Sep 2014 09:29:16 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA2E1A88AD for ; Mon, 8 Sep 2014 09:29:15 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-9a-540dd95a063a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 5A.A5.13180.A59DD045; Mon, 8 Sep 2014 12:29:15 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s88GTE0r012443; Mon, 8 Sep 2014 12:29:14 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s88GTCBf008787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Sep 2014 12:29:13 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s88GTCeM020843; Mon, 8 Sep 2014 12:29:12 -0400 (EDT) Date: Mon, 8 Sep 2014 12:29:11 -0400 (EDT) From: Benjamin Kaduk To: Tom Yu In-Reply-To: Message-ID: References: <20140905195755.12365.12570.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixG6nrht9kzfEYPcsJoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr43THbLaCa8wVc56eYWlg/MLUxcjJISFgItH0/gk7hC0mceHe erYuRi4OIYHZTBJ3mg+wQjgbGCU+zZzCDuEcZJKY/PgEWLuQQL3Eq2/bmUFsFgEtib5T38Bs NgEViZlvNrKB2CICkhLHnpwHizMLCEusPzcDzBYWcJRY0PUfzOYU0JOYefElmM0LFL/RsI0Z Yn6yxL9ly8DOExXQkVi9fwoLRI2gxMmZT1ggZmpJLJ++jWUCo+AsJKlZSFILGJlWMcqm5Fbp 5iZm5hSnJusWJyfm5aUW6Zrp5WaW6KWmlG5iBIeli/IOxj8HlQ4xCnAwKvHwclzmCRFiTSwr rsw9xCjJwaQkylt5gTdEiC8pP6UyI7E4I76oNCe1+BCjBAezkgjv08tAOd6UxMqq1KJ8mJQ0 B4uSOO9ba6tgIYH0xJLU7NTUgtQimKwMB4eSBG/mDaBGwaLU9NSKtMycEoQ0EwcnyHAeoOH7 QWp4iwsSc4sz0yHypxiNOVqa3vYycazr/NbPJMSSl5+XKiXOu+Y6UKkASGlGaR7cNFhqecUo DvScMG8nyEAeYFqCm/cKaBUT0KpJwWCrShIRUlINjGxim5Qful86lvjj6/6jkWtEKgqfTmr+ 4jPl1sTyG7biN5SN4h54fItZkdyub3c7+1uZyWq3L/z+b2Zc9sgzTEg+4v1g+g3JUtbn/7eq H1N3fsx3aPOskoWZE3ulnSojU6amH9gjYq/JuCnetJsxJ6Olext3R3TGu18MXm/W8Akc8m1Z e8SyU4mlOCPRUIu5qDgRAMNba/8IAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ZubJeGqXGwFH1F3qJ45ns3O6efY Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-krb-wg-cammac-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 16:29:18 -0000 On Fri, 5 Sep 2014, Tom Yu wrote: > This revision makes some editorial wording changes in responses to > feedback. Thanks for the updates. Aside from the extra "be" (in "be use") that Simo pointed out on IRC, I am still not sure that I understand the last paragraph of the security considerations. That is, I don't see how using the S4U2Proxy extension and having policy disallow the use of S4U2Proxy would result in similar security properties. -Ben From nobody Mon Sep 8 09:59:11 2014 Return-Path: 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 C2B141A8903 for ; Mon, 8 Sep 2014 09:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 7qCX1MvPGHyn for ; Mon, 8 Sep 2014 09:58:57 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 56E7C1A88FC for ; Mon, 8 Sep 2014 09:58:55 -0700 (PDT) X-AuditID: 12074422-f79436d000000c21-ea-540de04e7445 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 2F.0B.03105.E40ED045; Mon, 8 Sep 2014 12:58:54 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s88Gwm15010101; Mon, 8 Sep 2014 12:58:49 -0400 Received: from [18.101.8.96] (vpn-18-101-8-96.mit.edu [18.101.8.96]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s88GwlNB020302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Sep 2014 12:58:48 -0400 Message-ID: <540DE046.2020709@mit.edu> Date: Mon, 08 Sep 2014 12:58:46 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Benjamin Kaduk , Tom Yu References: <20140905195755.12365.12570.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrev3gDfE4MBfM4ujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr491C9oIezopTMzcxNjBOZO9i5OSQEDCR2Lz6CCuELSZx4d56 ti5GLg4hgdlMErdXf2aHcDYwSjRfecAI4Rxgkjj+swkow8HBK6AmMXWfN0g3i4CqxNTu22BT 2QSUJdbv38oCYosKhEg0tfawgdi8AoISJ2c+YQFpFRGwlDi60REkzCwgLHFh+16wI4QFHCUW dP1nhlg1k1Fi0cpjjCAJTgEniQdTNrNBNOhJ7Lj+ixXClpdo3jqbeQKj4CwkK2YhKZuFpGwB I/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2MoFBld1HawfjzoNIhRgEORiUe Xo7LPCFCrIllxZW5hxglOZiURHk/3OENEeJLyk+pzEgszogvKs1JLT7EKMHBrCTC+/QyUI43 JbGyKrUoHyYlzcGiJM771toqWEggPbEkNTs1tSC1CCYrw8GhJMFrcR+oUbAoNT21Ii0zpwQh zcTBCTKcB2i4P0gNb3FBYm5xZjpE/hSjLse6zm/9TEIsefl5qVLivCvvARUJgBRllObBzYGl mFeM4kBvCfPGgoziAaYnuEmvgJYwAS2ZFAy2pCQRISXVwGi8aeHRgw9+7Nb/aciRGVmfpq7S XvT91LLd3wVKlvUmXVYOmMLqGnP5Affm6zWtrC/tF00WmXD4/bnbkkE77W8Jmy1R4CyfMW0H z8PHBXPOGldM+nV8vaqmVH3LmokH/85TDnvhncYlf8A0T6ymP8lo8s+9Qnv055/doHJ3fkrC Sa0tPkcOzLZTYinOSDTUYi4qTgQAjOqnegwDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/kFbO10Cc34v-epn8BHzzlGxjISA Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-krb-wg-cammac-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 16:59:00 -0000 On 09/08/2014 12:29 PM, Benjamin Kaduk wrote: > Aside from the extra "be" (in "be use") that Simo pointed out on IRC, I am > still not sure that I understand the last paragraph of the security > considerations. That is, I don't see how using the S4U2Proxy extension > and having policy disallow the use of S4U2Proxy would result in similar > security properties. I tihnk the extra "be" is supposed to be "not" or "never". I suggest changing: The KDC MAY create a new CAMMAC from an existing CAMMAC lacking a kdc-verifier if it is inserting the new CAMMAC into a service ticket for the same service principal as the ticket that contained the existing CAMMAC, and if all of the realm's KDCs are configured to reject S4U2Proxy requests made by that service principal. to instead say, "... as the ticket that contained the existing CAMMAC, but MUST NOT place a kdc-verifier in the new CAMMAC." This is simpler to implement. By not putting a kdc-verifier in the new CAMMAC, we don't risk treating the new CAMMAC contents as definitively KDC-originated for a subsequent S4U2Proxy request if the policy changes. From nobody Mon Sep 8 10:00:19 2014 Return-Path: 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 61C1C1A890B for ; Mon, 8 Sep 2014 10:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.954 X-Spam-Level: X-Spam-Status: No, score=-3.954 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 K1-pONbOm8hE for ; Mon, 8 Sep 2014 10:00:15 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B85E1A8904 for ; Mon, 8 Sep 2014 10:00:15 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-ab-540de09d5a99 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 03.A4.27750.D90ED045; Mon, 8 Sep 2014 13:00:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s88H0DUY016833; Mon, 8 Sep 2014 13:00:13 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s88H0BGl020788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Sep 2014 13:00:12 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s88H0AiI024696; Mon, 8 Sep 2014 13:00:10 -0400 (EDT) Date: Mon, 8 Sep 2014 13:00:10 -0400 (EDT) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <1409962498.54315.YahooMailNeo@web142804.mail.bf1.yahoo.com> Message-ID: References: <52AE9A65.1010700@oracle.com> <53F53D1F.7010305@oracle.com> <1409962498.54315.YahooMailNeo@web142804.mail.bf1.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1275471049-1410195610=:21571" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IRYrdT1533gDfEYIGWxdHNq1gsvnVdZ3Zg 8liy5CeTx6xZh5kCmKK4bFJSczLLUov07RK4Mnpf72EuuKNe8XfZTJYGxoPyXYycHBICJhI7 fr9jhbDFJC7cW8/WxcjFISQwm0liV+NssISQwAZGiQf7OCHsg0wSm/dVQNj1EjsvPGMBsVkE tCR6Fj1hB7HZBFQkZr7ZCDSIg0NEQF2i+bs3SJgZyPx25g0jiC0sYCtxfF0b2HhOAU+Jwxfe MIOU8wo4SpzutYQ4YRejxN/jy8HGiwroSKzePwXM5hUQlDg58wkLSD2zQKDEkv/RExgFZyHJ zELIzAJbrCvxZtVBJghbW+L+zTa2BYwsqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3QN9XIzS/RS U0o3MYLCmVOSZwfjm4NKhxgFOBiVeHg5LvOECLEmlhVX5h5ilORgUhLl/XCHN0SILyk/pTIj sTgjvqg0J7X4EKMEB7OSCO/Ty0A53pTEyqrUonyYlDQHi5I471trq2AhgfTEktTs1NSC1CKY rAwHh5IEb9t9oEbBotT01Iq0zJwShDQTByfIcB6g4RNBaniLCxJzizPTIfKnGHU51nV+62cS YsnLz0uVEuddeQ+oSACkKKM0D24OLA29YhQHekuYNxZkFA8whcFNegW0hAloyaRgsCUliQgp qQbGreH+wj/5TrIYMcoufjBRa5X4/M59v9XutO3WsuMNDD606L1dnO3hwClvdin/4rjyJPxA 9umupCP7n7h8eiQ56euL3vL2i95VF4oORb7lUXXvWOo7a5PGTzfPW2WP9hokBy+xzMuKar2g 97T8U7vtLoNpZYxfZzycYry9cpPXsRlva3Y1rEraq8RSnJFoqMVcVJwIAMowpt8eAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/xqiGX6jvzuT3P3BaO_GnAFv5D8o Cc: "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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 17:00:17 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1275471049-1410195610=:21571 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 5 Sep 2014, Bill Mills wrote: > On Friday, September 5, 2014 10:05 AM, Benjamin Kaduk wro= te: > > > 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).=A0 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 o= f > IMAP the resource server may assert the resource owner's email address to > the IMAP server for usage in an email-based application.".=A0 But isn't t= he > IMAP server the resource server here?=A0 Maybe it is the authorization > server which is making this assertion? > > *** > [bill] =A0it'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"= =2E > *** 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.=A0 I'm uncertain which sort of requests do require ke= yed > message digests, so I don't really have any suggestions. > > *** > [bill] =A0Changed 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 som= e > reason to think that doing so is possible.=A0 Is there prior art, or some > other specification for a similar thing that gives an example?=A0 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] =A0OAuth 1.0a tokens may well (and commonly have in some implement= ations) > either carried or has access to the client identity. > > For the question of whether both identities can be communicated to the ap= p, it > would be a new capability you'd have to add to the SASL implementation yo= u're > using. =A0Not herculean, but not trivial if you're going to patch somethi= ng 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.=A0 It is probably best to add a qualifier to at least o= ne > occurrence. > > *** > [bill]=A0IIRC this is lifted from the SASL spec itself. =A0That said, del= eting the > second usage seems to do the trick, "=A0The framework also provides a pro= tocol for > securing subsequent=A0exchanges 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."=A0 It would be nice to say > something about why. > > *** > [bill] Now there's a fun topic. =A0There are folks that assert that allow= ing in > band discovery if the password grant is in play might lead to an effectiv= e > phishing attack. =A0Other's disagree. =A0No one hated the current languag= e. =A0I'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] =A0no, 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 m= ay be > empty." > *** Ah, I see now. Sorry for the confusion. -Ben ---559023410-1275471049-1410195610=:21571-- From nobody Mon Sep 8 11:28:52 2014 Return-Path: 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 9A3341A029D for ; Mon, 8 Sep 2014 11:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ZOS89uXS8Bpa for ; Mon, 8 Sep 2014 11:28:49 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55121A02A0 for ; Mon, 8 Sep 2014 11:28:48 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-5c-540df55f36a0 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 1C.6C.27750.F55FD045; Mon, 8 Sep 2014 14:28:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s88ISkAe023376; Mon, 8 Sep 2014 14:28:47 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s88ISiFg023276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Sep 2014 14:28:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s88ISivs005753; Mon, 8 Sep 2014 14:28:44 -0400 (EDT) Date: Mon, 8 Sep 2014 14:28:43 -0400 (EDT) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: <540DE046.2020709@mit.edu> Message-ID: References: <20140905195755.12365.12570.idtracker@ietfa.amsl.com> <540DE046.2020709@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrRv/lTfEYPoyDYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY/GTdqaCfVwVW1efZ2tgnMjRxcjJISFgIjHzZR8LhC0mceHe erYuRi4OIYHZTBLX191hhHA2MErc/t4K5Rxkkpg8aQI7SIuQQL3Ej4VtjCA2i4CWxOq+/2Cj 2ARUJGa+2cgGYosIKEr8XvkWrIYZqObR4qVMILawgKPEgq7/zCA2p4C6RPuSw0A1HBy8QPF1 S5Mhxm9hlDi7UxnEFhXQkVi9fwrYeF4BQYmTM5+wwIxcPn0bywRGwVlIUrOQpBYwMq1ilE3J rdLNTczMKU5N1i1OTszLSy3SNdTLzSzRS00p3cQIDkpJnh2Mbw4qHWIU4GBU4uHluMwTIsSa WFZcmXuIUZKDSUmUd9tH3hAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxPLwPleFMSK6tSi/Jh UtIcLErivG+trYKFBNITS1KzU1MLUotgsjIcHEoSvKZfgBoFi1LTUyvSMnNKENJMHJwgw3mA hueA1PAWFyTmFmemQ+RPMepyrOv81s8kxJKXn5cqJc47B6RIAKQoozQPbg4smbxiFAd6S5jX GKSKB5iI4Ca9AlrCBLRkUjDYkpJEhJRUA2PKj/UWqvGtcvx+Cz0+n3u+OJu/kvlHbqx7kMo/ ryjhTU4Pru7sUBeRO8PpcahOa06a5MkVJyxe/utkdZCdaHjnZsZ7kTWRdleUpW8y5V9gSFq6 Lmg662fPrdO2rg+wF31wOq92dY0H637elFeRBzhnLl76979dDEePR3KV/ov2SMnvOcv+cSmx FGckGmoxFxUnAgARnKrNAQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/H2E8sUvqDKTj7uQT7hzruN_emtk Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-krb-wg-cammac-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 18:28:50 -0000 On Mon, 8 Sep 2014, Greg Hudson wrote: > On 09/08/2014 12:29 PM, Benjamin Kaduk wrote: > > Aside from the extra "be" (in "be use") that Simo pointed out on IRC, I am > > still not sure that I understand the last paragraph of the security > > considerations. That is, I don't see how using the S4U2Proxy extension > > and having policy disallow the use of S4U2Proxy would result in similar > > security properties. > > I tihnk the extra "be" is supposed to be "not" or "never". Yes, I think it makes more sense with that substitution. > I suggest changing: > > The KDC MAY create a new CAMMAC from an existing CAMMAC > lacking a kdc-verifier if it is inserting the new CAMMAC into a > service ticket for the same service principal as the ticket that > contained the existing CAMMAC, and if all of the realm's KDCs are > configured to reject S4U2Proxy requests made by that service > principal. > > to instead say, "... as the ticket that contained the existing CAMMAC, > but MUST NOT place a kdc-verifier in the new CAMMAC." This is simpler > to implement. By not putting a kdc-verifier in the new CAMMAC, we don't > risk treating the new CAMMAC contents as definitively KDC-originated for > a subsequent S4U2Proxy request if the policy changes. That seems reasonable to me. -Ben From nobody Mon Sep 8 13:32:22 2014 Return-Path: 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 ; 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 ; 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 ; 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> <1409962498.54315.YahooMailNeo@web142804.mail.bf1.yahoo.com> Message-ID: <1410208338.40585.YahooMailNeo@web142804.mail.bf1.yahoo.com> Date: Mon, 8 Sep 2014 13:32:18 -0700 From: Bill Mills To: Benjamin Kaduk In-Reply-To: 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" 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 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 20:32:22 -0000 ---2129327256-1876670983-1410208338=:40585 Content-Type: text/plain; charset=us-ascii Changed to your text on the host/port thing. Thanks again! On Monday, September 8, 2014 10:00 AM, Benjamin Kaduk wrote: On Fri, 5 Sep 2014, Bill Mills wrote: > On Friday, September 5, 2014 10:05 AM, Benjamin Kaduk 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 ---2129327256-1876670983-1410208338=:40585 Content-Type: text/html; charset=us-ascii
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


---2129327256-1876670983-1410208338=:40585-- From nobody Wed Sep 10 13:03:48 2014 Return-Path: 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 D039B1A879D; Wed, 10 Sep 2014 13:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 W5lZRCOEm1_d; Wed, 10 Sep 2014 13:03:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 841701A0180; Wed, 10 Sep 2014 13:03:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140910200340.31115.18871.idtracker@ietfa.amsl.com> Date: Wed, 10 Sep 2014 13:03:40 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/cBTYknoDtKh0gTnacqzwqIZCIE0 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-krb-wg-cammac-10.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 20:03:42 -0000 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 Working Group of the IETF. Title : Kerberos Authorization Data Container Authenticated by Multiple MACs Authors : Simo Sorce Tom Yu Thomas Hardjono Filename : draft-ietf-krb-wg-cammac-10.txt Pages : 9 Date : 2014-09-10 Abstract: Abstract: This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-krb-wg-cammac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-cammac-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 10 13:16:40 2014 Return-Path: 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 617761A916D for ; Wed, 10 Sep 2014 13:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Mc7AKb1qFRvd for ; Wed, 10 Sep 2014 13:16:38 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F521A9147 for ; Wed, 10 Sep 2014 13:16:36 -0700 (PDT) X-AuditID: 12074424-f79346d000004923-9e-5410b1a2528d Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 88.4E.18723.2A1B0145; Wed, 10 Sep 2014 16:16:34 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s8AKGYuA002032 for ; Wed, 10 Sep 2014 16:16:34 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8AKGXDp030433 for ; Wed, 10 Sep 2014 16:16:34 -0400 From: Tom Yu To: References: <20140910200340.31115.18871.idtracker@ietfa.amsl.com> Date: Wed, 10 Sep 2014 16:16:32 -0400 In-Reply-To: <20140910200340.31115.18871.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Wed, 10 Sep 2014 13:03:40 -0700") Message-ID: Lines: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUixG6nortoo0CIwa4ma4ujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr48PmKawFxxgrDr2ex9bAuJixi5GTQ0LAROLktmvsELaYxIV7 69m6GLk4hARmM0lcXLKIEcI5ziix5F0jM4TTxCRx/PEpsHY2AWmJ45d3MYHYIgKiErO3vGIB sYUFLCRuNDxjBbGFBBwlLqybAWazCKhKPP/7mAlkEKfABEaJU3OngA3iFdCVuL/zFxuIzSPA IfFsRQ87RFxQ4uTMJ2BDmQW0JG78e8k0gZF/FpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT 8/JSi3TN9XIzS/RSU0o3MYIDzUVlB2PzIaVDjAIcjEo8vAK1/CFCrIllxZW5hxglOZiURHnv rBUIEeJLyk+pzEgszogvKs1JLT7EKMHBrCTCO28NUI43JbGyKrUoHyYlzcGiJM676QdfiJBA emJJanZqakFqEUxWhoNDSYL31AagRsGi1PTUirTMnBKENBMHJ8hwHqDhT0FqeIsLEnOLM9Mh 8qcYLTn2tL/sZeJoaXoLJNd1futnEmLJy89LlRLnvQXSIADSkFGaBzcTljheMYoDvSjM+xKk igeYdOCmvgJayAS08KAxP8jCkkSElFQDY/+35G1HsvkZSk//Vfr9krle1S20/0lwwnlhyfWS Tfv5nqjqsvS6SjkysH9b7Nk8szlWTdQ1sk+2+1Cu3K85hcb8gf0p8Xmau6tm6dyvUjlmmMtb Yt/649uUefUKyduZemuSXovxOhxPU/ptOM3Ly3aRmsUFM95FM8TPzHLw+mDMwRK1SViJpTgj 0VCLuag4EQDOABY39wIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/zbrUsBzcTOSbsednQtTz1FtU-3Q Subject: Re: [kitten] I-D Action: draft-ietf-krb-wg-cammac-10.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 20:16:39 -0000 I believe this incorporates all the feedback sent in response to -09, and adds new Security Considerations text about the service principal binding issue pointed out by Sam and analyzed by Greg. From nobody Thu Sep 11 14:00:53 2014 Return-Path: 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 2BE171A0026 for ; Thu, 11 Sep 2014 14:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 sKdPe68oJTpT for ; Thu, 11 Sep 2014 14:00:48 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81451A0185 for ; Thu, 11 Sep 2014 14:00:46 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-5e-54120d7dd106 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 43.D4.27750.D7D02145; Thu, 11 Sep 2014 17:00:45 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s8BL0i13013167; Thu, 11 Sep 2014 17:00:44 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8BL0ghU012244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Sep 2014 17:00:43 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s8BL0gIV008386; Thu, 11 Sep 2014 17:00:42 -0400 (EDT) Date: Thu, 11 Sep 2014 17:00:41 -0400 (EDT) From: Benjamin Kaduk To: "Nordgren, Bryce L -FS" In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E68DEFD@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: References: <20140214214526.22958.30728.idtracker@ietfa.amsl.com> <82E7C9A01FD0764CACDD35D10F5DFB6E68DE37@001FSN2MPN1-045.001f.mgd2.msft.net> <1392484918.22754.5.camel@willson.li.ssimo.org> <82E7C9A01FD0764CACDD35D10F5DFB6E68DEFD@001FSN2MPN1-045.001f.mgd2.msft.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrVvLKxRi0HNJwOLqm5+sFkc3r2Jx YPK4/eYsi8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKWHHvPWtCkXXHhykTGBsaDSl2MnBwSAiYS Z1dvY4KwxSQu3FvPBmILCcxmktgwg7WLkQvI3sgocWvhZGYI5xCTxKSO44wQTgOjxNQvq9lB WlgEtCVeTJ3LCGKzCahIzHyzEWyUiIChRPfSY2BxZgF1iW9n3oDZwgKOEpOf/gWr4RSIkPg1 /TBQnIODFyi+YnEOxPxuJommlglg9aICOhKr909hAbF5BQQlTs58wgIxU0ti+fRtLBMYBWch Sc1CklrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11AvN7NELzWldBMjOFQleXYwvjmodIhR gINRiYe3gkUwRIg1say4MvcQoyQHk5Io7wZWoRAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzO C4HKeVMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeJ14gIYKFqWmp1ak ZeaUIKSZODhBhvMADe/nAqrhLS5IzC3OTIfIn2LU5VjX+a2fSYglLz8vVUqct5kbqEgApCij NA9uDizFvGIUB3pLmFcFZB0PMD3BTXoFtIQJaMlBY36QJSWJCCmpBsZyvp6Pe1UskuZMPzHV 8p3FQfknuypmOH/TNu0Uv1J2ZNoF487Ec84btRcvXvP8sxkr08u8ybq8h2wnhPj7GW+rt508 a01i7AH7lT/qVtv/fPbFvLE3zF2Ut+aly5sm8xUvfs1/cLPwwLX3hiKpOQt3/ThgtGp7ToAO pyvTDLWVB3sYJt59Gr5UiaU4I9FQi7moOBEA+e0zBgwDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/KrfctMS8N3gPcBueaPlNrlqKA-0 Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-iakerb-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 21:00:51 -0000 My apologies for the delay in responding ... hopefully the relevant thoughts have not since been forgotten. On Sat, 15 Feb 2014, Nordgren, Bryce L -FS wrote: > -- Comments on draft-ietf-kitten-iakerb-01.txt -- > > Comment 5: This approach may be summarized as a "message relay" from > client to app to KDC. Compare and contrast this approach with a "ticket > relay", where a strawman (fake) KDC requests and relays proxiable and/or > forwardable tickets from the "real" KDC on the client's behalf, using > its own identity. Outline the tradeoffs in terms of compatibility with > deployed Krb5 clients and KDCs, amount of "extension" required, types of > situations to which the approach applies, state information required at > the relay point, and security implications. Make the case that "message > relay" is a superior strategy, and show that alternatives were > considered and rejected. It's not really clear to me that this sort of comparison is necessary. If I understand correctly, this proposed strawman fake KDC would also need to be in the DMZ, with network connectivity to both the real KDC and the client. The real KDC would need some way to authorize the fake KDC's principal as permitted to get tickets for (arbitrary? particular?) client principals. Then one considers whether the fake KDC gets a copy of the session keys for those tickets. If it does, how does it securely transmit those back to the client, given that the client is not really authenticated yet. If it doesn't, then what it is sending back to the client is fundamentally equivalent to a KDC-REP, at which point we've degenerated back to the message-passing paradigm. Maybe I'm missing something, but is there even a real strawman to prop up here? > Comment 6: This message relay approach intentionally establishes many > persistent "men in the middle", potentially piggybacking on every > kerberized app you have. Note this in the security considerations. I guess we could mention that. It doesn't matter, because kerberos is designed to run on the open internet anyway so all the interesting bits are encrypted. > -- Technical discussion about draft-ietf-kitten-iakerb-01.txt -- > > Comments 2 and 3 boil down to: should an IAKERB enabled Kerberos client > keep track of KDC connection failures so that it can try and get tickets > when it later discovers a path to the KDC? Conversely, should an IAKERB > enabled Kerberos client keep track of proxies so that it doesn't just > give up when it can't contact the KDC? Details below. > > 2nd comment details...Proxies may be asked to acquire tickets for other They may be, yes. That is not the intended use case, though. (We should still talk about any relevant security considerations, of course.) > services, and the order in which services are accessed by clients seems > to matter. (Person A is at home, accessing web services "X" and "Y". > Both X and Y are kerberized. X is IAKERB enabled and Y is not. If A > connects to X first, it SHOULD request a ticket for Y using X once it > discovers that Y isn't IAKERB enabled. If A connects to Y first, it has > no TGT nor a means of getting one, so Y must behave like a gateway. > After A connects to X, and "discovers" a pathway to its KDC, should it > then request tickets for Y? How is Y informed that A now has a ticket? ) > This may not require much in the way of verbage, but I think it probably > should be included. The proposed improvement is to eliminate gatewaylike > behavior. Since this is not the intended use case of the document, I don't think we need to cover it at all, other than any security considerations this client workflow might entail (which I have not yet attempted to analyze). If at some later date, someone has a use case for this client workflow, then we can revisit the issue, but it seems like it's really an implementation issue, anyway. This workflow feels quite strange anyway, since the GSSAPI security context tokens are nominally working towards a single authentication event, and this workflow is abusing the IAKERB proxy to exchange messages which are relevant to a different authentication event. I don't think we necessarily need to forbid it at the present time, though. > 3rd comment details...what if the service also does not have a path to > the KDC? In the VPN example above, I log in to my host using cached > credentials. Once I connect to an IAKERB proxy (VPN server), should the > host try to grab a valid ticket? I don't think I follow this question, but I'll take a couple of stabs at it. If the GSS acceptor ("service") does not have a network path to the KDC, then the IAKERB mechanism must fail; there is simply no way for the initiator to get its desired KDC responses. There is no provision for another layer of network proxying. If you log onto a host by validating against cached credentials, and then later (after the cached credentials are expired, say) go to authenticate to a remote service over the IAKERB mechanism and obtain a new TGT during that GSS negotiation loop, I would expect the new TGT to be retained in your krb5 credentials cache on the original host. Even if you already had a TGT and were just using IAKERB to get a service ticket, I would still expect it to be cached. I would not expect the mechanism to proactively go and get a service ticket for the local host's service principal and cache that. -Ben From nobody Fri Sep 12 08:54:30 2014 Return-Path: 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 22EAD1A02E8 for ; Fri, 12 Sep 2014 08:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3ZN9Qfm4kEkw for ; Fri, 12 Sep 2014 08:54:26 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C1A1A0162 for ; Fri, 12 Sep 2014 08:54:26 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-f8-541317313a5c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 1C.A8.13180.13713145; Fri, 12 Sep 2014 11:54:25 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s8CFsOA0017069; Fri, 12 Sep 2014 11:54:25 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8CFsMQD016409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Sep 2014 11:54:24 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s8CFsMtw002442; Fri, 12 Sep 2014 11:54:22 -0400 (EDT) Date: Fri, 12 Sep 2014 11:54:22 -0400 (EDT) From: Benjamin Kaduk To: Tom Yu In-Reply-To: Message-ID: References: <20140910200340.31115.18871.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixCmqrWsoLhxisOygjMXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfL+KtaCWUwVf762sjYw3mXsYuTkkBAwkVh8chorhC0mceHe erYuRi4OIYHZTBJf/n1mhHA2Mkq82/aBFcI5xCSx63YTO4TTwChx+etLoAwHB4uAtsSUbl+Q UWwCKhIz32xkA7FFBCQljj05zwxiMwsIS6w/NwPMFhZwlFiwZwULiM0poCex8/EGJpAxvEDx t2sjQcJCAskSM+e+BbtOVEBHYvX+KWDlvAKCEidnPmGBGKklsXz6NpYJjIKzkKRmIUktYGRa xSibklulm5uYmVOcmqxbnJyYl5dapGuml5tZopeaUrqJERSU7C7KOxj/HFQ6xCjAwajEw1vB IhgixJpYVlyZe4hRkoNJSZT3HLNwiBBfUn5KZUZicUZ8UWlOavEhRgkOZiURXkVRoBxvSmJl VWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgQvtxhQo2BRanpqRVpmTglCmomD E2Q4D9BwL5Aa3uKCxNzizHSI/ClGY46Wpre9TBzrOr/1Mwmx5OXnpUqJ8xaAlAqAlGaU5sFN gyWWV4ziQM8J874GuZYHmJTg5r0CWsUEtOrdHCGQVSWJCCmpBsbDBTXrdTc+SpiW1mYmtuFi 40Nh5xVz1l/zcTznOelPeceT+kjBx8reH/pzjVPO/+3ym5xZdLeiS2JRlsFeOeZrSzImLDkq E7L7wJozPr2fXvuYq6Sfr2s6OO+o+YZNmlpCZZdnTLLuWbI310zY7OKJ0DZJt4Wrrkv9MOhI USquWiplEXT6TqESS3FGoqEWc1FxIgDnwjTJBwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/dpL_iYldS_UkrLWLLTi9IzkhAAQ Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-krb-wg-cammac-10.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 15:54:28 -0000 On Wed, 10 Sep 2014, Tom Yu wrote: > I believe this incorporates all the feedback sent in response to -09, > and adds new Security Considerations text about the service principal > binding issue pointed out by Sam and analyzed by Greg. Thanks for the updates, Tom. -Ben From nobody Tue Sep 16 16:45:25 2014 Return-Path: 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 661C61A004D; Tue, 16 Sep 2014 16:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 0OwO0NxtSSJs; Tue, 16 Sep 2014 16:45:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB50D1A01F7; Tue, 16 Sep 2014 16:45:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140916234519.22685.47362.idtracker@ietfa.amsl.com> Date: Tue, 16 Sep 2014 16:45:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/dkCNGXTOmqth4Lan2TdfB9BNVg0 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 23:45:21 -0000 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 Working Group of the IETF. Title : A set of SASL Mechanisms for OAuth Authors : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-16.txt Pages : 22 Date : 2014-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) 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 shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term 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-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 16 17:04:15 2014 Return-Path: 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 3D1761A03F1 for ; Tue, 16 Sep 2014 17:04:13 -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=[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, MISSING_HEADERS=1.021, 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 KNCzHCenvVci for ; Tue, 16 Sep 2014 17:04:10 -0700 (PDT) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) (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 7CEF81A00AE for ; Tue, 16 Sep 2014 17:04:10 -0700 (PDT) Received: from [66.196.81.173] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 17 Sep 2014 00:04:09 -0000 Received: from [98.139.212.207] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 17 Sep 2014 00:04:09 -0000 Received: from [127.0.0.1] by omp1016.mail.bf1.yahoo.com with NNFMP; 17 Sep 2014 00:04:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 739512.82850.bm@omp1016.mail.bf1.yahoo.com Received: (qmail 36521 invoked by uid 60001); 17 Sep 2014 00:04:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1410912249; bh=3JZZKlvVHvPDCCv16CalGWm3Rep2+rS/Iax0Jke/f0Q=; h=References:Message-ID:Date:From:Reply-To:Subject:Cc:In-Reply-To:MIME-Version:Content-Type; b=gNnzlJnbVE/DqIPY0EwXe5VspHfklWJGjJKaj8i7itsZVEAb56NyA9FESup/WswWdHNijLmvxh8umRNYOc9o/u8+fS5kZZheO/STnCbNXlW+C30rR/OVIB2lrFnN8aOKnK79Z+z33jNSPVqQn21CFRjjGf0+BCUq+6f11QeSp8I= X-YMail-OSG: Qc.w.dgVM1nuQDuaNINBSj2Ya8DOmlKZda3E_CpxBZdnIsB rCQE2QWIsKmQCqX0k1.qGoh0bY1YCP98cveTpE2t0CbQ4A2F35Q0Oq8FqjTa 06tjUsH00zQ9MElbmjH2So3PJbBgLhSvG9J4ngSC.KK7.bQiQHMHV99iCtjU 1YoT4R5SMlxdAEa5DMoSVjYeipVPGYsyDC_cXvXUnwt9n.dxxGdVCVQi4j2_ 9hGfvv27.cACfrxKgwewGx5C14iiw54wxQYc8l.r4bsyD9TfKyG4cY_9qsDQ qd_iVVCGqso9OKPl9SW7SQd1iR6nZNznGm9WcSEIpArIRd9EXbHfHS5IA1Bs L_cZiDCAwDJU6erXs3yOuaGn7.OQAlLQezMbWktQBzeDuUIavzeoF.2jyUAW AQd3s.WXZVdIMzVqraWhk16CXTHa8F56lZu09SKyGsuDQV32LlQNcZM6yvei Bpd0is6hWXzyXSAjgaq5ZT5eABYgmLY.IBGqZudAcS3Cpa.0EQOrCk0x98h6 7mi3gKNfeZvyo0eMufO3Ch6gPATA10lg0KNpxVMlTINhB3oJ56m16LH8EwvM rYcsa50Q0_qoh72d_ga3O1qqfzlxaDx2dqAaX0dbJCr_8iNhhrlNi Received: from [167.220.24.156] by web142801.mail.bf1.yahoo.com via HTTP; Tue, 16 Sep 2014 17:04:09 PDT X-Rocket-MIMEInfo: 002.001, LTE2IGlzIHN1Ym1pdHRlZCwgYW5kIHRoZXJlIGlzIG9uZSBzdWdnZXN0ZWQgY2hhbmdlICh3aGljaCBJIHdhcyBzdXBwb3NlZCB0byBoYXZlIGFkZGVkIGluIGFscmVhZHkgYW5kIGJsZXcgaXQpLCB3aGljaCBpcyB0byByZXBsYWNlIHNlY3Rpb24gMy4yLjIgd2l0aCB0aGUgdGV4dCAoZmFydGhlcikgYmVsb3cuCgpNeSBjb21tZW50cyBvbiB0aGUgc3VnZ2VzdGVkIHRleHQ6CgojMSkgIEkgZG9uJ3QgdGhpbmsgdGhlIGR5bmFtaWMgcmVnaXN0cmF0aW9uIHN0dWZmIGlzIGJha2VkIGVub3VnaCB0byB3YW50IHQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <20140916234519.22685.47362.idtracker@ietfa.amsl.com> Message-ID: <1410912249.50514.YahooMailNeo@web142801.mail.bf1.yahoo.com> Date: Tue, 16 Sep 2014 17:04:09 -0700 From: Bill Mills Cc: "kitten@ietf.org" In-Reply-To: <20140916234519.22685.47362.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/L7RrrBcTKlwmeiSPvx8xzfyxBos Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 00:04:13 -0000 -16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below. My comments on the suggested text: #1) I don't think the dynamic registration stuff is baked enough to want to pull that in to the "oauth-configuration" definition. I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations. #2) I didn't really want to make all of the OpenID elements required but I don't have a strong opinion here, my initial intent was to use the OpenID Discovery format as an existing format to be re-used here but leave it flexible. #3) I am against recommending scope names at all in any way. I would not include the last sentence of paragraph 5 below and strike the scope names. New text for 3.2.2: ----------------------- 3.2.2. Server Response to Failed Authentication For a failed authentication the server returns a JSON [RFC4627] formatted error result, and fails the authentication. The error result consists of the following values: status (REQUIRED): The authorization error code. Valid error codes are defined in the IANA "OAuth Extensions Error Registry" specified in the OAuth 2 core specification. scope (OPTIONAL): An OAuth scope which is valid to access the service. This may be empty which implies that unscoped tokens are required, or a scope value. If a scope is specified then a single scope is preferred, use of a space separated list of scopes is NOT RECOMMENDED. oauth-configuration (OPTIONAL): The URL for a document following the OpenID Provider Configuration Information schema, as described in Section 3 of the OpenID Connect Discovery [OpenID.Discovery], that is appropriate for the user. The server MAY return different URLs for users from different domains and a client MUST NOT cache a single returned value and assume it applies for all users/domains that the server suports. The returned discovery document MUST have all data elements required by the OpenID Connect Discovery specification populated. In addition, the discovery document MUST contain the 'registration_endpoint' element to learn about the endpoint to be used with the Dynamic Client Registration protocol [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of parameters necessary for the OAuth protocol exchange to function. Authorization servers MUST implement the authorization code grant and other grant types MAY be supported. Furthermore, authorization servers MUST implement the ability to issue refresh tokens for use with native applications to benefit from an abbreviated protocol exchange. The use of the 'offline_access' scope, as defined in [OpenID.Core] is RECOMMENDED to give clients the capability to explicitly request a refresh token. If the resource server provides a scope (as part of the element of the configuration payload) then the client MUST always request scoped tokens from the token endpoint. This specification RECOMMMENDs the use of the following scopes: imap: The 'imap' scope value is used to interact with IMAP mail servers. pop3: The 'pop3' scope value is used to interact with POP3 mail servers. xmpp: The 'xmpp' scope value is used to interact with XMPP servers. If the resource server provides no scope to the client then the client SHOULD presume an empty scope (unscoped token) is needed. Since clients may interact with a number of application servers, such as email servers and XMPP servers, they need to have a way to determine whether dynamic client registration has been performed already and whether an already available refresh token can be re-used to obtain an access token for the desired resource server. This specification RECOMMENDs that a client uses the information in the 'issue' element to make this determination. ----------------------- I think we're getting very close :) -bill Draft -16 notification follows: ---------------------------------------------------- On Tuesday, September 16, 2014 4:45 PM, "internet-drafts@ietf.org" wrote: 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 Working Group of the IETF. Title : A set of SASL Mechanisms for OAuth Authors : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-16.txt Pages : 22 Date : 2014-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) 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 shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term 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-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. 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 From nobody Tue Sep 16 17:16:41 2014 Return-Path: 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 058111A6F3E for ; Tue, 16 Sep 2014 17:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.152 X-Spam-Level: X-Spam-Status: No, score=-3.152 tagged_above=-999 required=5 tests=[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, 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 KhNGCr9OF71r for ; Tue, 16 Sep 2014 17:16:36 -0700 (PDT) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (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 CE6F51A01F7 for ; Tue, 16 Sep 2014 17:16:34 -0700 (PDT) Received: from [98.139.214.32] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 17 Sep 2014 00:16:33 -0000 Received: from [98.139.212.195] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 17 Sep 2014 00:16:33 -0000 Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 17 Sep 2014 00:16:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 928576.39276.bm@omp1004.mail.bf1.yahoo.com Received: (qmail 81232 invoked by uid 60001); 17 Sep 2014 00:16:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1410912993; bh=Q0q0vw5o0I1o4qvYgJR57wXpRXglIrPeTSi6A+uD8nM=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dRuP53AQgnNzaX1lsfXrM03EPbU75FeiujRsfAcYk6mqSFfGKwbqzSE9MIAccgsz6VvPqzG4z9XC3yhCUfN6pt435TWOgOb3OYGfr6mfuRzlZcREW+yYcKrFt8saPEIVTk1eMqNDnNHr/hOblbfVl4gABFlr/BV2YZUdRcfslsk= X-YMail-OSG: hEHtnzYVM1lbt4bEwMDlaRzE1iSzvd.qZRejeFgqa0cgIpZ 8Av.RDvYjb538PV7R7WvbMOeDtSvUyPaOGXKXycmTiKF255FxjxMmmsNr5r5 p585KWgq.0MHDyQ0LgiACMu6RnR1KdBXov0yhUYyiCtRisgZqhxemZN1Xm.A 2n_pgl.rmxtp9lhhiL8bDlGmZNYqbv7G2ocD53qPQEwfLO0Yb_fhJND2TlR_ FxPLBc.OtwNLLB1fupCudEXyauUHet4lvKdPTX55r6UWdqKzFUX8Rwj.9LG. DskQpXrPStxxgorDi4G5wzEdRebncp_crxrVK.w6qZi.h1wg6BEB44V0qsFp oJLoihG2rCVn5z6hSHPqTCHEwg9IblPl7rnLWWmHyWv6VwtNdTPIY_ydwH.D SE2_FaqZuSxlCxEJNF444Hm0H77mppP2OSuYlmaqMKZPlUuDn7sqqbAJkZUa 0ZTEpPNBpFt1uq.dP_Ay1O0LBSGNrNKcC261XcxTE.8_Jqpbc.Zd.0noJrfG yFgcVS_peROTeV14BKu4WukEZujW_c6r3rGuoJBirabprDCw5y3mFh_LMSyU sqBDdw2Gzc1831Ct9TzzPov5PGL3J8COtcrudVN0ndF3m Received: from [167.220.24.156] by web142806.mail.bf1.yahoo.com via HTTP; Tue, 16 Sep 2014 17:16:33 PDT X-Rocket-MIMEInfo: 002.001, UmVzZW5kaW5nIHdpdGggYSBtb3JlIHVzZWZ1bCBzdWJqZWN0IGxpbmUuICAKCgoKT24gVHVlc2RheSwgU2VwdGVtYmVyIDE2LCAyMDE0IDU6MDQgUE0sIEJpbGwgTWlsbHMgPHdtaWxsc185MjEwNUB5YWhvby5jb20.IHdyb3RlOgoKCi0xNiBpcyBzdWJtaXR0ZWQsIGFuZCB0aGVyZSBpcyBvbmUgc3VnZ2VzdGVkIGNoYW5nZSAod2hpY2ggSSB3YXMgc3VwcG9zZWQgdG8gaGF2ZSBhZGRlZCBpbiBhbHJlYWR5IGFuZCBibGV3IGl0KSwgd2hpY2ggaXMgdG8gcmVwbGFjZSBzZWN0aW9uIDMuMi4yIHdpdGggdGhlIHQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <20140916234519.22685.47362.idtracker@ietfa.amsl.com> <1410912249.50514.YahooMailNeo@web142801.mail.bf1.yahoo.com> Message-ID: <1410912993.76700.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Tue, 16 Sep 2014 17:16:33 -0700 From: Bill Mills To: Bill Mills In-Reply-To: <1410912249.50514.YahooMailNeo@web142801.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/RUm8lDm9CL88RP_pC-HF6Fm4ZPE Cc: "kitten@ietf.org" Subject: [kitten] Suggested changes for -16 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 00:16:39 -0000 Resending with a more useful subject line. On Tuesday, September 16, 2014 5:04 PM, Bill Mills wrote: -16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below. My comments on the suggested text: #1) I don't think the dynamic registration stuff is baked enough to want to pull that in to the "oauth-configuration" definition. I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations. #2) I didn't really want to make all of the OpenID elements required but I don't have a strong opinion here, my initial intent was to use the OpenID Discovery format as an existing format to be re-used here but leave it flexible. #3) I am against recommending scope names at all in any way. I would not include the last sentence of paragraph 5 below and strike the scope names. New text for 3.2.2: ----------------------- 3.2.2. Server Response to Failed Authentication For a failed authentication the server returns a JSON [RFC4627] formatted error result, and fails the authentication. The error result consists of the following values: status (REQUIRED): The authorization error code. Valid error codes are defined in the IANA "OAuth Extensions Error Registry" specified in the OAuth 2 core specification. scope (OPTIONAL): An OAuth scope which is valid to access the service. This may be empty which implies that unscoped tokens are required, or a scope value. If a scope is specified then a single scope is preferred, use of a space separated list of scopes is NOT RECOMMENDED. oauth-configuration (OPTIONAL): The URL for a document following the OpenID Provider Configuration Information schema, as described in Section 3 of the OpenID Connect Discovery [OpenID.Discovery], that is appropriate for the user. The server MAY return different URLs for users from different domains and a client MUST NOT cache a single returned value and assume it applies for all users/domains that the server suports. The returned discovery document MUST have all data elements required by the OpenID Connect Discovery specification populated. In addition, the discovery document MUST contain the 'registration_endpoint' element to learn about the endpoint to be used with the Dynamic Client Registration protocol [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of parameters necessary for the OAuth protocol exchange to function. Authorization servers MUST implement the authorization code grant and other grant types MAY be supported. Furthermore, authorization servers MUST implement the ability to issue refresh tokens for use with native applications to benefit from an abbreviated protocol exchange. The use of the 'offline_access' scope, as defined in [OpenID.Core] is RECOMMENDED to give clients the capability to explicitly request a refresh token. If the resource server provides a scope (as part of the element of the configuration payload) then the client MUST always request scoped tokens from the token endpoint. This specification RECOMMMENDs the use of the following scopes: imap: The 'imap' scope value is used to interact with IMAP mail servers. pop3: The 'pop3' scope value is used to interact with POP3 mail servers. xmpp: The 'xmpp' scope value is used to interact with XMPP servers. If the resource server provides no scope to the client then the client SHOULD presume an empty scope (unscoped token) is needed. Since clients may interact with a number of application servers, such as email servers and XMPP servers, they need to have a way to determine whether dynamic client registration has been performed already and whether an already available refresh token can be re-used to obtain an access token for the desired resource server. This specification RECOMMENDs that a client uses the information in the 'issue' element to make this determination. ----------------------- I think we're getting very close :) -bill Draft -16 notification follows: ---------------------------------------------------- On Tuesday, September 16, 2014 4:45 PM, "internet-drafts@ietf.org" wrote: 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 Working Group of the IETF. Title : A set of SASL Mechanisms for OAuth Authors : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-16.txt Pages : 22 Date : 2014-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) 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 shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term 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-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. 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 _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From nobody Wed Sep 17 16:08:10 2014 Return-Path: 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 EC9AF1A03CA for ; Wed, 17 Sep 2014 16:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ftTnlYTgr_eC for ; Wed, 17 Sep 2014 16:08:02 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4C31A05F5 for ; Wed, 17 Sep 2014 16:08:01 -0700 (PDT) X-AuditID: 12074425-f79e46d000002583-3f-541a144f4337 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id B6.87.09603.F441A145; Wed, 17 Sep 2014 19:07:59 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s8HN7x8d012552; Wed, 17 Sep 2014 19:07:59 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8HN7uAl019745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Sep 2014 19:07:58 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s8HN7uh3004003; Wed, 17 Sep 2014 19:07:56 -0400 (EDT) Date: Wed, 17 Sep 2014 19:07:56 -0400 (EDT) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <1410912993.76700.YahooMailNeo@web142806.mail.bf1.yahoo.com> Message-ID: References: <20140916234519.22685.47362.idtracker@ietfa.amsl.com> <1410912249.50514.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1410912993.76700.YahooMailNeo@web142806.mail.bf1.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrOsvIhVisPmKjsXRzatYLL51XWd2 YPJYsuQnk8esWYeZApiiuGxSUnMyy1KL9O0SuDLezpjMVvBPs2L66y1sDYzbFbsYOTkkBEwk TnT0sUHYYhIX7q0Hsrk4hARmM0k0d/xngXA2MkpcPPOPHcI5xCTRO2EtK0iLkEADo8TSJRwg NouAtsSUdVvZQWw2ARWJmW82Ao3i4BARUJdo/u4NEmYGMr+decMIYgsLpEr86msHK+EU8JRo 2WMJEuYVcJRY1PkHau9uRokpe96BrRIV0JFYvX8KC0SRoMTJmU9YIGZqSSyfvo1lAqPgLCSp WUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFula6OVmluilppRuYgQFKruL6g7GCYeUDjEK cDAq8fAe4JUKEWJNLCuuzD3EKMnBpCTK+4sVKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE1/O9 ZIgQb0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IEr5Mw0FDBotT01Iq0 zJwShDQTByfIcB6g4f4gNbzFBYm5xZnpEPlTjLoc6zq/9TMJseTl56VKifOmgxQJgBRllObB zYElmFeM4kBvCfM6g1TxAJMT3KRXQEuYgJac7REDWVKSiJCSamB0n7XDik26z4fhxId6UY6q U1ecnHUa+20Vy+Uvrm33Vir4Xfo+v+PWLJfpqzzm5fv+FPY2Oq5QasfcqZO6cmlIN/OK9RMi XdqqHL/a5SrpO3JcrIiI8K4Ry33Gp8EQp3Zw25Lngqz/dM3K13w/37jPe06/X4bb9vsvrm2J nZvVYFDE8T/jiBJLcUaioRZzUXEiAFzvAKILAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/143z_6FkzB0sgw0iiuN8iB3t1DQ Cc: "kitten@ietf.org" Subject: Re: [kitten] Suggested changes for -16 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 23:08:05 -0000 On Tue, 16 Sep 2014, Bill Mills wrote: > Resending with a more useful subject line. > > > > On Tuesday, September 16, 2014 5:04 PM, Bill Mills wrote: > > > -16 is submitted, and there is one suggested change (which I was Thanks. The new text for the "host" key/value has a comma splice. In 4.3, there is an added message from the server. Is that intended to replace the previous value? > supposed to have added in already and blew it), which is to replace > section 3.2.2 with the text (farther) below. > My comments on the suggested text: I think I am confused or missed an email or something; I don't remember why you were supposed to add this text. > #1) I don't think the dynamic registration stuff is baked enough to > want to pull that in to the "oauth-configuration" definition. I don't > want to pull it in because I don't think dynamic registration is > required for SASL/OAUTH (as evidenced by the Google and Outlook.com > implementations. Even in the new text it is OPTIONAL, which would seem consistent with the lack of requirement. > #2) I didn't really want to make all of the OpenID elements required > but I don't have a strong opinion here, my initial intent was to use the > OpenID Discovery format as an existing format to be re-used here but > leave it flexible. The text in -16 seems more consistent with that goal than the text below. > #3) I am against recommending scope names at all in any way. I would > not include the last sentence of paragraph 5 below and strike the scope > names. I don't have any position on the use or inclusion of scopes; I am only concerned that if someone concludes they need to use a scope, they have some sense of how to do so/what to choose. It seems that this is a matter for generic OAuth specifications, not this document, most likely. > New text for 3.2.2: > ----------------------- > 3.2.2. Server Response to Failed Authentication > > > For a failed authentication the server returns a JSON [RFC4627] > formatted error result, and fails the authentication. The error > result consists of the following values: > > > status (REQUIRED): The authorization error code. Valid error > codes are defined in the IANA "OAuth Extensions Error Registry" > specified in the OAuth 2 core specification. > > > scope (OPTIONAL): An OAuth scope which is valid to access the > service. This may be empty which implies that unscoped tokens > are required, or a scope value. If a scope is specified then a > single scope is preferred, use of a space separated list of > scopes is NOT RECOMMENDED. > > > oauth-configuration (OPTIONAL): The URL for a document following > the OpenID Provider Configuration Information schema, as > described in Section 3 of the OpenID Connect Discovery > [OpenID.Discovery], that is appropriate for the user. The > server MAY return different URLs for users from different > domains and a client MUST NOT cache a single returned value and > assume it applies for all users/domains that the server > suports. The returned discovery document MUST have all data > elements required by the OpenID Connect Discovery specification It seems slightly redundant to say that it MUST have all the required features of the thing that it complies to, but maybe the extra emphasis is needed. -Ben > populated. In addition, the discovery document MUST contain > the 'registration_endpoint' element to learn about the endpoint > to be used with the Dynamic Client Registration protocol > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of > parameters necessary for the OAuth protocol exchange to > function. Authorization servers MUST implement the > authorization code grant and other grant types MAY be > supported. Furthermore, authorization servers MUST implement > the ability to issue refresh tokens for use with native > applications to benefit from an abbreviated protocol exchange. > The use of the 'offline_access' scope, as defined in > [OpenID.Core] is RECOMMENDED to give clients the capability to > explicitly request a refresh token. > > > If the resource server provides a scope (as part of the element of > the configuration payload) then the client MUST always request > scoped tokens from the token endpoint. This specification > RECOMMMENDs the use of the following scopes: > > imap: The 'imap' scope value is used to interact with IMAP mail > servers. > > pop3: The 'pop3' scope value is used to interact with POP3 mail > servers. > > xmpp: The 'xmpp' scope value is used to interact with XMPP servers. > > > > If the resource server provides no scope to the client then the > client SHOULD presume an empty scope (unscoped token) is needed. > > > Since clients may interact with a number of application servers, > such as email servers and XMPP servers, they need to have a way > to determine whether dynamic client registration has been performed > already and whether an already available refresh token can be > re-used to obtain an access token for the desired resource server. > This specification RECOMMENDs that a client uses the information in > the 'issue' element to make this determination. > ----------------------- > > > I think we're getting very close :) > > -bill > > > From nobody Wed Sep 17 17:46:32 2014 Return-Path: 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 E087E1A6F1D for ; Wed, 17 Sep 2014 17:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 K3hxGL5yoj4D for ; Wed, 17 Sep 2014 17:46:27 -0700 (PDT) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (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 8AEAA1A6F14 for ; Wed, 17 Sep 2014 17:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1411001186; bh=nhzo6cIjVDJvzgYbC92JOYnN/0deVGDCAownHWVtX6c=; h=Received:Received:Received:X-Yahoo-Newman-Property:X-Yahoo-Newman-Id:Date:From:Reply-To:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Length:From:Subject; b=VsvPWfzkTuxbHOBMxO2+TsI3zyao8CMli5MVbjLTBmkIFP7KTT6uqQdf78/xnxRUXKE9cnh/L8J62Q3ewPXJrlNH8nwy5e/2d0iJbbe4yrQFN2bx6bIQRNYNtlsdtOSnm68R1VuuPUR8dHIcrRtZO5DawoZQQygWZHgeBAHjnSwystPi3STxuDdh/QJqahEAzVDoWpnfu3K7JcD+I+zD4zBUSZSql4M3u0j77knM7K1XjU0NLISdbOVmDBZrewPQijdo8dnfNtBOvuIfxbgnTe2D6nsDjDT0y8fxLTpziunbOiB03wus3l/zZgoBKv+DJGM1cyyZddZJXOnn5weogQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=tscXR3iQTLJWPPLdJdXYZUm3auFfylRz+19bdycfWJQnX/irZuFWf2QpzeMfF9JVCrFeWwYyc8WsGgM7hSuCiT0tl0D1/XjJ5K1Wbt+wqTfamsMTTDm8R8kGvKLqEOjIzlsfI3F0z1FEgIrpv9A2G42EchJcPT6r75vv1WSVt7qXMg9PkzcrX8+pfHHw0aqkcCPRsOtihwJtAAW60kEv3qlTbPaUAWhn5gmEHrIi1g8GJSijXvaykZDQudXrBPD5PvtJxMh2BPGkcFqBXzf0zMi+WuH+8Xzpixqz1GFiqApWkrYIuY7NefHa8huFaw9/sVCqb+1jSQYYEVe0VEAKfg==; Received: from [98.139.212.149] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 18 Sep 2014 00:46:26 -0000 Received: from [98.139.212.215] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 18 Sep 2014 00:46:26 -0000 Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 18 Sep 2014 00:46:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 474363.3442.bm@omp1024.mail.bf1.yahoo.com Date: Thu, 18 Sep 2014 00:46:25 +0000 (UTC) From: Bill Mills To: Benjamin Kaduk Message-ID: <1629842008.197.1411001185518.JavaMail.yahoo@jws10638.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_196_249738370.1411001185509" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/GiBEF0etvZ0H-XITChBPBNAiNIM Cc: "kitten@ietf.org" Subject: Re: [kitten] Suggested changes for -16 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 00:46:30 -0000 ------=_Part_196_249738370.1411001185509 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable for the nascent -17 draft: killed the comma splice, and removed the cruft s= erver message that had the wrong status (401) in the base64 encoded stuff.= =20 The suggested text is from an off list conversation, bringing it to the lis= t. -bill On Wednesday, September 17, 2014 4:08 PM, Benjamin Kaduk wrote: =20 On Tue, 16 Sep 2014, Bill Mills wrote: > Resending with a more useful subject line. > > > > On Tuesday, September 16, 2014 5:04 PM, Bill Mills wrote: > > > -16 is submitted, and there is one suggested change (which I was Thanks. The new text for the "host" key/value has a comma splice. In 4.3, there is an added message from the server.=C2=A0 Is that intended t= o replace the previous value? > supposed to have added in already and blew it), which is to replace > section 3.2.2 with the text (farther) below. > My comments on the suggested text: I think I am confused or missed an email or something; I don't remember why you were supposed to add this text. > #1)=C2=A0 I don't think the dynamic registration stuff is baked enough to > want to pull that in to the "oauth-configuration" definition.=C2=A0 I don= 't > want to pull it in because I don't think dynamic registration is > required for SASL/OAUTH (as evidenced by the Google and Outlook.com > implementations. Even in the new text it is OPTIONAL, which would seem consistent with the lack of requirement. > #2)=C2=A0 I didn't really want to make all of the OpenID elements require= d > but I don't have a strong opinion here, my initial intent was to use the > OpenID Discovery format as an existing format to be re-used here but > leave it flexible. The text in -16 seems more consistent with that goal than the text below. > #3)=C2=A0 I am against recommending scope names at all in any way.=C2=A0 = I would > not include the last sentence of paragraph 5 below and strike the scope > names. I don't have any position on the use or inclusion of scopes; I am only concerned that if someone concludes they need to use a scope, they have some sense of how to do so/what to choose.=C2=A0 It seems that this is a ma= tter for generic OAuth specifications, not this document, most likely. > New text for 3.2.2: > ----------------------- > 3.2.2.=C2=A0 Server Response to Failed Authentication > > > For a failed authentication the server returns a JSON [RFC4627] > formatted error result, and fails the authentication.=C2=A0 The error > result consists of the following values: > > > status (REQUIRED):=C2=A0 The authorization error code.=C2=A0 Valid error > codes are defined in the IANA "OAuth Extensions Error Registry" > specified in the OAuth 2 core specification. > > > scope (OPTIONAL):=C2=A0 An OAuth scope which is valid to access the > service.=C2=A0 This may be empty which implies that unscoped tokens > are required, or a scope value.=C2=A0 If a scope is specified then a > single scope is preferred, use of a space separated list of > scopes is NOT RECOMMENDED. > > > oauth-configuration (OPTIONAL):=C2=A0 The URL for a document following > the OpenID Provider Configuration Information schema, as > described in Section 3 of the OpenID Connect Discovery > [OpenID.Discovery], that is appropriate for the user.=C2=A0 The > server MAY return different URLs for users from different > domains and a client MUST NOT cache a single returned value and > assume it applies for all users/domains that the server > suports.=C2=A0 The returned discovery document MUST have all data > elements required by the OpenID Connect Discovery specification It seems slightly redundant to say that it MUST have all the required features of the thing that it complies to, but maybe the extra emphasis is needed. -Ben > populated.=C2=A0 In addition, the discovery document MUST contain > the 'registration_endpoint' element to learn about the endpoint > to be used with the Dynamic Client Registration protocol > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of > parameters necessary for the OAuth protocol exchange to > function.=C2=A0 Authorization servers MUST implement the > authorization code grant and other grant types MAY be > supported.=C2=A0 Furthermore, authorization servers MUST implement > the ability to issue refresh tokens for use with native > applications to benefit from an abbreviated protocol exchange. > The use of the 'offline_access' scope, as defined in > [OpenID.Core] is RECOMMENDED to give clients the capability to > explicitly request a refresh token. > > > If the resource server provides a scope (as part of the element of > the configuration payload) then the client MUST always request > scoped tokens from the token endpoint.=C2=A0 This specification > RECOMMMENDs the use of the following scopes: > > imap:=C2=A0 The 'imap' scope value is used to interact with IMAP mail > servers. > > pop3:=C2=A0 The 'pop3' scope value is used to interact with POP3 mail > servers. > > xmpp:=C2=A0 The 'xmpp' scope value is used to interact with XMPP servers. > > > > If the resource server provides no scope to the client then the > client SHOULD presume an empty scope (unscoped token) is needed. > > > Since clients may interact with a number of application servers, > such as email servers and XMPP servers, they need to have a way > to determine whether dynamic client registration has been performed > already and whether an already available refresh token can be > re-used to obtain an access token for the desired resource server. > This specification RECOMMENDs that a client uses the information in > the 'issue' element to make this determination. > ----------------------- > > > I think we're getting very close :) > > -bill > > > ------=_Part_196_249738370.1411001185509 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
for the nascent -17 draft: killed the comma splice, and remo= ved the cruft server message that had the wrong status (401) in the base64 = encoded stuff.

<= /div>
The suggested text is from a= n off list conversation, bringing it to the list.

-= bill

On Wednesday, September 17, 2014 4:= 08 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:


On Tue, 16 Sep 2014, Bill Mills wrote:

> Resending with a more useful subject line.
>
>
>
> On Tuesday, September 16, 2014 5:04 PM, Bill Mills <wmills_92105@yahoo.com> wrote:
>
>
> -16 is submitted, and there is one suggested change (which I was
Thanks.

The new text for the "host" key/value has a comma splice.

In 4.3, there is an added message from the server.=   Is that intended to
replace the previous value?
> supposed to have added in already a= nd blew it), which is to replace
> section 3.2.2 with = the text (farther) below.
> My comments on the suggest= ed text:

I think I am confused or miss= ed an email or something; I don't remember
why you were s= upposed to add this text.

> #1)&nbs= p; I don't think the dynamic registration stuff is baked enough to
> want to pull that in to the "oauth-configuration" definition= .  I don't
> want to pull it in because I don't t= hink dynamic registration is
> required for SASL/OAUTH= (as evidenced by the Google and Outlook.com
> impleme= ntations.

Even in the new text it is O= PTIONAL, which would seem consistent with the
lack of req= uirement.

> #2)  I didn't real= ly want to make all of the OpenID elements required
> = but I don't have a strong opinion here, my initial intent was to use the> OpenID Discovery format as an existing format to be re= -used here but
> leave it flexible.
=
The text in -16 seems more consistent with that goal tha= n the text below.

> #3)  I am = against recommending scope names at all in any way.  I would
> not include the last sentence of paragraph 5 below and strik= e the scope
> names.

I don't have any position on the use or inclusion of scopes; I am only<= br clear=3D"none">concerned that if someone concludes they need to use a sc= ope, they have
some sense of how to do so/what to choose.=   It seems that this is a matter
for generic OAuth s= pecifications, not this document, most likely.

> New text for 3.2.2:
> -----------------= ------
> 3.2.2.  Server Response to Failed Authen= tication
>
>
&g= t; For a failed authentication the server returns a JSON [RFC4627]
> formatted error result, and fails the authentication.  = The error
> result consists of the following values:>
>
> status = (REQUIRED):  The authorization error code.  Valid error
> codes are defined in the IANA "OAuth Extensions Error Regist= ry"
> specified in the OAuth 2 core specification.
>
>
> scope (OP= TIONAL):  An OAuth scope which is valid to access the
> service.  This may be empty which implies that unscoped tokens<= br clear=3D"none">> are required, or a scope value.  If a scope is = specified then a
> single scope is preferred, use of a= space separated list of
> scopes is NOT RECOMMENDED.<= br clear=3D"none">>
>
> oauth-= configuration (OPTIONAL):  The URL for a document following
> the OpenID Provider Configuration Information schema, as
> described in Section 3 of the OpenID Connect Discovery<= br clear=3D"none">> [OpenID.Discovery], that is appropriate for the user= .  The
> server MAY return different URLs for use= rs from different
> domains and a client MUST NOT cach= e a single returned value and
> assume it applies for = all users/domains that the server
> suports.  The= returned discovery document MUST have all data
> elem= ents required by the OpenID Connect Discovery specification

It seems slightly redundant to say that it MUST have = all the required
features of the thing that it complies t= o, but maybe the extra emphasis is
needed.

-Ben


> populat= ed.  In addition, the discovery document MUST contain
> the 'registration_endpoint' element to learn about the endpoint
> to be used with the Dynamic Client Registration protocol=
> [I-D.ietf-oauth-dyn-reg] to obtain the minimum numb= er of
> parameters necessary for the OAuth protocol ex= change to
> function.  Authorization servers MUST= implement the
> authorization code grant and other gr= ant types MAY be
> supported.  Furthermore, autho= rization servers MUST implement
> the ability to issue= refresh tokens for use with native
> applications to = benefit from an abbreviated protocol exchange.
> The u= se of the 'offline_access' scope, as defined in
> [Ope= nID.Core] is RECOMMENDED to give clients the capability to
> explicitly request a refresh token.
>
>
> If the resource server provides a sco= pe (as part of the element of
> the configuration payl= oad) then the client MUST always request
> scoped toke= ns from the token endpoint.  This specification
>= RECOMMMENDs the use of the following scopes:
>
> imap:  The 'imap' scope value is used to interact wit= h IMAP mail
> servers.
>
> pop3:  The 'pop3' scope value is used to interact with = POP3 mail
> servers.
>
> xmpp:  The 'xmpp' scope value is used to interact with = XMPP servers.
>
>
>
> If the resource server provides no scope to = the client then the
> client SHOULD presume an empty s= cope (unscoped token) is needed.
>
&= gt;
> Since clients may interact with a number of appl= ication servers,
> such as email servers and XMPP serv= ers, they need to have a way
> to determine whether dy= namic client registration has been performed
> already= and whether an already available refresh token can be
&g= t; re-used to obtain an access token for the desired resource server.
> This specification RECOMMENDs that a client uses the info= rmation in
> the 'issue' element to make this determin= ation.
> -----------------------
>= ;
>
> I think we're getting very = close :)
>
> -bill
>
>
>


------=_Part_196_249738370.1411001185509-- From nobody Wed Sep 17 20:13:21 2014 Return-Path: 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 10F0D1A00BD for ; Wed, 17 Sep 2014 20:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 D_236GHG0LyG for ; Wed, 17 Sep 2014 20:13:09 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE631A0099 for ; Wed, 17 Sep 2014 20:13:08 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-b3-541a4dc28f34 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 87.CD.27750.2CD4A145; Wed, 17 Sep 2014 23:13:06 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s8I3D5vh019744; Wed, 17 Sep 2014 23:13:06 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8I3D3ta002940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Sep 2014 23:13:05 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s8I3D3Uk004745; Wed, 17 Sep 2014 23:13:03 -0400 (EDT) Date: Wed, 17 Sep 2014 23:13:03 -0400 (EDT) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <1629842008.197.1411001185518.JavaMail.yahoo@jws10638.mail.bf1.yahoo.com> Message-ID: References: <1629842008.197.1411001185518.JavaMail.yahoo@jws10638.mail.bf1.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixCmqrXvIVyrE4P1KdYujm1exWHzrus7s wOSxZMlPJo9Zsw4zBTBFcdmkpOZklqUW6dslcGUcmTCXuWADS8XbG0eYGxgPMHcxcnJICJhI nOlaBmWLSVy4t56ti5GLQ0hgNpPE1W9djBDORkaJpstrmCCcQ0wSE97tZIdwGhgl7m2cxgjS zyKgLfGj9y3YLDYBFYmZbzYCzeLgEBFQl2j+7g0SZgYyv515A1YuLJAq8auvnQ3E5hQIk9g2 sZcZpJxXwFFi3gwOiPHdjBIXvzWxgtSICuhIrN4/hQXE5hUQlDg58wkLxEwtieXTt7FMYBSc hSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1DvdzMEr3UlNJNjOBQleTZwfjmoNIh RgEORiUeXgkBqRAh1sSy4srcQ4ySHExKory9HkAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrz7 QXK8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8G3yAGgWLUtNTK9Iy c0oQ0kwcnCDDeYCGTwap4S0uSMwtzkyHyJ9iNOZoaXrby8SxrvNbP5MQS15+XqqUOC8DSKkA SGlGaR7cNFi6ecUoDvScMO80kCoeYKqCm/cKaBUT0KqzPWIgq0oSEVJSDYyTQpqXbmlqUWc9 4aAmKH//6sa1WxwzpG47/NwzrWXJiq3dLH89t8pGh67mUmbUkHzS5+KSe3TW7KuL167a3Xjr up5F22PHjLTkVrbtAc2b9u6yu67KMJl9YtL+PUtWvv++uS7bMDZg9p+iqQKqi7UX3RJrPfzu vN1Nk/SwC4FqbtNbRHjeMAgqsRRnJBpqMRcVJwIAIl+zzhIDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/23suHUsHTRutJ1NXG7V6ixwIM_I Cc: "kitten@ietf.org" Subject: Re: [kitten] Suggested changes for -16 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 03:13:13 -0000 On Wed, 17 Sep 2014, Bill Mills wrote: > for the nascent -17 draft: killed the comma splice, and removed the cruft server message that had the wrong status (401) in the base64 encoded stuff. > The suggested text is from an off list conversation, bringing it to the list. I would strongly suggest that the other party in the off-list conversation send their comments to the list. I think that in this point in the document's progression, we should have some on-list justification and general consensus for any changes that are being made. -Ben From nobody Mon Sep 22 14:52:54 2014 Return-Path: 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 8F4F41A1B0E for ; Mon, 22 Sep 2014 14:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.526 X-Spam-Level: * X-Spam-Status: No, score=1.526 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 bq7WyzkANxUI for ; Mon, 22 Sep 2014 14:52:52 -0700 (PDT) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (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 B197D1A1AAD for ; Mon, 22 Sep 2014 14:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1411422770; bh=OGt8z0KGs4J8V9JcsrjUKq7tPZB7mfagk/SwVsC1eZo=; h=Received:Received:Received:X-Yahoo-Newman-Property:X-Yahoo-Newman-Id:Date:From:Reply-To:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Length:From:Subject; b=PDNcP1pJjKzpxydOilonRMJALdiom2kXNexdV6DZX8OpQuJ/lvg63Je1NH/GtxsFPQ/U5DFRbZbuosW5oH33GTBcN8pTAANCXaFNaeheGZg/jGHd11ln9ETJDnwN16O3RbGVAOOuQSToe+b91PWIxxqSKP/TyaFejBI41AePdMvsVp+yKRCDT6TiIpsLK1jAwN5SP/7znSn6ooGmN7RQOyjdniecPsuZs2fb0aA/K15Of+0HT0ehwbrUf7EysSCD6DcHUpnoe/EdrzJrsIg/5WhC1YeS0HNWAGXWkABP/kYK0pyxwN+gyaoIFhydh5UtPGuutVXhls7SWa45Lvj0tA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=nBaxcoMJb+e6q6ExY7gb47pwCbYtIKBwPoOyzSvZ4R32LPLX5LFjZLPnfc09sJQhKVXHdp0mklPcp1Fyzv0ssZZn5wg8OPfPd9WkQOqeRbopwM3AE1BK81ZLFq4ZUPL+2u30y3wzedDCQUa8tXh9xIqMeeY+9Uj0mB2lwruw0RQ8oEHami6Eo6tUbrfkX2JlX0SoYgG9OJEvZoIkT2+K9d9ufCKAM+xeGaBCVnf4++3xje0Lw3rM0sA2lnLk7NZTsAocB3ukv8BwEyjRoABs8iWt4BtjTha2MeHDWGFoUhkvVx62c6nMrjAk3zMjRQk79gMTGD9zbCuz8rMwBU627g==; Received: from [98.139.214.32] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 22 Sep 2014 21:52:50 -0000 Received: from [98.139.212.204] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 22 Sep 2014 21:52:50 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 22 Sep 2014 21:52:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 884803.42320.bm@omp1013.mail.bf1.yahoo.com Date: Mon, 22 Sep 2014 21:52:50 +0000 (UTC) From: Bill Mills To: Benjamin Kaduk Message-ID: <1801429658.30762.1411422770121.JavaMail.yahoo@jws10645.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_30761_540657726.1411422770116" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/WRVpvYm0fIOFgp5pEfsXGLiGlRs Cc: "kitten@ietf.org" Subject: Re: [kitten] Suggested changes for -16 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 21:52:52 -0000 ------=_Part_30761_540657726.1411422770116 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The =C2=A0new language is proposed by Hannes and Torsten. =C2=A0Hoping one = of them will have time to follow up on list soon. -bill=20 On Wednesday, September 17, 2014 8:13 PM, Benjamin Kaduk wrote: =20 On Wed, 17 Sep 2014, Bill Mills wrote: > for the nascent -17 draft: killed the comma splice, and removed the cruft= server message that had the wrong status (401) in the base64 encoded stuff= . > The suggested text is from an off list conversation, bringing it to the l= ist. I would strongly suggest that the other party in the off-list conversation send their comments to the list. I think that in this point in the document's progression, we should have some on-list justification and general consensus for any changes that are being made. -Ben ------=_Part_30761_540657726.1411422770116 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The  new language is proposed by Hannes and T= orsten.  Hoping one of them will have time to follow up on list soon.<= /span>

-bill


On Wednesday, Septe= mber 17, 2014 8:13 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:


On Wed, 17 Sep 2014, Bi= ll Mills wrote:

> for the nascent -= 17 draft: killed the comma splice, and removed the cruft server message tha= t had the wrong status (401) in the base64 encoded stuff.
> The suggested text is from an off list conversation, bringing it to t= he list.

I would strongly suggest that= the other party in the off-list conversation
send their = comments to the list.

I think that in = this point in the document's progression, we should have
= some on-list justification and general consensus for any changes that arebeing made.
=

-Ben


=
------=_Part_30761_540657726.1411422770116-- From nobody Tue Sep 23 05:25:50 2014 Return-Path: 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 60E911A802C; Tue, 23 Sep 2014 05:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 IvYdHe558uaC; Tue, 23 Sep 2014 05:25:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6981A00A7; Tue, 23 Sep 2014 05:25:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140923122546.30735.53089.idtracker@ietfa.amsl.com> Date: Tue, 23 Sep 2014 05:25:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Dux53GisG2cFxE5HODDWpIiSFWg Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 12:25:47 -0000 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 Working Group of the IETF. Title : AES Encryption with HMAC-SHA2 for Kerberos 5 Authors : Michael J. Jenkins Michael A. Peck Kelley W. Burgin Filename : draft-ietf-kitten-aes-cts-hmac-sha2-05.txt Pages : 16 Date : 2014-09-23 Abstract: This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 29 18:03:35 2014 Return-Path: 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 72BCA1A000C for ; Mon, 29 Sep 2014 18:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Ss-Dkl94rC9G for ; Mon, 29 Sep 2014 18:03:32 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6A41A0009 for ; Mon, 29 Sep 2014 18:03:31 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id n15so7312271lbi.1 for ; Mon, 29 Sep 2014 18:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GSBTbhic/fmhxZqPZkuqVVEeS+Rq4JUHVNtR42ds0hM=; b=BvX+dozbFzJyxsElSnXAdx6F144qtg4POa0KOG5GPrqqKx5rZGzxCJNIO59gYlc75Y Gr7rYonu3893eCWzwj0Td/JahgWONw7TfoYjb5ChwM78n2tptgVGNcKxJKHWfS4/C2z1 i3i1TrtUqIsg+6i79ui5QpattTZc3CsErOVHmji/djzOOxyPXh0QUANvgQg6t55IhUr5 4xiiAO1lT/D1dK7YvicefbpOTPMSxxfZUW1BnHM7tYPpivUgeq9/CmfspOG4puY9JemU IwooFIE1QaOERmpQxNT+wt+JUKkszTrdrPxvVU7ylvY5MK9K7f7hhQM+4CoyvDIBj+o3 zJpA== MIME-Version: 1.0 X-Received: by 10.112.150.106 with SMTP id uh10mr40255740lbb.11.1412039010218; Mon, 29 Sep 2014 18:03:30 -0700 (PDT) Received: by 10.152.25.132 with HTTP; Mon, 29 Sep 2014 18:03:30 -0700 (PDT) In-Reply-To: <1409243818.9966.3.camel@redhat.com> References: <1409243818.9966.3.camel@redhat.com> Date: Mon, 29 Sep 2014 21:03:30 -0400 Message-ID: From: Richard Feezel To: kitten@ietf.org Content-Type: multipart/alternative; boundary=047d7b34340c9cf71605043df3a2 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/LytzSEQjg8lqHuu1lrppyk-NgIs Subject: Re: [kitten] Authentication Indicator in Kerberos tickets X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 01:03:34 -0000 --047d7b34340c9cf71605043df3a2 Content-Type: text/plain; charset=UTF-8 I would like to encourage the group to adopt this document as well. I, too, have been wrestling with the challenge of how to represent assertions about an authentication event which extend well beyond questions of the technical strength of the authentication methodology. The implications of an authentication event extend far beyond the question of whether the technical mechanism should be trusted. The qualities of the whole process of qualifying individual identities before technical credentials are issued is often an important consideration when making authorization decisions. Another idea not specifically envisioned in the proposed approach, but well within it's capability is the question of how to represent the "circumstances" under which the user is authenticating. Such ideas as "User is authenticating on their office computer during normal business hours" could be represented and would, in some circumstances, very useful in making risk-based authorizations decisions. The proposed mechanism is a compact and yet generalized and extendible idea which supports both global federation and localizable customization. It is a perfect fit for the CAMMAC container which I also encourage the group to quickly adopt. I plan to do some trial implementation testing and would like to know what values I can safely use for the Authorization Data fields for CAMMAC and Authentication Indicators in advance of an official action by this group and the IANA? On Thu, Aug 28, 2014 at 12:36 PM, Nathaniel McCallum wrote: > I have submitted a new draft for Kerberos Authentication Indicators and > I'd like to start a discussion about moving the draft through the > process. I'm a newbie here, so any help would be greatly appreciated. > > The purpose of Authentication Indicators is to be able to assert some > positive attributes about the authentication event itself in the ticket. > This should also be usable in the case of S4U2Proxy. > > The draft can be found here: > http://www.ietf.org/id/draft-jain-kitten-krb-auth-indicator-01.txt > > For some background information, see the MIT krb5 project page: > http://k5wiki.kerberos.org/wiki/Projects/Authentication_indicator > > Thanks! > > Nathaniel McCallum > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > -- Richard M Feezel rfeezel@gmail.com --047d7b34340c9cf71605043df3a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would like to encourage the group to adopt this doc= ument as well.
=C2=A0
I, too,=C2=A0have been wrestling = with the challenge of how to represent assertions about an authentication e= vent which extend well beyond questions of the technical strength of the au= thentication methodology. The=C2=A0implications=C2=A0of an authentication e= vent extend far beyond the question of whether the technical mechanism shou= ld be trusted. The qualities of the whole process of qualifying individual = identities=C2=A0before technical credentials are issued is often an importa= nt consideration when making authorization decisions.
=C2=A0
Another idea not specifically envisioned in the proposed approach, bu= t well within it's capability is the question of how to represent the &= quot;circumstances" under which the user is authenticating. Such ideas= as "User is authenticating on their office computer during normal bus= iness hours" could be represented and would, in some circumstances, ve= ry useful in making risk-based authorizations decisions.
=C2=A0
The proposed mechanism is a compact and yet generalized and extend= ible idea which supports both global federation and localizable customizati= on.
=C2=A0
It is a perfect fit for the CAMMAC container= which I also encourage the group to quickly adopt.
=C2=A0
<= div>I plan to do some trial implementation testing and would like to know w= hat values I can safely use for the Authorization Data fields for CAMMAC an= d Authentication Indicators in advance of an official action by this group = and the IANA?

On Thu, Aug 28, 2014 at 12:36 PM, Nathaniel McCallum <npmccall= um@redhat.com> wrote:
I hav= e submitted a new draft for Kerberos Authentication Indicators and
I'd like to start a discussion about moving the draft through the
process. I'm a newbie here, so any help would be greatly appreciated.
The purpose of Authentication Indicators is to be able to assert some
positive attributes about the authentication event itself in the ticket. This should also be usable in the case of S4U2Proxy.

The draft can be found here:
http://www.ietf.org/id/draft-jain-kitten-krb-auth-ind= icator-01.txt

For some background information, see the MIT krb5 project page:
http://k5wiki.kerberos.org/wiki/Projects/Authenticatio= n_indicator

Thanks!

Nathaniel McCallum

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



--
Richard M Feezel
rfeezel@gmail.com
--047d7b34340c9cf71605043df3a2-- From nobody Tue Sep 30 11:11:14 2014 Return-Path: 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 6F3E71A86FC for ; Tue, 30 Sep 2014 11:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, 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 e8bEPux8Yc7N for ; Tue, 30 Sep 2014 11:10:45 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 8616B1A871A for ; Tue, 30 Sep 2014 11:10:45 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8UIAhMW012829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 30 Sep 2014 14:10:44 -0400 Received: from willson.usersys.redhat.com (ovpn-113-127.phx2.redhat.com [10.3.113.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8UIAg9Z015667 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 30 Sep 2014 14:10:42 -0400 Date: Tue, 30 Sep 2014 14:10:40 -0400 From: Simo Sorce To: kitten@ietf.org Message-ID: <20140930141040.271b6205@willson.usersys.redhat.com> In-Reply-To: <20140923122546.30735.53089.idtracker@ietfa.amsl.com> References: <20140923122546.30735.53089.idtracker@ietfa.amsl.com> Organization: Red Hat, Inc MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/QiO0KLfsTxVRJ-4oJyiSOU12ozA Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 18:10:59 -0000 On Tue, 23 Sep 2014 05:25:46 -0700 internet-drafts@ietf.org wrote: > > 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 Working Group of the IETF. > > Title : AES Encryption with HMAC-SHA2 for Kerberos 5 > Authors : Michael J. Jenkins > Michael A. Peck > Kelley W. Burgin > Filename : draft-ietf-kitten-aes-cts-hmac-sha2-05.txt Hi while reading this otherwise very nice specification two questions kept popping in my mind. Why SHA-512 is not being used ? Why AES-192 is not being used and SHA-384 is paired with AES-256 instead ? Why are you using a hash twice the size of the bit strength required, and chop it off, isn't HMAC supposedly not affected by birthday attacks ? I can guess at the rationale of some of these choices (some of it was discussed in IETF meetings/lists), but it would be nice to have a section that explains the choice or even just a reference to some other document that does. Regards, Simo. -- Simo Sorce * Red Hat, Inc * New York