From latze@angry-red-pla.net Fri Jul 13 05:10:26 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F5A21F86F3 for ; Fri, 13 Jul 2012 05:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFnQ+y3rbi4V for ; Fri, 13 Jul 2012 05:10:26 -0700 (PDT) Received: from thuvia.angry-red-pla.net (thuvia.angry-red-pla.net [83.169.33.217]) by ietfa.amsl.com (Postfix) with ESMTP id 00B0E21F86E2 for ; Fri, 13 Jul 2012 05:10:22 -0700 (PDT) Received: from 110-229.194-178.cust.bluewin.ch ([178.194.229.110] helo=[192.168.1.128]) by thuvia.angry-red-pla.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Spehz-0003dV-Ly for Kitten@ietf.org; Fri, 13 Jul 2012 14:10:56 +0200 Message-ID: <5000104E.2000607@angry-red-pla.net> Date: Fri, 13 Jul 2012 14:10:54 +0200 From: Carolin Latze User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120506 Icedove/3.0.11 MIME-Version: 1.0 To: Kitten@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [kitten] draft-josefsson-sasl-external-channel-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 12:10:26 -0000 Hi all, we just uploaded a new version of the draft-josefsson-sasl-external-channel: http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-05.txt This is an upgrade of a pretty old draft which has been discussed on the SASL list in the past: http://www.ietf.org/mail-archive/web/sasl/current/msg00427.html By then, the main issue was the lack of an use case which we believe we found now. We came with the requirement to use multiple certificates within the same authentication exchange. Some applications (like BYOD in some companies) want to make use of an user and a device authentication. Access should only be granted if user *and* device can be authenticated. One way to do that is to set up a secure tunnel where you authenticate the device and then run user authentication inside that tunnel. However that costs some resources. Therefore, we upgraded the I-D to allow for chained, renegotiated TLS handshakes in the EXTERNAL-TLS mechanism to support this use case. Best regards Carolin From nico@cryptonector.com Sat Jul 14 23:15:27 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719D221F8464 for ; Sat, 14 Jul 2012 23:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=-2.807, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cqv3mHL+srg for ; Sat, 14 Jul 2012 23:15:26 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 115F121F8463 for ; Sat, 14 Jul 2012 23:15:26 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 6BED976805C for ; Sat, 14 Jul 2012 23:16:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=UFFToQZWfGuKwxEKeF3Vm5pAaHX1GXOn35jzvkoHMhp3 OHoqN/+LuNSsA4MHr1MEBYM0Uz3+6tCEO/mUcUoLhs9dqUN1/0IawgR9FTCgqht5 Qpy3h31vgd/S0C/OR+Doma+fWVpcjSgxauGnY1FLiXw8Y9VsrlmlqrnhgcbvHXo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=V7NyFPDWrni1b8BzfFHtd0ay13A=; b=w0cta0CEsKl Xpmcy7cz0a0lhLQdAFUNaXINb+oZp5O5lSrsmG9nhS223RjfJOg/FwLj+4laSp19 HYkm5Cc0OZQC0fMt5fEwcBiTHVX4IIkZQ81y8Pp47aIHWpoTi4FsPfanr31vjrF4 megU7rydsOKYWBgpps0MvGaa25NAw9hU= Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 465CD768059 for ; Sat, 14 Jul 2012 23:16:06 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3233202vbb.31 for ; Sat, 14 Jul 2012 23:16:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.37.80 with SMTP id w16mr2695051vdj.84.1342332965490; Sat, 14 Jul 2012 23:16:05 -0700 (PDT) Received: by 10.220.76.203 with HTTP; Sat, 14 Jul 2012 23:16:05 -0700 (PDT) Date: Sun, 15 Jul 2012 01:16:05 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 06:15:27 -0000 I keep running into this "the GSS-API is enormous, enormously complex, forget it" attitude. So I've written an I-D that I hope will help with this. It's too late for the -00 cut-off. Here's a non-submitted I-D: https://raw.github.com/nicowilliams/httpbisIDs/master/gss-profiles.txt Other renderings are available at: https://github.com/nicowilliams/httpbisIDs Nico -- From chris.newman@oracle.com Mon Jul 16 11:29:34 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EC321F8742 for ; Mon, 16 Jul 2012 11:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55g7JJUFvicV for ; Mon, 16 Jul 2012 11:29:33 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 864E621F8741 for ; Mon, 16 Jul 2012 11:29:33 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6GIU7DQ032308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jul 2012 18:30:08 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6GIU7g4015887; Mon, 16 Jul 2012 18:30:07 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.101.111] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7u5-4.06 64bit (built Mar 14 2012)) with ESMTPA id <0M7900E5GNE4JV00@gotmail.us.oracle.com>; Mon, 16 Jul 2012 11:30:06 -0700 (PDT) Date: Mon, 16 Jul 2012 11:30:08 -0700 From: Chris Newman To: Carolin Latze , Kitten@ietf.org Message-id: In-reply-to: <5000104E.2000607@angry-red-pla.net> References: <5000104E.2000607@angry-red-pla.net> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [kitten] draft-josefsson-sasl-external-channel-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 18:29:34 -0000 I'm very dubious of this claim in the abstract. > This has impacted the interoperability of the EXTERNAL mechanism. Perhaps that claim should be either removed or supported with documentation in an appendix. We're also in a situation where we're just starting to get partial interoperability of TLS client certificate authentication with SASL EXTERNAL in the installed base of Internet email services (there have been numerous interoperability problems in that space, although I'm not aware of any problems due to the specification of the EXTERNAL mechanism). I'm concerned that muddying the waters by introducing EXTERNAL-TLS may produce more interoperability problems. However, that concern would be largely mitigated if this document added a statement along the lines of: Clients that use EXTERNAL-TLS SHOULD be able to use EXTERNAL for the same purpose in order to interoperate with deployed server software that presently only implements EXTERNAL for use with TLS. Servers that advertise EXTERNAL-TLS SHOULD also advertise EXTERNAL in order to interoperate with deployed client software that presently only implements EXTERNAL. - Chris --On July 13, 2012 14:10:54 +0200 Carolin Latze wrote: > Hi all, > > we just uploaded a new version of the > draft-josefsson-sasl-external-channel: > > http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel > -05.txt > > This is an upgrade of a pretty old draft which has been discussed on the > SASL list in the past: > > http://www.ietf.org/mail-archive/web/sasl/current/msg00427.html > > By then, the main issue was the lack of an use case which we believe we > found now. We came with the requirement to use multiple certificates > within the same authentication exchange. Some applications (like BYOD in > some companies) want to make use of an user and a device authentication. > Access should only be granted if user *and* device can be authenticated. > One way to do that is to set up a secure tunnel where you authenticate > the device and then run user authentication inside that tunnel. However > that costs some resources. Therefore, we upgraded the I-D to allow for > chained, renegotiated TLS handshakes in the EXTERNAL-TLS mechanism to > support this use case. > > Best regards > Carolin > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From chris.newman@oracle.com Mon Jul 16 14:17:24 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7A611E8143 for ; Mon, 16 Jul 2012 14:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j5R2Aj3dYqi for ; Mon, 16 Jul 2012 14:17:22 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id ECC3F11E80EF for ; Mon, 16 Jul 2012 14:17:21 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6GLI41n002546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jul 2012 21:18:05 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6GLI4mB010263; Mon, 16 Jul 2012 21:18:04 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.101.111] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7u5-4.06 64bit (built Mar 14 2012)) with ESMTPA id <0M7900E6GV61JV00@gotmail.us.oracle.com>; Mon, 16 Jul 2012 14:18:03 -0700 (PDT) Date: Mon, 16 Jul 2012 14:18:05 -0700 From: Chris Newman To: Nico Williams , kitten@ietf.org Message-id: <5096375474F148B9EF159D55@96B2F16665FF96BAE59E9B90> In-reply-to: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 21:17:25 -0000 I really appreciate that you're trying, but this document seems like something designed to appeal to people interested in security concepts and philosophy. Some application developers are not interested. Security is sometimes viewed by newer application developers as an annoyance that makes it more difficult to accomplish useful goals. For experienced application developers, security is often viewed as a risky area where the best approach is to write the absolute minimum amount of code necessary to accomplish specific customer requirements and to be wary both of third-party security libraries and of the risk integrating such libraries creates as these have been frequent sources of major vulnerabilities in real-world software. I put myself in the latter camp. Anyway, if you want to make GSS-API appealing to application developers, I'd suggest starting with a focus on two things: 1. How to get the client authenticated to the server using traditional username. 2. How to exchange the messages over protocol between the client and server to accomplish 1. SASL has seen partial success in deployment when it has successfully made the case that it solves these two problems with less effort than a roll-your-own approach. GSS-API has utility to the extent it is makes the code simpler when solving these two problems and responding to real-world customer requests, such as: Kerberos authentication (this request comes from Universities or sites running Windows Domain Controllers) and TLS client certificate authentication. Then perhaps discuss how things like SCRAM and channel bindings available through GSS-API might be a competitive advantage, or help customers/sites get a bit ahead of the curve on security. - Chris --On July 15, 2012 1:16:05 -0500 Nico Williams wrote: > I keep running into this "the GSS-API is enormous, enormously complex, > forget it" attitude. So I've written an I-D that I hope will help > with this. It's too late for the -00 cut-off. Here's a non-submitted > I-D: > > https://raw.github.com/nicowilliams/httpbisIDs/master/gss-profiles.txt > > Other renderings are available at: > > https://github.com/nicowilliams/httpbisIDs > > Nico > -- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nico@cryptonector.com Mon Jul 16 14:34:45 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A3F21F8644 for ; Mon, 16 Jul 2012 14:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=-1.467, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtWB-cpB0RCf for ; Mon, 16 Jul 2012 14:34:44 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0CC21F8609 for ; Mon, 16 Jul 2012 14:34:44 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 4A3AF31805C for ; Mon, 16 Jul 2012 14:35:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=VVLyxw10eaoZ/RGUJfVoN klY8VkZk7pQ1YapPIAtYVpNLm1ruJnxtXpsurtaZha5oR0VboK5WKRmM8idkBPTv xv7FPC+dLy1PvoxNPLgZUTTxdOS9cUNasZbPfHuGJychyekWU8abI+UBvWd5RT3n 1DRGL9noSdwcfgkOLV62YA= 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=FHq9+8fBda4IVVRGqh4e N1FPtG8=; b=jrZWGedmtYWE3LIOARUzgWU5dYCNam7zcUfAleYsiMwQe6nshms1 6fpf2X1huwZeuXQT6zoypgmgXWo39LOtsY0WCYbAc2ynfpNJkNBQOy4NSttsFhiU 0jwDStKW2NZR58ZMC2812U6T4qr9PLdxebNWAOPbsYnAiqz8Vnvo0nE= Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 2BB76318058 for ; Mon, 16 Jul 2012 14:35:28 -0700 (PDT) Received: by yhq56 with SMTP id 56so6229572yhq.31 for ; Mon, 16 Jul 2012 14:35:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.83.200 with SMTP id s8mr13854pay.10.1342474527200; Mon, 16 Jul 2012 14:35:27 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Mon, 16 Jul 2012 14:35:27 -0700 (PDT) In-Reply-To: <5096375474F148B9EF159D55@96B2F16665FF96BAE59E9B90> References: <5096375474F148B9EF159D55@96B2F16665FF96BAE59E9B90> Date: Mon, 16 Jul 2012 16:35:27 -0500 Message-ID: From: Nico Williams To: Chris Newman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 21:34:45 -0000 On Mon, Jul 16, 2012 at 4:18 PM, Chris Newman wrote: > I really appreciate that you're trying, but this document seems like > something designed to appeal to people interested in security concepts and > philosophy. Some application developers are not interested. Security is > [...] Whenever one of us usual suspects says "GSS" several people start complaining about complexity. But the GSS-API is NOT complex. It is NOT something that an application developer MUST use. The main purpose of the GSS-API for me is to provide a degree of formalism in application protocols. It's like the syntax used in TLS for its messages, or ASN.1 (the notation), or XDR syntax, or ABNF, or... That's all. That's all I want anyone to use it for. Whether anyone uses the GSS-API for implementations, I don't actually care. GSS-API, SSPI, home-brew wire-compatible equivalents (e.g., like Samba) -- doesn't matter to me. Now, this particular I-D is intended to show how simple the GSS-API can be for any use of it, whether specification or implementation, by showing that for most use cases a tiny subset of the API is sufficient. In particular this I-D is targeting some misplaced criticisms uttered on the HTTPbis WG mailing list regarding my "REST-GSS" proposal for HTTP/2.0 authentication. (Actually, REST-GSS uses SASL/GS2, so it should really be called REST-SASL. It's just a RESTful approach to multi-legged authentication message key exchanges, and by using POST it also results in a session URI which can be DELETEd to logout. It has a number of advantages over all other HTTP auth proposals.) I'm starting to think that we need different names for different aspects of the API. In particular the *abstract* API (RFC2743) needs to be named something that doesn't have "API" in the name, or even "GSS". It's not an API in the strictest sense, it's a) a language for specifying how applications use GSS, b) a pattern for actual programming language bindings of it. > Anyway, if you want to make GSS-API appealing to application developers, I'd > suggest starting with a focus on two things: > > 1. How to get the client authenticated to the server using traditional > username. So, this is part of that. I intend to add another I-D describing how to use the API. The only reason I'd do this in another I-D is that having too much content in one I-D is going to make it large and, evidently, scary. > 2. How to exchange the messages over protocol between the client and server > to accomplish 1. Yes. > SASL has seen partial success in deployment when it has successfully made > the case that it solves these two problems with less effort than a > roll-your-own approach. Right. Thanks for your feedback. While you're thinking about this, can you think of how better to separate the abstract and concrete uses of the GSS-API? I think that's where we could do the most to promote the use of it... (And no, promoting its use is not a fetish, but a code and specification re-use matter.) Nico -- From wmills@yahoo-inc.com Mon Jul 16 16:22:02 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E68011E8088 for ; Mon, 16 Jul 2012 16:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.548 X-Spam-Level: X-Spam-Status: No, score=-17.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abvX4L7EQwPQ for ; Mon, 16 Jul 2012 16:22:01 -0700 (PDT) Received: from nm17-vm4.bullet.mail.ne1.yahoo.com (nm17-vm4.bullet.mail.ne1.yahoo.com [98.138.91.177]) by ietfa.amsl.com (Postfix) with SMTP id D99F211E8085 for ; Mon, 16 Jul 2012 16:22:00 -0700 (PDT) Received: from [98.138.90.50] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jul 2012 23:22:42 -0000 Received: from [98.138.88.237] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jul 2012 23:22:42 -0000 Received: from [127.0.0.1] by omp1037.mail.ne1.yahoo.com with NNFMP; 16 Jul 2012 23:22:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 688360.29777.bm@omp1037.mail.ne1.yahoo.com Received: (qmail 78865 invoked by uid 60001); 16 Jul 2012 23:22:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1342480962; bh=p3ERAnzsyoqXmaTpcEV8xfES/lialEtLGbylVznJ2Ew=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pNhUgsVMFGSaLMDpjAXgJnKSYz5veY8FcxBw0LZLDTshIT6NMGoQwqL/MtbF3KgPb5wB86f0AvtUC6VTcsNMYBtgmzB9vThWUwsCwMIqx536lPoxi4aGEwewcJKMJRmV4J5HAAYUrmTNkRhuX9b/feB1VxFW/vfCJJp8xsvuJW0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=paEpdtexRimdGCJIP/FkycUVpozeEMR1z0WbcjStXvp9XkgMbWaYktDaSZEUVtVPoo3g1Ij61kWUHe4AZp7f9U/irbQOr3Fo4SIH05Vck6gDfpFtZY/HezvnQj7pxamjwYxXwuF8+YfHt69ESe9i3mzsyHNbHgKe0yMEcEI1HEY=; X-YMail-OSG: C0oralEVM1np8otXDS69CdXOrkgHV.S34afHpYwEcrItHvv CernMEsF4j3HUjvZqhkahekixeum55t2N8D6seZuZzY_fKosVNwA3folQczT 8wmo9ziab6rpemwDfew_66mKK12EoiihJE6M2kX3l46FvCuYvxuSMy6FfZhv PPmd202R0VNhjI43Om3ebTXFtq2ihxfyZN9dLeah79RwP4eUPMSJOl0QHrFZ WFvccpb6hBZv7exm2vJYhtS7t_vprpZXFMtlj2wWf1uQ8HUGpteCIA44oqFR CKUupjvZC9PDUbDuWkuNn5UiZwzTyhM78BZ0VKf4W2gSimWccxey9t8RRDF8 5N3l.zip4FDMaoEWK7NguAeSS6e8W8c1LB_Gea0tCDsGe2c_rHz.Se35_aVQ fP8PA0z6mZJ4vPuFSEEEStb8aUpI8DZ78RmCOMNr8_BxfPR.m9o4- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Mon, 16 Jul 2012 16:22:42 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <1342480265.22646.YahooMailNeo@web31807.mail.mud.yahoo.com> Message-ID: <1342480962.78473.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Mon, 16 Jul 2012 16:22:42 -0700 (PDT) From: William Mills To: "kitten@ietf.org" In-Reply-To: <1342480265.22646.YahooMailNeo@web31807.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [kitten] Fw: [OAUTH-WG] SASL / OAuth Binding Request: User Field X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 23:22:02 -0000 (bringing this to the Kitten list where it probably should be, might get a = dup of a different message too)=0A=0A=0AI'm fine with Ryan's desire to brin= g back the "user" element into the SASL message.=A0 In an HTTP environment = the server would probably accomplish this with a cookie, I don't want to ma= ke a general cookie mechanism, but I'm OK with requiring a username hint in= the SASL message itself.=A0 The only danger I think is that developers wil= l use it for more than just a hint, which isn't to huge a deal.=0A=0AAny ob= jection to this?=0A=0A=0A-bill=0A=0A=0A=0A----- Forwarded Message -----=0AF= rom: Ryan Troll =0A>To: oauth@ietf.org =0A>Sent: Monda= y, July 16, 2012 11:46 AM=0A>Subject: [OAUTH-WG] SASL / OAuth Binding Reque= st: User Field=0A> =0A>=0A>I'd like to discuss the possibility of adding a = "user" field to the SASL/OAuth request. =A0This is based on draft-ietf-kitt= en-sasl-oauth-00.txt.=0A>=0A>=0A>Background=0A>The contents of this field m= ay be used by the resource provider as a hint to aid in request routing, an= d/or data location, without the need for=A0decrypting=A0the provided access= token. =A0The contents of the user field is not used to grant access of an= y kind.=0A>=0A>=0A>=0A>=0A>Proposed Addition=0A>The text of this addition c= ould look something like this:=0A>=0A>=0A>Section 3.1 addition / update:=0A= >=0A>=0A>user: =A0Contains the user ID of the user being authorized=0A>>=0A= >>In authorization schemes that use signatures, the client MUST send host, = port number and user key/values, and the server MUST fail authorization req= uests requiring signatures that do not have host, port, and user values.=0A= >=0A>=0A>Section 3.2 addition:=0A>=0A>=0A>If the user field is present, the= ID in the user field must match the ID obtained from the credential for th= e request to succeed.=0A>=0A>=0A>=0A>=0A>Rationale for Presence of User Fie= ld in the Request=0A>This data is not required by all resource providers, a= nd as such could be a provider-specific requirement, placed (for example) i= n the query string. =A0By documenting the user field, we encourage resource= providers that do require it to find it in the same location - encouraging= inter-operability.=0A>=0A>=0A>The user identity could be determined via th= e access token, rather than requiring it in the request. =A0However, using = the access token to determine the identity can result in the resource provi= der decoding the token multiple times, or making multiple requests to the a= ccess provider. =A0By pulling this attribute out into the protocol, we may = be able to simplify the resource provider work required when moving to OAut= h.=0A>=0A>=0A>=0A>=0A>Rationale for Location of User Field=0A>This data cou= ld be transmitted as part of the path, or a query string parameter, or in t= he post body. =A0This approach, using a header, was proposed as there are c= urrently no path, query string, or post fields defined. =A0Those three loca= tions remain untouched by this proposal.=0A>=0A>=0A>=0A>=0A>Comments?=0A>-R= =0A>=0A>=0A>=0A>=0A>_______________________________________________=0A>OAut= h mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/o= auth=0A>=0A>=0A>=0A>=0A> From nathan@webr3.org Mon Jul 16 17:05:45 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF55421F875C for ; Mon, 16 Jul 2012 17:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxL7N6ZAe2PR for ; Mon, 16 Jul 2012 17:05:45 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 249AD21F8742 for ; Mon, 16 Jul 2012 17:05:44 -0700 (PDT) Received: by weyu54 with SMTP id u54so4413059wey.31 for ; Mon, 16 Jul 2012 17:06:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=95yi9X2huPCmI0CUDIpfk0QgMyjPXkVQRTIZPEfAU8M=; b=HF3lhXDcFIkNZmq3Q2T1QXEQagvOyPhzfTP+DrOJNzpNe7q1C48+RFVPdnBHNFc751 8aDLZ8eHZekEkr5xPcRvYiyX2GdKQ0VhQT2IYAdOTf6hvJMQNyJCRNUxxffjgjiKCOt1 BVSkiSGonSXS6pWl7CuIQhMuYPolIrH4puUNj+XOaPEqcBr9g5na9sPahqqnnjQxL0oF eTWZ7WmyaCHzFiv7dVVnkDUtTpCkWYLIo4fwwkTI5zuMDPqOafzLeGgr4tuyvDqTDBPg NAxiAwpLzHNj9t0jidT9kCI8qK6xH1bvmM460Z9v9yGutNbDVsd0v6KXJ7R7SWsc2Ls3 v1Fg== Received: by 10.180.94.234 with SMTP id df10mr788827wib.16.1342483590249; Mon, 16 Jul 2012 17:06:30 -0700 (PDT) Received: from [192.168.1.68] (host81-152-134-57.range81-152.btcentralplus.com. [81.152.134.57]) by mx.google.com with ESMTPS id t7sm35549450wix.6.2012.07.16.17.06.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Jul 2012 17:06:29 -0700 (PDT) Message-ID: <5004AC5B.3040701@webr3.org> Date: Tue, 17 Jul 2012 01:05:47 +0100 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Nico Williams References: <5096375474F148B9EF159D55@96B2F16665FF96BAE59E9B90> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk0EoWAxwRkrsLGSDdgw8HDCKo6I9QIo2ko3d1KXdvUXRLZafWtFA57I8IfzxX811tHfl0+ Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nathan@webr3.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 00:05:46 -0000 Nico Williams wrote: > On Mon, Jul 16, 2012 at 4:18 PM, Chris Newman wrote: >> I really appreciate that you're trying, but this document seems like >> something designed to appeal to people interested in security concepts and >> philosophy. Some application developers are not interested. Security is >> [...] > > Whenever one of us usual suspects says "GSS" several people start > complaining about complexity. But the GSS-API is NOT complex. It is > NOT something that an application developer MUST use. If it helps any, I'm a fairly competent web developer, I've read gss-profiles.txt (didn't sink in, sorry) and then read the REST-GSS ID, which I'm glad to say did make far more sense. However, I don't "get it" - it appears to be a way to store encrypted or verifiable session state on a remote server using verious cryptographic methods and tied to various apis (like gss). So it leads me to a few questions: a) why would I want a session with a stateless protocol like HTTP? b) if I did want a session, why would I want it's state to be stored on a third, web accessible, resource? .. using a custom message structure which isn't a well known media type? .. dependent on knowledge of several other specifications? c) what advantage does any of this give over say a simple client side certificate containing a unique user identifier? (c) is perhaps the most important of my questions, if I'm missing something I'm keen to learn - as currently I've just got a big "but why?" when I think about these IDs I've just read. TIA, Nathan From nico@cryptonector.com Mon Jul 16 17:24:46 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D7211E8086 for ; Mon, 16 Jul 2012 17:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.423 X-Spam-Level: X-Spam-Status: No, score=-3.423 tagged_above=-999 required=5 tests=[AWL=-1.446, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGyFDCYjXGzs for ; Mon, 16 Jul 2012 17:24:45 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id BB47911E80FB for ; Mon, 16 Jul 2012 17:24:43 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 705322C2057 for ; Mon, 16 Jul 2012 17:25:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=nk+yDE7vFLOFn0IYzvW+1 97Bx8bGa/aALc3EoiaVHIhY6L3IVumbFrrJGd3PeDoGdDqbCyICq2ZksXlfkAUda Usg1wpz78kBqgjg7JfzTMsZpOPcVgJg0UZRZHC2p1BAC4D9fX0pQpGJ/SMcVc6DR Eb1lQ9PT486vpnP8+t/LNU= 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=A6iLBGwgDC/01ZDmLwnF IaDrLT4=; b=meflvCrEGmjIoD7X9/FEyGB6oUxnApVS7PpRs8NYxjKrAN9T//uf keUmPBeJBC/YDs9bQnAz5WdSXYbMK0JGd8bRR/kpJ6sxW8v/7MfpEMau/IijwyOa HnlV9ILUWU3YcsxFkI7rwUaLJzlu2RrNBs3VBA1VUf6hm2mm/WMVnZY= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 4B2042C2054 for ; Mon, 16 Jul 2012 17:25:29 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so11323762pbc.31 for ; Mon, 16 Jul 2012 17:25:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.75.168 with SMTP id d8mr731877paw.63.1342484729011; Mon, 16 Jul 2012 17:25:29 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Mon, 16 Jul 2012 17:25:28 -0700 (PDT) In-Reply-To: <5004AC5B.3040701@webr3.org> References: <5096375474F148B9EF159D55@96B2F16665FF96BAE59E9B90> <5004AC5B.3040701@webr3.org> Date: Mon, 16 Jul 2012 19:25:28 -0500 Message-ID: From: Nico Williams To: nathan@webr3.org Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 00:24:46 -0000 On Mon, Jul 16, 2012 at 7:05 PM, Nathan wrote: > Nico Williams wrote: >> Whenever one of us usual suspects says "GSS" several people start >> complaining about complexity. But the GSS-API is NOT complex. It is >> NOT something that an application developer MUST use. > > If it helps any, I'm a fairly competent web developer, I've read > gss-profiles.txt (didn't sink in, sorry) and then read the REST-GSS ID, > which I'm glad to say did make far more sense. Great. > However, I don't "get it" - it appears to be a way to store encrypted or > verifiable session state on a remote server using verious cryptographic > methods and tied to various apis (like gss). So it leads me to a few > questions: Every cryptographic authentication protocol ever devised involves some exchange of authentication messages. GSS, SASL, EAP, SSHv2, IKEv*, TLS -- all of these have a such a thing. GSS_Init_sec_context() and GSS_Accept_sec_context() are an abstract API to just that exchange of authentication messages. Typically one outcome of authentication is session keys (because authentication and key exchange generally go together). The interfaces to shared session keys are: - the per-message token functions (GSS_Wrap(), Unwrap, GetMIC, and VerifyMIC) - GSS_Pesudo_random() (for generating sub-session key material for application purposes) Another typical outcome of authentication is a name of the peer, which is typically then used for authorization. The interfaces to this are: - GSS_Display_name() - GSS_Display_name_ext() - GSS_Export_name() - GSS_Inquire_name() - GSS_Get_name_attribute() > a) why would I want a session with a stateless protocol like HTTP? Because HTTP is stateless, but the application protocol rarely ever is. Cookies exist precisely to bind multiple requests (and corresponding responses) into one session. > b) if I did want a session, why would I want it's state to be stored on a > third, web accessible, resource? Session keys are shared by the two end-points of the session -- by definition. The resource itself would not be accessible to third parties: the server would only allow the client that owns the session (i.e., that knows its URI and is using MIC tokens, if that option is enabled) to GET or DELETE it. > .. using a custom message structure which isn't a well known media type? There's really not much to this resource. If we must we can add a media type for it. > .. dependent on knowledge of several other specifications? Surely we want to re-use existing authentication specifications. There's a number of reasons for this. If one has deployed Kerberos, say, surely one does not want to abandon that investment just so that HTTP can have an authentication scheme that... does not reuse other specifications. :) > c) what advantage does any of this give over say a simple client side > certificate containing a unique user identifier? Not everyone can carry private keys around. Even if everyone has smartphones, tablets, ... with them, there are times when the only way to recover from some disaster is via a password. "Ooops, my phone fell in the toilet, now I have no credentials." But also, user certificates have not see wide deployment. The Mozilla browserid concept is basically to authenticate traditionally then download your private keys so you can use user certificates, and even that hasn't taken off. I propose that we need pluggable authentication precisely so that people can re-use the credentials infrastructures that they already have. Deploying a new credentials infrastructure is essentially duplicating effort, at least for the long period of migration that must follow it. > (c) is perhaps the most important of my questions, if I'm missing something > I'm keen to learn - as currently I've just got a big "but why?" when I think > about these IDs I've just read. RESTful authentication gives you: - a way to initiate authentication w/o revealing what resource you're interested in before you finish authenticating the service - sessions using something better than cookies (and with an option for replay protection) - logout! - universally implementable HTTP authentication even when the mechanism selected requires multiple round trips This works with HTTP/1.0, 1.1, and almost certainly with whatever the final 2.0 will look like. It can be implemented with FCGI on well over 95% of web servers. It can be implemented on all client HTTP stacks. It can also be implemented by the HTTP stack so the application doesn't have to. - pluggable authentication (see above) Nico -- From chris.newman@oracle.com Mon Jul 16 18:33:02 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13BB21F85D3 for ; Mon, 16 Jul 2012 18:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9Z3IT9yC3G0 for ; Mon, 16 Jul 2012 18:33:02 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 1C56B21F85CE for ; Mon, 16 Jul 2012 18:33:02 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6H1XkJo030024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jul 2012 01:33:47 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6H1Xksp024007; Tue, 17 Jul 2012 01:33:46 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.101.111] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7u5-4.06 64bit (built Mar 14 2012)) with ESMTPA id <0M7A00E7W707JV00@gotmail.us.oracle.com>; Mon, 16 Jul 2012 18:33:45 -0700 (PDT) Date: Mon, 16 Jul 2012 18:33:47 -0700 From: Chris Newman To: Nico Williams Message-id: In-reply-to: References: <5096375474F148B9EF159D55@96B2F16665FF96BAE59E9B90> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 01:33:03 -0000 --On July 16, 2012 16:35:27 -0500 Nico Williams wrote: > Thanks for your feedback. While you're thinking about this, can you > think of how better to separate the abstract and concrete uses of the > GSS-API? I think that's where we could do the most to promote the > use of it... (And no, promoting its use is not a fetish, but a code > and specification re-use matter.) I'd start by breaking this down into sub-elements of the problem space. So we have: 1. a protocol-independent authentication model 2. a set of rules to bind the protocol-independent model to an application protocol and perform an authentication exchange for that protocol. 3. an optional set of elements that can be added to the above model that are helpful for specific authentication mechanisms or security problems. Most of these elements shouldn't or don't manifest in the protocol and can be ignored by implementations until they are needed. 4. a client/server API 5. extensions to the client/server API for item 3 6. a generic client/server mechanism ABI to go with 4 7. extensions to a generic client/server mechanism ABI for generic client/server API I consider standardization of items 1-3 incredibly valuable, standardization of items 4-5 of dubious value, and standardization or implementation of items 6-7 to be a design error in most cases. SASL and GSS-API both adequately cover 1. SASL covers 2 well (I find GSS-API vague in that area albeit more flexible due to that vagueness). SASL largely ignored 3, while GSS-API adds value in that area. Both models botched handling of authentication errors, but that can be worked around on a per-application basis as needed. The problem with trying to "market" the model to protocol implementers is that they may not understand that passwords-over-TLS won't be good enough forever, or they may want to pretend their protocol is the one-true-protocol and none of the other ones matter, or they may think their protocol is a special case, or they may have noticed that IETF authentication mechanisms have a poor track record and mistake that for lack of utility of a standardized model, or they may not understand how few constraints a standard model places on applications and implementations. Perhaps a "guide to IETF application authentication" that focuses on how the SASL/GSS-API models impact protocols and their implementations without getting into any API cruft. And do it incrementally, perhaps like: * You need TLS + password authentication in your protocol/implementation. Here are some issues to consider... * Your code base supports authentication for more than one protocol. Here are some additional issues to consider... * You want an IETF standards track application protocol with authentication. Some issues to consider... Checklist... * You may have security conscious customers who want certificate authentication via TLS. Some issues to consider... * You have customers who want multi-protocol single-sign-on (e.g., via Kerberos and/or Windows domain controller). Some issues to consider... * You want to innovate on authentication. Some issues to consider... The idea is instead of trying to convince them that the model we have is great, we need to help them solve their problem better and show how the model we have does that as they encounter new customer requirements. - Chris From mrex@sap.com Mon Jul 16 19:57:06 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5403521F869E for ; Mon, 16 Jul 2012 19:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uu7lDQBCduy4 for ; Mon, 16 Jul 2012 19:57:05 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 774A521F8622 for ; Mon, 16 Jul 2012 19:57:05 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q6H2vdJ4016643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jul 2012 04:57:40 +0200 (MEST) In-Reply-To: To: Nico Williams Date: Tue, 17 Jul 2012 04:57:39 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120717025739.80FE71A0D4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 02:57:06 -0000 While I'm in principle OK with trying to make GSS-API easier to digest for app programmers, I find your document much harder to understand than the original GSS-API spec, and I'm slighlty concerned about misleading information in the document about what can be reasonably expected from GSS-API implementations. Nico Williams wrote: > > GSS_Init_sec_context() and GSS_Accept_sec_context() are an abstract > API to just that exchange of authentication messages. OK. > > Typically one outcome of authentication is session keys (because > authentication and key exchange generally go together). The > interfaces to shared session keys are: > > - the per-message token functions (GSS_Wrap(), Unwrap, GetMIC, and VerifyMIC) Some authentication schemes may establish a shared (session) secret between peers during authentication and offer "message protection" service that application callers can use to protect their actual communication of application data between the peers. > - GSS_Pesudo_random() (for generating sub-session key material for > application purposes) Huge WARNING sign: this is not part of GSS-API v2 and not commonly available. > > Another typical outcome of authentication is a name of the peer, which > is typically then used for authorization. The interfaces to this are: > > - GSS_Display_name() for visualization/debug purposes only. > - GSS_Display_name_ext() not part GSS-API v2 and not commonly available for > 90% of existing gssapi mechs. > - GSS_Export_name() for populating ACLs and comparing authenticated peers to ACLs. > - GSS_Inquire_name() not part of GSS-API v2 and not commonly available > - GSS_Get_name_attribute() not part of GSS-API v2 and not commonly available for > 90% of existing gssapi mechs. And other that your document suggest, support for hostbased service names (GSS_C_NT_HOSTBASED_SERVICE) is BY FAR not universal. Of the ~20 gssapi mechanism implementation we have certified for interop with our application, only the solutions implementing Kerberos (rfc1964, rfc4121) support the hostbased service name, *ALL* other do not support it. Support for the nametype GSS_C_NT_USER_NAME is also quite questionable. This nametype is defined to "indicate a named user on a local system. Its syntax an interpretation may be OS-specific". For GSS-API mechanisms that are not tightly integrated with the OS, there may not even exist a mapping between users known to a GSS-API and users known to the OS. In general, GSS-API mechanisms have their very own notion of identities, and these may be syntactically very distinct from users as known to the OS. One should not blindly assume that GSS_C_NT_USER_NAME is ignored on input, but rather use GSS_C_NO_OID. gss_display_name() will rarely emit usernames, but typically identities as known natively to the GSS-API mechanism, with a "proprietary nametype" that may either be defined by the spec describing this gssapi mechanism (as it is with the Kerberos GSS-API mechanism), or might be implementation defined (as it is with implementations of rfc-2025, the "Simple Public Key Mechanism" due to the lack of a standardized name format/syntax in the specification. -Martin From nico@cryptonector.com Mon Jul 16 20:12:34 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3F111E8087 for ; Mon, 16 Jul 2012 20:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.402 X-Spam-Level: X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[AWL=-1.425, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmQO7Q53rGB6 for ; Mon, 16 Jul 2012 20:12:33 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8E94711E8086 for ; Mon, 16 Jul 2012 20:12:33 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id B75CC21DE77 for ; Mon, 16 Jul 2012 20:13:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Di80DWsSHCNuRMv0UExG3 BlPsys3u/8GRAIBRWQHiTXfkSvcx4KNnHqRXS7NoI7BliZqX45GIa5VAkYfmtb0B ff4dmpCVj+jPBJJM4DWp2v093FkYQquu2psubmnOFH3Tbl5UTvRK1MuyObcZ8uPj L/dlnzVLmU2uktw4Em+yjk= 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=8itasyS/UPK13ft6oGf7 1GxJcMo=; b=kHbz4fc6/wh5dwLVHth1y8yhzfn0dovp2mp2cTwaNr1hwWADXc1u pNBeLNUiJIQN+1FFACweegB701arSDVjWk5NBr2gZENdUboFIUFo0kk9lRy0PnvU BkRSY5p+22WIITxZyNfP3D6+TpTwn7syw0ESu11yPZUPdqPjQnxaSp4= Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 85CCA21DE57 for ; Mon, 16 Jul 2012 20:13:19 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6274586ghb.31 for ; Mon, 16 Jul 2012 20:13:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.75.168 with SMTP id d8mr1652578paw.63.1342494798530; Mon, 16 Jul 2012 20:13:18 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Mon, 16 Jul 2012 20:13:18 -0700 (PDT) In-Reply-To: References: <5096375474F148B9EF159D55@96B2F16665FF96BAE59E9B90> Date: Mon, 16 Jul 2012 22:13:18 -0500 Message-ID: From: Nico Williams To: Chris Newman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 03:12:34 -0000 On Mon, Jul 16, 2012 at 8:33 PM, Chris Newman wrote: > --On July 16, 2012 16:35:27 -0500 Nico Williams > wrote: >> >> Thanks for your feedback. While you're thinking about this, can you >> think of how better to separate the abstract and concrete uses of the >> GSS-API? I think that's where we could do the most to promote the >> use of it... (And no, promoting its use is not a fetish, but a code >> and specification re-use matter.) Let me go a bit further. We've seen the rise of quite a few frameworks where initially some protocol had one authentication method, then another was added, then... and finally implementors factored out authentication sub-protocols completely. EAP and SASL grew organically like that. GSS was more design-by-committee contemporaneously with Microsoft's SSPI and with SASL. It should be no surprise that Microsoft uses one API to interface to... three! frameworks: TLS, SASL, and GSS. Three! Heck, with a bit of effort I think IKE could be added to that list so that it could interface four frameworks. Heck, we could easily make GSS mechanisms based on SSHv2, so we could have one interface to five frameworks. The point: the same pattern repeats over, and over, and over again. Every time we build one more new framework we create duplication of effort and code. Every time we build a new framework we create bloat. So just to be utterly clear: it's not a GSS fetish I have, it's a re-use fetish. Once upon a time that was widely thought a good thing; isn't it still? > I'd start by breaking this down into sub-elements of the problem space. So > we have: Yes, roughly that is right. > I consider standardization of items 1-3 incredibly valuable, standardization > of items 4-5 of dubious value, and standardization or implementation of > items 6-7 to be a design error in most cases. Let's grant that for argument's sakes. Does any harm come from standardizing APIs/ABIs? It happens all the time outside the IETF. Are you merely objecting the IETF as the SDO for APIs/ABIs? Did harm actually follow from our having done so? > SASL and GSS-API both adequately cover 1. SASL covers 2 well (I find GSS-API > vague in that area albeit more flexible due to that vagueness). SASL largely I find SASL utterly vague because it's specified entirely in English language with nothing to add any formalism. The GSS-API too is specified in English language, but by having a notion of types and functions it makes it much easier to specify how to use the GSS-API formally, whereas SASL... there's no tools for formalism. Why is it OK to ask for the use of ABNF for specifying message forms, say, but not to have a similar tool for specifying protocol flows and options? > ignored 3, while GSS-API adds value in that area. Both models botched > handling of authentication errors, but that can be worked around on a > per-application basis as needed. I'd like to hear more about the handling of authentication errors. The GSS-API has a concept of error token for conveying authentication error information. Twelve years ago I had make sure that sshd sent those so that clients had useful error information to show to users. > The problem with trying to "market" the model to protocol implementers is > that they may not understand that passwords-over-TLS won't be good enough > forever, or they may want to pretend their protocol is the one-true-protocol > and none of the other ones matter, or they may think their protocol is a > special case, or they may have noticed that IETF authentication mechanisms > have a poor track record and mistake that for lack of utility of a > standardized model, or they may not understand how few constraints a > standard model places on applications and implementations. Yes, this is happening. > Perhaps a "guide to IETF application authentication" that focuses on how the > SASL/GSS-API models impact protocols and their implementations without > getting into any API cruft. And do it incrementally, perhaps like: Actually, what I'd like to do is implement and see. I can't right now, but maybe in a couple of months. We'll see. My proposal is partly designed to make it real easy to get near universal server-side support by being implementable as FCGI (actually, I lie: I realized this was so *after* I decided to use a RESTful design). The client-side is the hard part: I'd have to implement plugins for three or four major browsers, and it'd be hard to get the proper level of UI integration as a plugin. > * You need TLS + password authentication in your protocol/implementation. > Here are some issues to consider... > > * Your code base supports authentication for more than one protocol. Here > are some additional issues to consider... Well, if we don't say this, no problem: within a few years the framework pattern will repeat by itself :) (But that should be a sad smiley. I'm screaming from the rooftop that there's no need to re-invent the wheel one more time. We have so many authentication frameworks... But I guess we'll never learn.) > * You want an IETF standards track application protocol with authentication. > Some issues to consider... Checklist... > > * You may have security conscious customers who want certificate > authentication via TLS. Some issues to consider... > > * You have customers who want multi-protocol single-sign-on (e.g., via > Kerberos and/or Windows domain controller). Some issues to consider... > > * You want to innovate on authentication. Some issues to consider... > > The idea is instead of trying to convince them that the model we have is > great, we need to help them solve their problem better and show how the > model we have does that as they encounter new customer requirements. Right, we should give them running code. Nico -- From hartmans@mit.edu Tue Jul 17 06:53:07 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C9D21F8522 for ; Tue, 17 Jul 2012 06:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.094 X-Spam-Level: X-Spam-Status: No, score=-103.094 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEq+dradpHYj for ; Tue, 17 Jul 2012 06:53:07 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 23C8C21F85C5 for ; Tue, 17 Jul 2012 06:53:07 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1A621202D8 for ; Tue, 17 Jul 2012 09:54:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CC1C941F0; Tue, 17 Jul 2012 09:53:31 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org Date: Tue, 17 Jul 2012 09:53:31 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] RFC 6680 (naming extensions): Oops IANA X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 13:53:08 -0000 during final review, the RFC editor discovered that we did not actually register an OID for the gss-composite-export name type defined in the naming extensions draft. I think it's obvious that we intended to register an OID and that we intended to register it using the same registry used in RFC 5178 and 2743 for name types. If you think I'm wrong please speak up soon. I don't know what the process will be, but this looks enough like just an honest mistake that we may move quickly. From nathan@webr3.org Tue Jul 17 13:24:05 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1315B21F8688 for ; Tue, 17 Jul 2012 13:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgIwBfyHFJkH for ; Tue, 17 Jul 2012 13:24:03 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7A621F867C for ; Tue, 17 Jul 2012 13:24:00 -0700 (PDT) Received: by weyu54 with SMTP id u54so600120wey.31 for ; Tue, 17 Jul 2012 13:24:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=9yErexp94X/Foj7jP278Lx1g9yPq/zOGciumQV4lZG0=; b=WktW2sn2L9H58I1ujDpnqfF/dpCXzp9Co0+I6EFtTtb0B0rX929sWxpe4IUOjGyJ0F xMI3WiXvvlqupS1t3f9+Ae11i/6pb9Bi84V8CCigcg60zjJkJFUtKJ7g9RmAID0zC9Ze QUFyhqzz7Kyv+a58wGlx80oUbvxTkpfEihtMWh8hatGAk5rOajk840aLg8Z2IbWQr4gk MbaF6Xbqrl+NUo1RrSJv+ktIh0Ff481zjL9RWKiZCHzuY3f1mm9DSssriZcCz3xaXuw9 nh/GOgKpL9daGhrUloH6bCgC+LaU9yFruQr5thVJ9La9luhoXkBxdtHGXag0arM5ZwGZ INYw== Received: by 10.180.86.106 with SMTP id o10mr553032wiz.22.1342556688071; Tue, 17 Jul 2012 13:24:48 -0700 (PDT) Received: from [192.168.1.68] (host81-152-134-57.range81-152.btcentralplus.com. [81.152.134.57]) by mx.google.com with ESMTPS id df4sm28727526wib.4.2012.07.17.13.24.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2012 13:24:47 -0700 (PDT) Message-ID: <5005CA0B.3000400@webr3.org> Date: Tue, 17 Jul 2012 21:24:43 +0100 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Nico Williams References: <5096375474F148B9EF159D55@96B2F16665FF96BAE59E9B90> <5004AC5B.3040701@webr3.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkkNOgNI0H2+PuHalx/J5pR+y5KcGXwEjsDpi90emZpq/DZ5gN2s+Qd4tVxmLxB/6V8UbPy Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nathan@webr3.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 20:24:05 -0000 Nico Williams wrote: > On Mon, Jul 16, 2012 at 7:05 PM, Nathan wrote: >> Nico Williams wrote: > Every cryptographic authentication protocol ever devised involves some > exchange of authentication messages. GSS, SASL, EAP, SSHv2, IKEv*, > TLS -- all of these have a such a thing. > > GSS_Init_sec_context() and GSS_Accept_sec_context() are an abstract > API to just that exchange of authentication messages. can you summarise their functionality for me? (even though it's fairly obvious) > Typically one outcome of authentication is session keys (because > authentication and key exchange generally go together). The > interfaces to shared session keys are: > > - the per-message token functions (GSS_Wrap(), Unwrap, GetMIC, and VerifyMIC) > - GSS_Pesudo_random() (for generating sub-session key material for > application purposes) Am I correct in thinking these correspond to commonly used terms: encrypt, decrypt (or seal and open) sign, verify and then just a typical random bytes function ? > Another typical outcome of authentication is a name of the peer, which > is typically then used for authorization. The interfaces to this are: > > - GSS_Display_name() > - GSS_Display_name_ext() > - GSS_Export_name() > - GSS_Inquire_name() > - GSS_Get_name_attribute() okay, functions to get details on the peer, what about the client details? >> a) why would I want a session with a stateless protocol like HTTP? > > Because HTTP is stateless, but the application protocol rarely ever is. It's probably worth mentioning that I'm already one of the converted who uses HTTP strictly stateless, storing state in client side applications where needed - however I won't mention that again as it isn't useful to this convo, and obviously I did use sessions w/ http for years. No need to respond to this, just an fyi. > Cookies exist precisely to bind multiple requests (and corresponding > responses) into one session. understood - and I can see some merits to the pattern of storing "state" in restful resource. Have you considered the use cases of shared session / application state between multiple clients? as this is something we run in to often. aside: when I say we, I typically refer to a bunch of people I work closely with who are part of the Read-Write-Web CG, WebID group (you may be interested in this), Linked Data community and various related projects around W3C. >> b) if I did want a session, why would I want it's state to be stored on a >> third, web accessible, resource? > > Session keys are shared by the two end-points of the session -- by > definition. The resource itself would not be accessible to third > parties: the server would only allow the client that owns the session > (i.e., that knows its URI and is using MIC tokens, if that option is > enabled) to GET or DELETE it. If the entire process is done over plain old HTTP, won't it be open to MIM attacks? and will it involve any passing of sensitive data (key info etc) over unencrypted / insecure transports? >> .. using a custom message structure which isn't a well known media type? > > There's really not much to this resource. If we must we can add a > media type for it. may come back to this later in the discussion, I'll keep it in mind. >> .. dependent on knowledge of several other specifications? > > Surely we want to re-use existing authentication specifications. > There's a number of reasons for this. If one has deployed Kerberos, > say, surely one does not want to abandon that investment just so that > HTTP can have an authentication scheme that... does not reuse other > specifications. This resonates with me, and enables me to see what you're trying to achieve as (please correct if wrong): Define a simplified abstract protocol for creating secure sessions, then map that abstract protocol to HTTP, via the use of headers which allows resource to specify which type of security to use, and which resource to access in order to create and manage a session. Correct? >> c) what advantage does any of this give over say a simple client side >> certificate containing a unique user identifier? > > Not everyone can carry private keys around. Even if everyone has > smartphones, tablets, ... with them, there are times when the only way > to recover from some disaster is via a password. "Ooops, my phone > fell in the toilet, now I have no credentials." Yes, this is one of the core issues we've found with WebID - so the point resonates. > But also, user certificates have not see wide deployment. The Mozilla > browserid concept is basically to authenticate traditionally then > download your private keys so you can use user certificates, and even > that hasn't taken off. Agree, things take time - but anything that involves certificates can involve jumping through an inordinate amount of hoops, either for developer or user. > I propose that we need pluggable authentication precisely so that > people can re-use the credentials infrastructures that they already > have. Deploying a new credentials infrastructure is essentially > duplicating effort, at least for the long period of migration that > must follow it. Admirable goal. To be brutally honest, the IDs I've read and which were discussing do not make this clear, they're: a) verbose b) couched in unfamiliar terminology from GSS c) unclear, both in terms of structure, and as to what you're trying to convey. I'm hoping that through this chain of emails you'll be able to explain to me simply the contents of the ID and what you're trying to achieve, and that may well be enough to write a much more generic and terse ID on the topic - which may help you greatly in your effort. Would be glad to learn what I can from you here and aid what you're trying to do, regardless of where it ultimately ends up - if that's okay with you. >> (c) is perhaps the most important of my questions, if I'm missing something >> I'm keen to learn - as currently I've just got a big "but why?" when I think >> about these IDs I've just read. > > RESTful authentication gives you: > > - a way to initiate authentication w/o revealing what resource you're > interested in before you finish authenticating the service So authentication, rather than authorisation? > - sessions using something better than cookies (and with an option > for replay protection) why optional replay protection, isn't this a critical feature? > - logout! > > - universally implementable HTTP authentication even when the > mechanism selected requires multiple round trips sounds good - I'm not clear on the details yet, but hope to be soon. Best, Nathan From nico@cryptonector.com Tue Jul 17 14:12:31 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F07E11E80A2 for ; Tue, 17 Jul 2012 14:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.383 X-Spam-Level: X-Spam-Status: No, score=-3.383 tagged_above=-999 required=5 tests=[AWL=-1.406, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UehIq6SgfkzY for ; Tue, 17 Jul 2012 14:12:30 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6620B21F84FD for ; Tue, 17 Jul 2012 14:12:30 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id C58241E05C for ; Tue, 17 Jul 2012 14:13:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=qkkl7q4bt4WgVnFVCwaY9 Tg/xezCQ8vVPRF/ZQw9SXmqNifrSuiemWzvxJWC7j0kE1Nyp998QJJwoCRKPBny4 Ntg1lzLDoiRK/pZ97B6pmmDUIUYcfqyu4bN9V8s1wffih+Yt+WwDnVdFQMygLk9B NKyURJYUaLDUWfBYYYQxts= 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=MeGCstzbnX0KsdqpvAMN zarkcyk=; b=uHVhxz+9Bga9U5wlx18d7BrtsHA8UyOpov+OPQxtDPIGW6cGYdta 67egNeIw1BhsxWvvWd49yoFD/cc+SwlMzPwOkQ6I0kEqADWV0E4VU28kGDmacqRO +p0MAG6qy11edu1idp/Jr3t7zZ86rxntz9T7K2JVUG3MowaqeTNHXpI= Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 91BB01E00D for ; Tue, 17 Jul 2012 14:13:18 -0700 (PDT) Received: by yhq56 with SMTP id 56so1014929yhq.31 for ; Tue, 17 Jul 2012 14:13:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.220.39 with SMTP id pt7mr1906492pbc.40.1342559597319; Tue, 17 Jul 2012 14:13:17 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Tue, 17 Jul 2012 14:13:17 -0700 (PDT) In-Reply-To: <5005CA0B.3000400@webr3.org> References: <5096375474F148B9EF159D55@96B2F16665FF96BAE59E9B90> <5004AC5B.3040701@webr3.org> <5005CA0B.3000400@webr3.org> Date: Tue, 17 Jul 2012 16:13:17 -0500 Message-ID: From: Nico Williams To: nathan@webr3.org Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 21:12:31 -0000 On Tue, Jul 17, 2012 at 3:24 PM, Nathan wrote: > Nico Williams wrote: >> Every cryptographic authentication protocol ever devised involves some >> exchange of authentication messages. GSS, SASL, EAP, SSHv2, IKEv*, >> TLS -- all of these have a such a thing. >> >> GSS_Init_sec_context() and GSS_Accept_sec_context() are an abstract >> API to just that exchange of authentication messages. > > can you summarise their functionality for me? (even though it's fairly > obvious) GSS_Init/Accept_sec_context() drive the exchange of authentication messages ("security context tokens" in GSS speak). The model is that the initiator sends the first token, the acceptor consumes it. If the acceptor produces a token, then that is to be sent to the initiator, and if the acceptor wants another token from the initiator then the function will return a status indication for that. We loop until we're done. These functions DO NOT do the I/O for the authentication message exchange -- they deal in buffers, and it's the application's job to actual send and receive them. This allows for authentication message exchanges consisting of 1 message (half round trip), 2 (one round trip), 3, 4, ... N. Most GSS mechanisms have a fixed number of messages, but they technically can use variable numbers of authentication messages. The authentication message exchange is synchronous. It's not possible for one party to send two such messages without receiving one in between. There's a fairly large number of arguments to these functions, but most inputs have reasonable defaults. The ones that matter most as follows. Inputs: - target_name (initiator side) is the intended name of the acceptor, and it's a required input - mech (initiator side) is the intended mechanism choice, but takes a default value - input_cred_handle (both) is the credential object for the local party; takes a default value - req_flags (initiator side) requests features - input_token (both), token from the peer - context (both) is an input/output parameter as these functions act as the constructor for the security context object on the first call, and then use the constructed context as the state object to tie the subsequent calls (if any) to the initial ones - all other inputs are not worth mentioning here The outputs include: - actual_mech (both), being the mechanism that was used, which can differ from the initial choice if the initial choice can negotiate an alternate mechanism (e.g., SPNEGO can do this) - ret_flags (both), indicates what functionality is available - the context itself, of course - output_token (both), token to send to the peer - src_name (acceptor-side only), the authenticated name of the initiator - all other outputs are not worth mentioning here. >> Typically one outcome of authentication is session keys (because >> authentication and key exchange generally go together). The >> interfaces to shared session keys are: >> >> - the per-message token functions (GSS_Wrap(), Unwrap, GetMIC, and >> VerifyMIC) >> - GSS_Pesudo_random() (for generating sub-session key material for >> application purposes) > > > Am I correct in thinking these correspond to commonly used terms: > encrypt, decrypt (or seal and open) > sign, verify > and then just a typical random bytes function > > ? Yes, with the caveat that sign/verify are with symmetric keys, not public keys ("signature"nowadays tends to mean "public key signature"). >> Another typical outcome of authentication is a name of the peer, which >> is typically then used for authorization. The interfaces to this are: >> >> - GSS_Display_name() >> - GSS_Display_name_ext() >> - GSS_Export_name() >> - GSS_Inquire_name() >> - GSS_Get_name_attribute() > > okay, functions to get details on the peer, what about the client details? It's symmetric: each peer gets to know the other's name. So the client can ask about the server and vice versa. (It's possible too for either or both peers to be anonymous.) >>> a) why would I want a session with a stateless protocol like HTTP? >> >> Because HTTP is stateless, but the application protocol rarely ever is. > > It's probably worth mentioning that I'm already one of the converted who > uses HTTP strictly stateless, storing state in client side applications > where needed - however I won't mention that again as it isn't useful to this > convo, and obviously I did use sessions w/ http for years. No need to > respond to this, just an fyi. REST-GSS allows for all REST-GSS server-side state to be stored by the client, with that state being encrypted in a server key, of course. The server could just cache the state instead of burdening all the client requests with this state ticket; if the state gets lost then the client just gets to re-authenticate. >> Cookies exist precisely to bind multiple requests (and corresponding >> responses) into one session. > > understood - and I can see some merits to the pattern of storing "state" in > restful resource. The state can be encrypted into a ticket that the client's requests have to carry. > Have you considered the use cases of shared session / application state > between multiple clients? as this is something we run in to often. No. Where can I learn more about this? Could the use of a state ticket (see above) address this? >>> b) if I did want a session, why would I want it's state to be stored on a >>> third, web accessible, resource? >> >> Session keys are shared by the two end-points of the session -- by >> definition. The resource itself would not be accessible to third >> parties: the server would only allow the client that owns the session >> (i.e., that knows its URI and is using MIC tokens, if that option is >> enabled) to GET or DELETE it. > > If the entire process is done over plain old HTTP, won't it be open to MIM > attacks? and will it involve any passing of sensitive data (key info etc) > over unencrypted / insecure transports? I envision REST-GSS being used either in conjunction with TLS (with channel binding) or standalone. When used standalone you'll want to use the MIC option for certain to provide integrity protection to the requests and responses. I did not provide an option for TLS-less confidentiality protection (i.e., encryption), should I? >>> .. dependent on knowledge of several other specifications? >> >> Surely we want to re-use existing authentication specifications. >> There's a number of reasons for this. If one has deployed Kerberos, >> say, surely one does not want to abandon that investment just so that >> HTTP can have an authentication scheme that... does not reuse other >> specifications. > > This resonates with me, and enables me to see what you're trying to achieve > as (please correct if wrong): > > Define a simplified abstract protocol for creating secure sessions, then map > that abstract protocol to HTTP, via the use of headers which allows resource > to specify which type of security to use, and which resource to access in > order to create and manage a session. > > Correct? Yes. I'm particularly interested in NOT forcing a one-size-fits-all solution, which to me means we need a pluggable framework. >> But also, user certificates have not see wide deployment. The Mozilla >> browserid concept is basically to authenticate traditionally then >> download your private keys so you can use user certificates, and even >> that hasn't taken off. > > Agree, things take time - but anything that involves certificates can > involve jumping through an inordinate amount of hoops, either for developer > or user. The problem is not the certificates but the private keys. Users can't be expected to type them in :( so we need to carry them on thumb drives, or better, smartcards. But that creates all sorts of problems. Smartphones and tablets allow for device keys -- as if the devices were or had an embedded smartcard. But we don't always get to use personal mobile wireless devices (e.g., in the corporate environment it's all about desktops, terminals, servers). So I think there must be room for password-based mechanisms, among others. >> I propose that we need pluggable authentication precisely so that >> people can re-use the credentials infrastructures that they already >> have. Deploying a new credentials infrastructure is essentially >> duplicating effort, at least for the long period of migration that >> must follow it. > > Admirable goal. To be brutally honest, the IDs I've read and which were > discussing do not make this clear, they're: > > a) verbose > b) couched in unfamiliar terminology from GSS > c) unclear, both in terms of structure, and as to what you're trying to > convey. > > I'm hoping that through this chain of emails you'll be able to explain to me > simply the contents of the ID and what you're trying to achieve, and that > may well be enough to write a much more generic and terse ID on the topic - > which may help you greatly in your effort. Would be glad to learn what I can > from you here and aid what you're trying to do, regardless of where it > ultimately ends up - if that's okay with you. Great. I appreciate the help! I am coming around to the idea of re-writing the REST-GSS I-D in a way that doesn't remotely mention GSS (nor SASL/GS2)... I can arrange for it to be such that it'd be exactly compatible REST-GSS. We did just this with SCRAM (RFC5802), which is designed to be a GSS-API mechanism but not described as such in the normative specification. >>> (c) is perhaps the most important of my questions, if I'm missing >>> something >>> I'm keen to learn - as currently I've just got a big "but why?" when I >>> think >>> about these IDs I've just read. >> >> >> RESTful authentication gives you: >> >> - a way to initiate authentication w/o revealing what resource you're >> interested in before you finish authenticating the service > > So authentication, rather than authorisation? Authorization follows authentication. GSS gives you authentication and information suitable for authorization, but the application has to do the authorization bit. E.g., the server has to decide whether you get to GET a resource, POST to it, DELETE it.... >> - sessions using something better than cookies (and with an option >> for replay protection) > > why optional replay protection, isn't this a critical feature? If you use a state ticket (see above) then you can't have it, that's all. >> - logout! >> >> - universally implementable HTTP authentication even when the >> mechanism selected requires multiple round trips > > sounds good - I'm not clear on the details yet, but hope to be soon. I truly appreciate that you're interested and asking these questions. I am open to the idea that this is the wrong approach, or that significant changes may be needed, but I can only really figure that out when I get feedback like yours. Nico -- From chris.newman@oracle.com Tue Jul 17 22:12:37 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EB511E8124 for ; Tue, 17 Jul 2012 22:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5GCgNlh0ILL for ; Tue, 17 Jul 2012 22:12:35 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 31DEC11E8121 for ; Tue, 17 Jul 2012 22:12:26 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6I5DDIv016199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jul 2012 05:13:13 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6I5DC7b027230; Wed, 18 Jul 2012 05:13:12 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.110.120] (dhcp-amer-vpn-rmdc-anyconnect-10-159-110-120.vpn.oracle.com [10.159.110.120]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7u5-4.06 64bit (built Mar 14 2012)) with ESMTPA id <0M7C00D0XBTTVN00@gotmail.us.oracle.com>; Tue, 17 Jul 2012 22:13:12 -0700 (PDT) Date: Tue, 17 Jul 2012 22:03:32 -0700 From: Chris Newman To: Nico Williams Message-id: <71320C768C9C5B50320CB5FC@[192.168.15.131]> In-reply-to: References: <5096375474F148B9EF159D55@96B2F16665FF96BAE59E9B90> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 05:12:37 -0000 --On July 16, 2012 22:13:18 -0500 Nico Williams wrote: > So just to be utterly clear: it's not a GSS fetish I have, it's a > re-use fetish. Once upon a time that was widely thought a good thing; > isn't it still? I think many have learned the hard way that code re-use is overrated. A generalized library that tries to solve many problems can be difficult to use, difficult to maintain and make problem diagnosis harder. Simple narrowly focused code can reduce long term costs better than re-use of complex general purpose code. But protocol re-use and model re-use can have great benefits even if no code re-use is involved. I strongly support reusing the GSS/SASL model, but have zero interest in promoting the API. Indeed, I think promoting the API is harmful to this effort because it taints a useful model with complex implementation details that are often irrelevant to the problem at hand. >> I consider standardization of items 1-3 incredibly valuable, >> standardization of items 4-5 of dubious value, and standardization or >> implementation of items 6-7 to be a design error in most cases. > > Let's grant that for argument's sakes. Does any harm come from > standardizing APIs/ABIs? It happens all the time outside the IETF. > Are you merely objecting the IETF as the SDO for APIs/ABIs? Did harm > actually follow from our having done so? Absolutely. When a de-facto standard API/implementation for a technology arises and it has poor behavior in practice, it taints the implementer experience around that technology. This has happened time and time again. Good protocols that have inappropriately gained a negative reputation due to poor implementation/API design issues include: IMAP, LDAP, Kerberos and GSS. I have no objection to developing an API in a standards organization, as long as it's at least a good API. GSS-API is not a good API. The model and protocol elements are fine and should be reused when appropriate, but the API stinks and I'll avoid using it whenever possible. I have the same opinion when it comes to SASL. The SASL API that I designed years ago is not a good API either, but I've found the SASL model incredibly valuable and useful in practice. > Why is it > OK to ask for the use of ABNF for specifying message forms, say, but > not to have a similar tool for specifying protocol flows and options? I would support development and/or use of a good tool for specifying protocol flows, states and options. I don't think the API portion of GSS-API is a good tool for this purpose. - Chris From nathan@webr3.org Wed Jul 18 08:30:10 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA67B21F86DC for ; Wed, 18 Jul 2012 08:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Td-PWarEv-x for ; Wed, 18 Jul 2012 08:30:09 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9857921F863D for ; Wed, 18 Jul 2012 08:30:08 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1023122wgb.13 for ; Wed, 18 Jul 2012 08:30:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=NGfAErsRKGAELPJT6txgFjrxHhG3+gZBD3p1xd6hre0=; b=a9WE8AUwP9feoP9MXmSFtAW2LZSfIBoD0k+CjdGCk4AGhBydMggSWUcMyB+LXdf3Hh LHqzQpo9NYCG7yWkZ2936kBgiyAu9ZxX28GURt0WT+EqkHVAWZiqjvOYNzw7WXUuRkXP RMmzW7nyFDLk8fxhTZPVypWKw7I5h+hDGhPy+sFPNSzo8yuhWlC36Ll15lMoUVLlOlIu cSmitQ7KUfzevooswM2Kfrl202wkIpYUE8EjqbahIZzF6L77B0ZQkhPP//7bVd1FH3t8 F6+GOyhFfV1guSmV/olAchTaV3fXEyYFgmm7VCR+VJOFyKm1FDGLYXxeCAUqbMuE3b7Q cHuA== Received: by 10.216.193.166 with SMTP id k38mr717251wen.200.1342625458488; Wed, 18 Jul 2012 08:30:58 -0700 (PDT) Received: from [192.168.1.68] (host81-152-134-57.range81-152.btcentralplus.com. [81.152.134.57]) by mx.google.com with ESMTPS id j6sm49005856wiy.4.2012.07.18.08.30.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jul 2012 08:30:57 -0700 (PDT) Message-ID: <5006D6A4.8030700@webr3.org> Date: Wed, 18 Jul 2012 16:30:44 +0100 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Nico Williams References: <5096375474F148B9EF159D55@96B2F16665FF96BAE59E9B90> <5004AC5B.3040701@webr3.org> <5005CA0B.3000400@webr3.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn+81gwCgKfSfA+Asi4r3omyHfiOKwuX/tgv5fgUiEiHesukSJ0tHsCIQIWoOQjjmRBCD+u Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nathan@webr3.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:30:10 -0000 Nico Williams wrote: > On Tue, Jul 17, 2012 at 3:24 PM, Nathan wrote: >> Nico Williams wrote: >>> Every cryptographic authentication protocol ever devised involves some >>> exchange of authentication messages. GSS, SASL, EAP, SSHv2, IKEv*, >>> TLS -- all of these have a such a thing. >>> >>> GSS_Init_sec_context() and GSS_Accept_sec_context() are an abstract >>> API to just that exchange of authentication messages. >> can you summarise their functionality for me? (even though it's fairly >> obvious) > > GSS_Init/Accept_sec_context() drive the exchange of authentication > messages ("security context tokens" in GSS speak). Thanks, I'll reply in full later on, if needed, however I think I just stumbled upon something which would be a natural blocker for me to even consider using this, and on which I need your comments. It appears to me that this whole thing is premised on there being "one" peer in the server role, indicated by 'login-uri = relativeURI', and the assumption that the server delivering the requested resource (that which requires auth) has access to the security context. The thing is, in almost every website / application I make, there are multiple (physical and virtual) servers, and the setup would need to involve two peers in the server roles - additionally often this is delegated to SSO servers, or via third parties as in oath and openid. Can you explain how this would work when there are three machines involved: C - Client DS - Document Server AS - Authorisation Server C requests a document from DS, DS says that it needs authorisation and points the client to AS ...?????.... Cheers, Nathan From mrex@sap.com Wed Jul 18 08:43:38 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EB021F86BD for ; Wed, 18 Jul 2012 08:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyf17+p7MD2d for ; Wed, 18 Jul 2012 08:43:37 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2FB21F8697 for ; Wed, 18 Jul 2012 08:43:37 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q6IFiN95015932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jul 2012 17:44:23 +0200 (MEST) In-Reply-To: <5006D6A4.8030700@webr3.org> To: nathan@webr3.org Date: Wed, 18 Jul 2012 17:44:22 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120718154422.EE1341A0DF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:43:38 -0000 Nathan wrote: > > Nico Williams wrote: > > > > GSS_Init/Accept_sec_context() drive the exchange of authentication > > messages ("security context tokens" in GSS speak). > > Thanks, I'll reply in full later on, if needed, however I think I just > stumbled upon something which would be a natural blocker for me to even > consider using this, and on which I need your comments. > > It appears to me that this whole thing is premised on there being "one" > peer in the server role, indicated by 'login-uri = relativeURI', and the > assumption that the server delivering the requested resource (that which > requires auth) has access to the security context. > > The thing is, in almost every website / application I make, there are > multiple (physical and virtual) servers, and the setup would need to > involve two peers in the server roles - additionally often this is > delegated to SSO servers, or via third parties as in oath and openid. > > Can you explain how this would work when there are three machines involved: > C - Client > DS - Document Server > AS - Authorisation Server > > C requests a document from DS, > DS says that it needs authorisation and points the client to AS > ...?????.... Such an exchange does not exist. When the process of authenticating client/initiator to server/acceptor requires communication with third parties, then any such communication would have to be performed by the GSS-API mechanism "under the covers" during gss_init_sec_context() on the client side or during gss_accept_sec_context() on the server side. Take Kerberos 5 as an example, where an authentication between client and server (traditionally) uses a two token exchange: an AP_REQ token client -> server and AP_REP token server -> client in response. In order for the client to produce an AP_REQ token, the client needs to already have a kerberos ticket for the server available, or the client will have to perform a TGS_REQ/TGS_REP exchange with the KDC under the covers during gss_init_sec_context(). When a (Microsoft) PAC in the service ticket is to be used by the server, then the server might perform a communication under the covers during gss_accept_sec_context() with Active Directory to validate the PAC from the service ticket. For the application on top of GSS-API, there exist only the two communication peers client/initiator and server/acceptor. -Martin From simo@redhat.com Wed Jul 18 08:54:13 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B0021F8736 for ; Wed, 18 Jul 2012 08:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1yGFU3L7X9d for ; Wed, 18 Jul 2012 08:53:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id B02D121F8735 for ; Wed, 18 Jul 2012 08:53:56 -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 q6IFskkV003404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jul 2012 11:54:46 -0400 Received: from [10.3.113.48] (ovpn-113-48.phx2.redhat.com [10.3.113.48]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q6IFsjst000995; Wed, 18 Jul 2012 11:54:46 -0400 From: Simo Sorce To: mrex@sap.com In-Reply-To: <20120718154422.EE1341A0DF@ld9781.wdf.sap.corp> References: <20120718154422.EE1341A0DF@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Wed, 18 Jul 2012 11:54:45 -0400 Message-ID: <1342626885.3219.111.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:54:14 -0000 On Wed, 2012-07-18 at 17:44 +0200, Martin Rex wrote: > Nathan wrote: > > > > Nico Williams wrote: > > > > > > GSS_Init/Accept_sec_context() drive the exchange of authentication > > > messages ("security context tokens" in GSS speak). > > > > Thanks, I'll reply in full later on, if needed, however I think I just > > stumbled upon something which would be a natural blocker for me to even > > consider using this, and on which I need your comments. > > > > It appears to me that this whole thing is premised on there being "one" > > peer in the server role, indicated by 'login-uri = relativeURI', and the > > assumption that the server delivering the requested resource (that which > > requires auth) has access to the security context. > > > > The thing is, in almost every website / application I make, there are > > multiple (physical and virtual) servers, and the setup would need to > > involve two peers in the server roles - additionally often this is > > delegated to SSO servers, or via third parties as in oath and openid. > > > > Can you explain how this would work when there are three machines involved: > > C - Client > > DS - Document Server > > AS - Authorisation Server > > > > C requests a document from DS, > > DS says that it needs authorisation and points the client to AS > > ...?????.... > > Such an exchange does not exist. Martin I would refrain from such absolutes because they are certainly wrong. The scenario Nathan describes above is quite common. > When the process of authenticating client/initiator to server/acceptor > requires communication with third parties, then any such communication > would have to be performed by the GSS-API mechanism "under the covers" > during gss_init_sec_context() on the client side or during > gss_accept_sec_context() on the server side. I think you misunderstand what Nathan is saying, Nathan is talking about application level behavior not authentication protocol behavior. Simo. -- Simo Sorce * Red Hat, Inc * New York From nathan@webr3.org Wed Jul 18 08:56:32 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BB811E808F for ; Wed, 18 Jul 2012 08:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV1hlSsOQE6v for ; Wed, 18 Jul 2012 08:56:31 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4499921F8735 for ; Wed, 18 Jul 2012 08:56:31 -0700 (PDT) Received: by weyu54 with SMTP id u54so1224550wey.31 for ; Wed, 18 Jul 2012 08:57:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=cI7c+aoouUkHzmZRHtiCC3+YbnI97BqXREF3PjY6FfA=; b=KrykUCEyfKkp8rRP+9RFPxtdVehl5LE7Hz6euhZcV6Jt1roHLdhmF5Mbdd1vbJGXKr vQBo/Fv/E8+GXXBxsjgVitgyIKws5ioR3Gjl1z4T+e49lANtrfxpeqUwkIZEV/9W22Cu kAdba+Fto8vEToyFsiClAUw9+JcpwzGkjiUsEsl0EU4CYtByELNDWwM4fbjHs61mCyLJ Uz22QitJYs99cyDF9a1MGpZoGF1TxcB+vdzmLkteeRBRsJfxCLx+obu3VQJeZNXkBqQ7 Z0A6t/tSKgIJ3BLcNPHcV8EKTrhXper3VrZdNtv+IXb/hSR4WexQb0CCasJ+5BCC1n0Y +gDw== Received: by 10.180.81.165 with SMTP id b5mr7650084wiy.17.1342627041285; Wed, 18 Jul 2012 08:57:21 -0700 (PDT) Received: from [192.168.1.68] (host81-152-134-57.range81-152.btcentralplus.com. [81.152.134.57]) by mx.google.com with ESMTPS id el6sm33171761wib.8.2012.07.18.08.57.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jul 2012 08:57:20 -0700 (PDT) Message-ID: <5006DCD7.80001@webr3.org> Date: Wed, 18 Jul 2012 16:57:11 +0100 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: mrex@sap.com References: <20120718154422.EE1341A0DF@ld9781.wdf.sap.corp> In-Reply-To: <20120718154422.EE1341A0DF@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmJXZePeIuRPf6GvubT0wUcQ0/G+CiDCndSbf5f8if+JBW9oyO9vYx2cmj+S6ZKHR2PcDK1 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nathan@webr3.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:56:33 -0000 Martin Rex wrote: > Nathan wrote: >> Nico Williams wrote: >>> GSS_Init/Accept_sec_context() drive the exchange of authentication >>> messages ("security context tokens" in GSS speak). >> Thanks, I'll reply in full later on, if needed, however I think I just >> stumbled upon something which would be a natural blocker for me to even >> consider using this, and on which I need your comments. >> >> It appears to me that this whole thing is premised on there being "one" >> peer in the server role, indicated by 'login-uri = relativeURI', and the >> assumption that the server delivering the requested resource (that which >> requires auth) has access to the security context. >> >> The thing is, in almost every website / application I make, there are >> multiple (physical and virtual) servers, and the setup would need to >> involve two peers in the server roles - additionally often this is >> delegated to SSO servers, or via third parties as in oath and openid. >> >> Can you explain how this would work when there are three machines involved: >> C - Client >> DS - Document Server >> AS - Authorisation Server >> >> C requests a document from DS, >> DS says that it needs authorisation and points the client to AS >> ...?????.... > > Such an exchange does not exist. > > When the process of authenticating client/initiator to server/acceptor > requires communication with third parties, then any such communication > would have to be performed by the GSS-API mechanism "under the covers" > during gss_init_sec_context() on the client side or during > gss_accept_sec_context() on the server side. > > Take Kerberos 5 as an example, where an authentication between client > and server (traditionally) uses a two token exchange: > an AP_REQ token client -> server and AP_REP token server -> client > in response. In order for the client to produce an AP_REQ token, > the client needs to already have a kerberos ticket for the server > available, or the client will have to perform a TGS_REQ/TGS_REP > exchange with the KDC under the covers during gss_init_sec_context(). > > When a (Microsoft) PAC in the service ticket is to be used by the server, > then the server might perform a communication under the covers during > gss_accept_sec_context() with Active Directory to validate the PAC > from the service ticket. > > For the application on top of GSS-API, there exist only the two communication > peers client/initiator and server/acceptor. That's what I thought, I can't see how it would be possible to make GSS RESTful given these constraints, it seems to contradict the ethos of the uniform interface - we need the solution to be stateless, uniform, and something which hides implementation details, such that it doesn't matter whether there are 1 or 1000 physical/virtual servers/proxies hiding behind the interface exposed by HTTP (or any RESTful protocol). From nico@cryptonector.com Wed Jul 18 09:03:41 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5179421F8720 for ; Wed, 18 Jul 2012 09:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.363 X-Spam-Level: X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[AWL=-1.386, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtwVOs9RV2ns for ; Wed, 18 Jul 2012 09:03:40 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 5162B21F8675 for ; Wed, 18 Jul 2012 09:03:28 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 199319406E for ; Wed, 18 Jul 2012 09:04:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=vM6rcv72/kzwS1edQyAck X2CELGHY442L0rHBSpANsZj+A9eGvdxUK8Tf+8vuHb3ft4wHZoiGWSK88f6mgV62 dQk/j9w/Iz4ane/6V+Sm8Y62NAYPYanimT0WyLgXqGZs4bYZUBndlZ8R3wrDLViG on/ZQnzjzsxca+J0912UCc= 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=WoGyj087+uuznnykLxn6 JBilLF4=; b=cZ1VOBLDsNquJcK28mMsniWtcdRnL6Nn/EnV31IA27UdEb6LUn1d u4hVCX/Wu1vmOU2pSEv9xrQD+Ol3rh5ESHkqHDjt/bnkmVLhwbcZGTSwbMFEcM7h QA7WreLfmV64HUgVZazNlvlf1NAN4TGvwSTsbdeSYzeqPtlEzWeqHPk= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id EAA6A94076 for ; Wed, 18 Jul 2012 09:04:18 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2908933pbc.31 for ; Wed, 18 Jul 2012 09:04:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.36 with SMTP id qz4mr8328994pbc.161.1342627458588; Wed, 18 Jul 2012 09:04:18 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Wed, 18 Jul 2012 09:04:18 -0700 (PDT) In-Reply-To: <5006DCD7.80001@webr3.org> References: <20120718154422.EE1341A0DF@ld9781.wdf.sap.corp> <5006DCD7.80001@webr3.org> Date: Wed, 18 Jul 2012 11:04:18 -0500 Message-ID: From: Nico Williams To: nathan@webr3.org Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:03:41 -0000 On Wed, Jul 18, 2012 at 10:57 AM, Nathan wrote: > That's what I thought, I can't see how it would be possible to make GSS > RESTful given these constraints, it seems to contradict the ethos of the > uniform interface - we need the solution to be stateless, uniform, and > something which hides implementation details, such that it doesn't matter > whether there are 1 or 1000 physical/virtual servers/proxies hiding behind > the interface exposed by HTTP (or any RESTful protocol). REST-GSS has a stateless mode where the state is kept in an encrypted state ticket that is carried in every client request. This mode can't do replay protection. This mode *can* more easily share a single session across many servers (though the alternative, with absolute session URIs, can also result in sessions spanning many servers if those servers can access the shared resource). Nico -- From nico@cryptonector.com Wed Jul 18 09:06:58 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1339311E80AA for ; Wed, 18 Jul 2012 09:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[AWL=-1.368, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwF2OyxqN+DT for ; Wed, 18 Jul 2012 09:06:57 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9729311E809B for ; Wed, 18 Jul 2012 09:06:57 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 2505E1006E for ; Wed, 18 Jul 2012 09:07:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=ukOsx7960AHrPBoQE2USb Ubh1BunZfehT270hH3/3J42aF+aUTirKIwW10/0TbyDuGP/o/jt/x4kl28XKiRHX hK4BpDVzjKP2VqHQVeoIfXcxumrxauH7kfR3tAvN0lJtW2NKyDW+SRWvPt8uV/K4 1Twm9zb1A/8O2sSur/pLyo= 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=VC8x+ppk77K4sMhP80jb 4HjyfTQ=; b=hckLd3czskivr6g+VeX8ag7od+pNJnNaMIO/hH1zEDHbiiwx4Wn7 BE38t6Al12HKDxVVHV/Au534ZYP77GajIOBRn6nGum5/i0W4LoDWqsQXlcNhtuF6 7KgJCXklNlih8zK7zJIlVOF69lv/LAomqrrG4YQOd/z7zUEbO1rE6X0= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 0AEAC1006D for ; Wed, 18 Jul 2012 09:07:48 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2912961pbc.31 for ; Wed, 18 Jul 2012 09:07:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.36 with SMTP id qz4mr8311208pbc.161.1342627292408; Wed, 18 Jul 2012 09:01:32 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Wed, 18 Jul 2012 09:01:32 -0700 (PDT) In-Reply-To: <5006D6A4.8030700@webr3.org> References: <5096375474F148B9EF159D55@96B2F16665FF96BAE59E9B90> <5004AC5B.3040701@webr3.org> <5005CA0B.3000400@webr3.org> <5006D6A4.8030700@webr3.org> Date: Wed, 18 Jul 2012 11:01:32 -0500 Message-ID: From: Nico Williams To: nathan@webr3.org Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:06:58 -0000 On Wed, Jul 18, 2012 at 10:30 AM, Nathan wrote: > It appears to me that this whole thing is premised on there being "one" peer > in the server role, indicated by 'login-uri = relativeURI', and the > assumption that the server delivering the requested resource (that which > requires auth) has access to the security context. I just added the relativeURI thing, but it seemed wrong. Yes, I think we want sessions to have "scope" that can span many servers (in one domain). I can't change this till next week. > Can you explain how this would work when there are three machines involved: > C - Client > DS - Document Server > AS - Authorisation Server > > C requests a document from DS, > DS says that it needs authorisation and points the client to AS > ...?????.... I'd expect that DS just runs through REST-GSS and returns a session URI (which cannot be relative) and just performs the authorization itself. In general I expect authorization to be done at each resource. REST-GSS with absolute session URIs can cope with separating where authentication happens from where authorization happens, but it does nothing to make it possible to do authorization on servers that are not the ones where the resources being accessed are -- for that we'd want "capabilities", say, but does one want a couple of redirects for every resource being accessed?? Nico -- From nathan@webr3.org Wed Jul 18 09:12:03 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D033221F867B for ; Wed, 18 Jul 2012 09:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbdqSoh98x5g for ; Wed, 18 Jul 2012 09:12:03 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA2B321F86DC for ; Wed, 18 Jul 2012 09:12:02 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1052176wgb.13 for ; Wed, 18 Jul 2012 09:12:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=JxRByXuMzvGkjN7QUd/bS50ojRynGimdmsJFQQhGjmY=; b=mTchqiPQzZ6McNmJ/zY0IoLYm5AFb445VWYynnf6SNOm+E1YVyuIYpH6316r+r0qtn vAj/KBKDiKE2wJniCtLC5LmSTrdrVXVdWtLL8KBxlKzEOXx4BpIZTUf294Fw5eR7lCKE TSCh3pNlLYiMoVZrp4hLCu3KBRo3kfhYJzPou9yHQrn+FwPXBPmrLp+lFiOGpU0nYvrD /3lqCAI/689Mu2TjWT1k+I4Vc4dgr69xVTR4168WrQxG+XK3jnLBiM4y4MNlJfUV4jXv wtnMaC7WeRZKwckPREtn8U5NqmPSAyhv/oXrXKusWKExAmpCbirYjLg2npGHMnbj7GTL stcQ== Received: by 10.180.86.106 with SMTP id o10mr7911030wiz.22.1342627972817; Wed, 18 Jul 2012 09:12:52 -0700 (PDT) Received: from [192.168.1.68] (host81-152-134-57.range81-152.btcentralplus.com. [81.152.134.57]) by mx.google.com with ESMTPS id k20sm33292790wiv.11.2012.07.18.09.12.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jul 2012 09:12:52 -0700 (PDT) Message-ID: <5006E07B.1070104@webr3.org> Date: Wed, 18 Jul 2012 17:12:43 +0100 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Nico Williams References: <5096375474F148B9EF159D55@96B2F16665FF96BAE59E9B90> <5004AC5B.3040701@webr3.org> <5005CA0B.3000400@webr3.org> <5006D6A4.8030700@webr3.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkWmtjxQyhNKmNvZ48ykNgsmLmZKuJjF9ZIn5LDN5Zz9M1i9d2yRO2knPZ6z7SAs8KX/2r2 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nathan@webr3.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:12:03 -0000 Nico Williams wrote: > On Wed, Jul 18, 2012 at 10:30 AM, Nathan wrote: >> It appears to me that this whole thing is premised on there being "one" peer >> in the server role, indicated by 'login-uri = relativeURI', and the >> assumption that the server delivering the requested resource (that which >> requires auth) has access to the security context. > > I just added the relativeURI thing, but it seemed wrong. Yes, I think > we want sessions to have "scope" that can span many servers (in one > domain). I can't change this till next week. > >> Can you explain how this would work when there are three machines involved: >> C - Client >> DS - Document Server >> AS - Authorisation Server >> >> C requests a document from DS, >> DS says that it needs authorisation and points the client to AS >> ...?????.... > > I'd expect that DS just runs through REST-GSS and returns a session > URI (which cannot be relative) and just performs the authorization > itself. In general I expect authorization to be done at each > resource. REST-GSS with absolute session URIs can cope with > separating where authentication happens from where authorization > happens, but it does nothing to make it possible to do authorization > on servers that are not the ones where the resources being accessed > are -- for that we'd want "capabilities", say, but does one want a > couple of redirects for every resource being accessed?? I have a feeling that a continuation of this thought train would just end up at OAuth(2). ? From mrex@sap.com Wed Jul 18 09:13:02 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C368021F8778 for ; Wed, 18 Jul 2012 09:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhRgJ+CB0PTD for ; Wed, 18 Jul 2012 09:12:57 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8A71E21F8737 for ; Wed, 18 Jul 2012 09:12:57 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q6IGDkCZ018536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jul 2012 18:13:47 +0200 (MEST) In-Reply-To: <1342626885.3219.111.camel@willson.li.ssimo.org> To: Simo Sorce Date: Wed, 18 Jul 2012 18:13:46 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120718161346.783F11A0DF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:13:02 -0000 Simo Sorce wrote: > > > > > > Can you explain how this would work when there are three machines involved: > > > C - Client > > > DS - Document Server > > > AS - Authorisation Server > > > > > > C requests a document from DS, > > > DS says that it needs authorisation and points the client to AS > > > ...?????.... > > > > Such an exchange does not exist. > > Martin I would refrain from such absolutes because they are certainly > wrong. > > The scenario Nathan describes above is quite common. I'm sorry for the misunderstanding, I did not intend to offend anyone. This was meant to say: At the abstract model of the GSS-API that is exposed to the application, such an exchange does not exist. > > I think you misunderstand what Nathan is saying, Nathan is talking about > application level behavior not authentication protocol behavior. I believe I understand his example. That's why I described the situation for Kerberos 5, which always involves _at_least_ 3 parties at the lower protocol levels, but appears as just initiator and acceptor at the GSS-API for the application. Any additional complexity necessary to implement a "gss-api mechanism" can only use the initial token exchange between client/initiator and server/acceptor, and the gssapi mechanism must do all other communication, that might be necessary, under the covers. In special situations, it could be a communication to a third party that a client needs, but which can only be performed by the server. So a special gss-api mechanism could extend the authentication token exchange to first forward the request from client to server, have the server perform the communication with the third party under the covers during gss_accept_sec_context() and return the result in a gssapi context token to the client. One such example is "Initial Authentication for Kerberos (IAKERB)" http://tools.ietf.org/html/draft-ietf-krb-wg-iakerb-02 -Martin -Martin From simo@redhat.com Wed Jul 18 09:29:06 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B49D11E80A6 for ; Wed, 18 Jul 2012 09:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.266 X-Spam-Level: X-Spam-Status: No, score=-109.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT+VlRWvGeid for ; Wed, 18 Jul 2012 09:29:05 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 105D311E809A for ; Wed, 18 Jul 2012 09:29:04 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6IGTtsb019398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jul 2012 12:29:55 -0400 Received: from [10.3.113.48] (ovpn-113-48.phx2.redhat.com [10.3.113.48]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q6IGTsJP022960; Wed, 18 Jul 2012 12:29:54 -0400 From: Simo Sorce To: mrex@sap.com In-Reply-To: <20120718161346.783F11A0DF@ld9781.wdf.sap.corp> References: <20120718161346.783F11A0DF@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Wed, 18 Jul 2012 12:29:53 -0400 Message-ID: <1342628993.3219.112.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:29:07 -0000 On Wed, 2012-07-18 at 18:13 +0200, Martin Rex wrote: > Simo Sorce wrote: > > > > > > > > Can you explain how this would work when there are three machines involved: > > > > C - Client > > > > DS - Document Server > > > > AS - Authorisation Server > > > > > > > > C requests a document from DS, > > > > DS says that it needs authorisation and points the client to AS > > > > ...?????.... > > > > > > Such an exchange does not exist. > > > > Martin I would refrain from such absolutes because they are certainly > > wrong. > > > > The scenario Nathan describes above is quite common. > > I'm sorry for the misunderstanding, I did not intend to offend anyone. > > This was meant to say: > > At the abstract model of the GSS-API that is exposed to the application, > such an exchange does not exist. > > > > > > I think you misunderstand what Nathan is saying, Nathan is talking about > > application level behavior not authentication protocol behavior. > > I believe I understand his example. That's why I described the > situation for Kerberos 5, which always involves _at_least_ 3 parties > at the lower protocol levels, but appears as just initiator and acceptor > at the GSS-API for the application. My time to apologize, I misunderstood your point. Simo. -- Simo Sorce * Red Hat, Inc * New York From nico@cryptonector.com Wed Jul 18 09:34:40 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76FC11E80ED for ; Wed, 18 Jul 2012 09:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[AWL=-1.349, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWXm1-dNo5zq for ; Wed, 18 Jul 2012 09:34:40 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3439911E80D9 for ; Wed, 18 Jul 2012 09:34:40 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id BD5191E05D for ; Wed, 18 Jul 2012 09:35:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=RHuc8K95laKQMA3y67LMS DHwkgVS1V1M5j1qfn+VGsWHU50PVIgen5/gJIe+BTzoH3+K1gGVkBUCSWvgsM52i bXwCAWFJVgTDrI/S477z2KMHEa8U9wQ+bWDkOzipu6VZizDlds3UkOhG39Lltn/F H43OEV8p+HUXmZNnsKnmMU= 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=j/ItLhpFn1HeRXFpmRyB NkiSEMg=; b=CogHrmcXk+1Oh5VtWenGuTeKm6IoPtFPOZ6rjJTtVW3WQD/ptGx3 y8tAcxN3zK/B08+Jivn9DcZ0MnFnCRhIWGoqJLxDduJGEdN5SJMPEYuydg7b1ze2 fD9cypjZVqXbN1i4nUNiLZKY6zZv+bOmN+S5qxI0loFUganVgztmFRM= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 99F751E059 for ; Wed, 18 Jul 2012 09:35:30 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2945701pbc.31 for ; Wed, 18 Jul 2012 09:35:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.220.39 with SMTP id pt7mr9181140pbc.40.1342629330122; Wed, 18 Jul 2012 09:35:30 -0700 (PDT) Received: by 10.143.29.16 with HTTP; Wed, 18 Jul 2012 09:35:30 -0700 (PDT) In-Reply-To: <20120718161346.783F11A0DF@ld9781.wdf.sap.corp> References: <1342626885.3219.111.camel@willson.li.ssimo.org> <20120718161346.783F11A0DF@ld9781.wdf.sap.corp> Date: Wed, 18 Jul 2012 11:35:30 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Simo Sorce Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:34:40 -0000 On Wed, Jul 18, 2012 at 11:13 AM, Martin Rex wrote: > I'm sorry for the misunderstanding, I did not intend to offend anyone. I was not offended... However, I do think that you're missing context. And, of course, to the extent that you dislike all GSS extensions (all outside RFCs 2743/2744, since my proposal depends on some, you might not like it (but the extensions ship has sailed). > This was meant to say: > > At the abstract model of the GSS-API that is exposed to the application, > such an exchange does not exist. Indeed. However, one can build applications that work in this way. The problem I have with Nathan's scenario is that I doubt he envisions authorizing access to every resources in this way. Instead I suspect that this only happens occasionally in his scenario. Nico -- From mrex@sap.com Wed Jul 18 09:57:34 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0EC11E8124 for ; Wed, 18 Jul 2012 09:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3Yqq9p7DRRN for ; Wed, 18 Jul 2012 09:57:33 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9151611E80D9 for ; Wed, 18 Jul 2012 09:57:33 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q6IGwK0A005147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jul 2012 18:58:20 +0200 (MEST) In-Reply-To: To: Nico Williams Date: Wed, 18 Jul 2012 18:58:19 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120718165819.DDDA61A0DF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org, Simo Sorce Subject: Re: [kitten] Simplified/minimized GSS-API profiles X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:57:34 -0000 Nico Williams wrote: > > Martin Rex wrote: >> >> I'm sorry for the misunderstanding, I did not intend to offend anyone. > > I was not offended... However, I do think that you're missing > context. And, of course, to the extent that you dislike all GSS > extensions (all outside RFCs 2743/2744, since my proposal depends on > some, you might not like it (but the extensions ship has sailed). I'm OK with extensions of the GSS-API! I just want to point out which of the extensions that you mentioned are typically unavailable in the installed base of GSS-API mechanisms. While support for hostbased service names is available in pretty much all Kerberos and Kerberos-derived GSS-API mechanisms in the installed base, none of the other functionality is. With installed base, i mean Microsoft Kerberos in Win7/2008R2, Vista, older, Kerberos included in (Enterprise) Linux Distros, Kerberos included in HP-UX 11.31, SunOS 5.10, AIX 6.1, ... Quest's Vintela, DCE (where it isn't extinct) ... > > > This was meant to say: > > > > At the abstract model of the GSS-API that is exposed to the application, > > such an exchange does not exist. > > Indeed. However, one can build applications that work in this way. But that has nothing to do with GSS-API then. Of course one can extend the GSS-API in various proprietary and mechanism- specific ways, but that usually means that no "portable application" that was designed to use GSS-API for authentication, will use/work with such extensions. And if your application protocols are made vitally dependent on such extensions being available, you'll run into problems if you try to plug'n'play other GSS-API mechanisms as alternatives that do not support these extensions. -Martin From simon@josefsson.org Thu Jul 19 07:29:22 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B220C21F8738 for ; Thu, 19 Jul 2012 07:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op+yjf9ZZe6F for ; Thu, 19 Jul 2012 07:29:22 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6E121F8775 for ; Thu, 19 Jul 2012 07:29:20 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q6JETu9L024906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 Jul 2012 16:29:57 +0200 From: Simon Josefsson To: Chris Newman References: <5000104E.2000607@angry-red-pla.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120719:kitten@ietf.org::y08OdXnfxXgxur9F:STD X-Hashcash: 1:22:120719:latze@angry-red-pla.net::vDBtthIsxRM+/v8c:BGeY X-Hashcash: 1:22:120719:chris.newman@oracle.com::gTFNTFqsH/jQe5rt:OxQN Date: Thu, 19 Jul 2012 16:29:45 +0200 In-Reply-To: (Chris Newman's message of "Mon, 16 Jul 2012 11:30:08 -0700") Message-ID: <87629j3jty.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: Kitten@ietf.org Subject: Re: [kitten] draft-josefsson-sasl-external-channel-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 14:29:22 -0000 Chris, I share your concern, although the reason for not saying anything like what you suggest is that, today, EXTERNAL and EXTERNAL-TLS semantically are different beasts. I believe the EXTERNAL-TLS semantics are more useful. It seems the deployment you refer to support that notion as well: they use EXTERNAL precisely what we want EXTERNAL-TLS for. The problem is that EXTERNAL can be used for other things too, and there is no way of knowing which purpose was intended. To illustrate the problem, consider an application running over IPSEC that does IMAP with STARTTLS. The client see EXTERNAL announced from the server. The app wants to authenticate to the IMAP server using its TLS credentials. The app does not want to use its IPSEC credential to authenticate to the IMAP server. If it does 'AUTHENTICATE EXTERNAL' the client doesn't know which credential was used for authentication, and it isn't deterministic which account it was logged into. (This example does not use any authorization identity for simplicity, although this is the most common usage.) I believe the text you provided would be good, and we'd be happy to add it. There is another solution though: How do you feel about revising the EXTERNAL mechanism specification to say that it refers to the credentials negotiated under TLS, similar to what's in d-j-sasl-external-channel? Currently EXTERNAL refers to anything outside of the application protocol, and to get security and interoperability, client and server need to negotiate out of band what is intended. Compare how we "updated" the GSSAPI mechanism to be for Kerberos V5 only. We could update EXTERNAL to be for TLS only, and permit future specification of EXTERNAL-SSH or EXTERNAL-IPSEC for "external" SASL authentication with other security protocols (if someone cares about that). I find EXTERNAL to be rarely used because applications cannot auto-detect when it is appropriate to use, and when it is used, in my experience it always means to use the TLS-negotiated credentials. The EXTERNAL-* idea is mostly to formalize one use-case for EXTERNAL. We could modify d-j-sasl-external-channel and say that for historical reasons EXTERNAL-TLS is actually called EXTERNAL, and then supersede Appendix A of RFC 4422 with this document. The only problem this would cause, that I can identify, is if someone is using EXTERNAL to mean IPSEC or some other security protocol. Is anyone aware of any such usage? If we can get consensus on updating EXTERNAL, that would be fine, but if that doesn't happen I think adding the text you provided is a good compromise. Revising EXTERNAL may bring up other issues that I haven't thought about though, so that is why I have hesitated. /Simon Chris Newman writes: > I'm very dubious of this claim in the abstract. > >> This has impacted the interoperability of the EXTERNAL mechanism. > > Perhaps that claim should be either removed or supported with > documentation in an appendix. > > > We're also in a situation where we're just starting to get partial > interoperability of TLS client certificate authentication with SASL > EXTERNAL in the installed base of Internet email services (there have > been numerous interoperability problems in that space, although I'm > not aware of any problems due to the specification of the EXTERNAL > mechanism). > > I'm concerned that muddying the waters by introducing EXTERNAL-TLS may > produce more interoperability problems. However, that concern would be > largely mitigated if this document added a statement along the lines > of: > > Clients that use EXTERNAL-TLS SHOULD be able to use EXTERNAL for the > same purpose in > order to interoperate with deployed server software that presently > only implements > EXTERNAL for use with TLS. > > Servers that advertise EXTERNAL-TLS SHOULD also advertise EXTERNAL in > order to > interoperate with deployed client software that presently only > implements EXTERNAL. > > - Chris > > --On July 13, 2012 14:10:54 +0200 Carolin Latze > wrote: > >> Hi all, >> >> we just uploaded a new version of the >> draft-josefsson-sasl-external-channel: >> >> http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel >> -05.txt >> >> This is an upgrade of a pretty old draft which has been discussed on the >> SASL list in the past: >> >> http://www.ietf.org/mail-archive/web/sasl/current/msg00427.html >> >> By then, the main issue was the lack of an use case which we believe we >> found now. We came with the requirement to use multiple certificates >> within the same authentication exchange. Some applications (like BYOD in >> some companies) want to make use of an user and a device authentication. >> Access should only be granted if user *and* device can be authenticated. >> One way to do that is to set up a secure tunnel where you authenticate >> the device and then run user authentication inside that tunnel. However >> that costs some resources. Therefore, we upgraded the I-D to allow for >> chained, renegotiated TLS handshakes in the EXTERNAL-TLS mechanism to >> support this use case. >> >> Best regards >> Carolin >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten >> From chris.newman@oracle.com Fri Jul 20 09:30:55 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AF521F85D2 for ; Fri, 20 Jul 2012 09:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHTH47oM8zEC for ; Fri, 20 Jul 2012 09:30:51 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id E4A0121F85D5 for ; Fri, 20 Jul 2012 09:30:50 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6KGVYoL017625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jul 2012 16:31:35 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6KGVX19023070; Fri, 20 Jul 2012 16:31:34 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7u5-4.06 64bit (built Mar 14 2012)) with ESMTPA id <0M7G00L4RWKFDS00@gotmail.us.oracle.com>; Fri, 20 Jul 2012 09:31:32 -0700 (PDT) Date: Fri, 20 Jul 2012 08:45:15 -0700 From: Chris Newman To: Simon Josefsson Message-id: <7E7509CFA6720310B98847D3@96B2F16665FF96BAE59E9B90> In-reply-to: <87629j3jty.fsf@latte.josefsson.org> References: <5000104E.2000607@angry-red-pla.net> <87629j3jty.fsf@latte.josefsson.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Kitten@ietf.org Subject: Re: [kitten] draft-josefsson-sasl-external-channel-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 16:30:56 -0000 --On July 19, 2012 16:29:45 +0200 Simon Josefsson wrote: > I share your concern, although the reason for not saying anything like > what you suggest is that, today, EXTERNAL and EXTERNAL-TLS semantically > are different beasts. I believe the EXTERNAL-TLS semantics are more > useful. It seems the deployment you refer to support that notion as > well: they use EXTERNAL precisely what we want EXTERNAL-TLS for. > The problem is that EXTERNAL can be used for other things too, and there is > no way of knowing which purpose was intended. Honestly, I see no real-world problem here. Yes, there's a minor semantic difference between "use available credentials" and "use available TLS credentials" but I don't see why it would matter to a client that has gone through the trouble of being configured to provide TLS client certificates. > To illustrate the problem, consider an application running over IPSEC > that does IMAP with STARTTLS. The client see EXTERNAL announced from > the server. The app wants to authenticate to the IMAP server using its > TLS credentials. The app does not want to use its IPSEC credential to > authenticate to the IMAP server. If it does 'AUTHENTICATE EXTERNAL' the > client doesn't know which credential was used for authentication, and it > isn't deterministic which account it was logged into. (This example > does not use any authorization identity for simplicity, although this is > the most common usage.) I know of no such implementation, nor of anyone conceiving of such an implementation. First, no IMAP server will advertise EXTERNAL as a result of IPSEC. The problem is that IPSEC uses host credentials which can't be mapped to an end-user account (or if it uses end-user credentials, there's no standard API to get them from the OS), so it doesn't provide any useful credentials for end-user authentication purposes so any IMAP server that advertised EXTERNAL without a useful mapping to end-user credentials would be at least broken and probably incompliant. Even if IPSEC could provide end-user credentials, those credentials would almost always be the correct ones and the client need not worry. So your strawman presumes 4 unlikely events: 1. someone uses IPSEC. 2. IPSEC uses end-user credentials which imapd can access through a supported API. 3. The IPSEC end-user credentials differ from the mail account identity. 4. The client both cares which mail account is accessed and fails to provide the mail account authorization identity to the EXTERNAL mechanism. That scenario is at best an unlikely misconfiguration, if not a broken client. I still think this is all trying to solve a non-existent problem. > I believe the text you provided would be good, and we'd be happy to add > it. There is another solution though: > > How do you feel about revising the EXTERNAL mechanism specification to > say that it refers to the credentials negotiated under TLS, similar to > what's in d-j-sasl-external-channel? Currently EXTERNAL refers to > anything outside of the application protocol, and to get security and > interoperability, client and server need to negotiate out of band what > is intended. I would have no objection to this change. > Compare how we "updated" the GSSAPI mechanism to be for Kerberos V5 > only. We could update EXTERNAL to be for TLS only, and permit future > specification of EXTERNAL-SSH or EXTERNAL-IPSEC for "external" SASL > authentication with other security protocols (if someone cares about > that). > > I find EXTERNAL to be rarely used because applications cannot > auto-detect when it is appropriate to use, and when it is used, in my > experience it always means to use the TLS-negotiated credentials. There are two useful models for clients: 1. explicit end-user selected security mechanism/policy 2. latched auto-select security policy: the client looks for the best option that works, and records that it worked with that server and requires security at least that good in the future to prevent downgrade attacks. Most clients do 1 because it's much less complex to implement/debug even if it does leave the choice up to the end-user. On top of that, it's even more difficult to auto-select the intended client certificate (which client certificate is associated with which mail account?). So if you have to make the end-user manually configure TLS client cert authentication anyway, may as well keep the code simpler. The other problem is the wide deployment of non-interoperable protocols when it comes to TLS client certificate authentication. There are ones where we botched the IETF specifications (SMTP), so there are servers that require EXTERNAL, servers that disallow EXTERNAL and servers that do or don't use client certificate credentials as a side-effect of the STARTTLS command and there's usually no way for the client to tell the difference. Most SMTP clients are lazy and just send the TLS client certificate and hope it works. Then there's the non-standard imaps and pops protocols that have unspecified behavior (and often do not interoperate when it comes to client certificate authentication). At least there's no excuse for non-interoperable STARTTLS client certificate authentication in IMAP and POP because that was standardized unambiguously in 1999. Of course, there's also the problem that deploying and managing a certificate infrastructure is a huge amount of work so for most deployments the incremental security (if any) isn't worth the cost. I don't think making EXTERNAL more complex will improve deployment of TLS client certificate authentication. Frankly, spending time on DANE specification and implementation would probably be a better investment if the latter is your goal. > The EXTERNAL-* idea is mostly to formalize one use-case for EXTERNAL. > We could modify d-j-sasl-external-channel and say that for historical > reasons EXTERNAL-TLS is actually called EXTERNAL, and then supersede > Appendix A of RFC 4422 with this document. The only problem this would > cause, that I can identify, is if someone is using EXTERNAL to mean > IPSEC or some other security protocol. Is anyone aware of any such > usage? No. - Chris > If we can get consensus on updating EXTERNAL, that would be fine, but if > that doesn't happen I think adding the text you provided is a good > compromise. Revising EXTERNAL may bring up other issues that I haven't > thought about though, so that is why I have hesitated. > > /Simon > > Chris Newman writes: > >> I'm very dubious of this claim in the abstract. >> >>> This has impacted the interoperability of the EXTERNAL mechanism. >> >> Perhaps that claim should be either removed or supported with >> documentation in an appendix. >> >> >> We're also in a situation where we're just starting to get partial >> interoperability of TLS client certificate authentication with SASL >> EXTERNAL in the installed base of Internet email services (there have >> been numerous interoperability problems in that space, although I'm >> not aware of any problems due to the specification of the EXTERNAL >> mechanism). >> >> I'm concerned that muddying the waters by introducing EXTERNAL-TLS may >> produce more interoperability problems. However, that concern would be >> largely mitigated if this document added a statement along the lines >> of: >> >> Clients that use EXTERNAL-TLS SHOULD be able to use EXTERNAL for the >> same purpose in >> order to interoperate with deployed server software that presently >> only implements >> EXTERNAL for use with TLS. >> >> Servers that advertise EXTERNAL-TLS SHOULD also advertise EXTERNAL in >> order to >> interoperate with deployed client software that presently only >> implements EXTERNAL. >> >> - Chris >> >> --On July 13, 2012 14:10:54 +0200 Carolin Latze >> wrote: >> >>> Hi all, >>> >>> we just uploaded a new version of the >>> draft-josefsson-sasl-external-channel: >>> >>> http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-chann >>> el -05.txt >>> >>> This is an upgrade of a pretty old draft which has been discussed on the >>> SASL list in the past: >>> >>> http://www.ietf.org/mail-archive/web/sasl/current/msg00427.html >>> >>> By then, the main issue was the lack of an use case which we believe we >>> found now. We came with the requirement to use multiple certificates >>> within the same authentication exchange. Some applications (like BYOD in >>> some companies) want to make use of an user and a device authentication. >>> Access should only be granted if user *and* device can be authenticated. >>> One way to do that is to set up a secure tunnel where you authenticate >>> the device and then run user authentication inside that tunnel. However >>> that costs some resources. Therefore, we upgraded the I-D to allow for >>> chained, renegotiated TLS handshakes in the EXTERNAL-TLS mechanism to >>> support this use case. >>> >>> Best regards >>> Carolin >>> _______________________________________________ >>> Kitten mailing list >>> Kitten@ietf.org >>> https://www.ietf.org/mailman/listinfo/kitten >>> > From hartmans@mit.edu Mon Jul 23 08:03:20 2012 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F1A11E80A1 for ; Mon, 23 Jul 2012 08:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.567 X-Spam-Level: X-Spam-Status: No, score=-99.567 tagged_above=-999 required=5 tests=[AWL=-3.855, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbQeWBJO3p1U for ; Mon, 23 Jul 2012 08:03:20 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-76-251.compute-1.amazonaws.com [23.21.76.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2364C11E8091 for ; Mon, 23 Jul 2012 08:03:20 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 25D70201F4 for ; Mon, 23 Jul 2012 11:03:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4F45641F2; Mon, 23 Jul 2012 11:02:44 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org Date: Mon, 23 Jul 2012 11:02:44 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [kitten] [Klaas Wierenga] [abfab] WGLC on draft-ietf-abfab-gss-eap-naming-03 (ending August 3d 2012) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 15:03:20 -0000 --=-=-= Hi. This document defines some GSS-API name attributes useful to kitten as well as abfab mechanisms. So, it's useful to get kitten review as well. Comments to abfab@ietf.org please. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Thu, 19 Jul 2012 09:47:21 -0400 X-Sieve: CMU Sieve 2.2 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by mail.suchdamage.org (Postfix) with ESMTP id 8BAD42053A for ; Thu, 19 Jul 2012 09:47:20 -0400 (EDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEEF21F879C; Thu, 19 Jul 2012 06:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342705567; bh=+lJkoY7I3cSQ3TT0xR4925e5hAFh5IeJ4Gl9l4b8J4Q=; h=From:Date:Message-Id:To:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=GngXhvozwUTMoJIThkt35frBujaFFGftDVPE1tvCp4NtFJ9xGBNladxj2uKUTVV7J h+yjUV3LCmrisbwehQdDUSv7X9qI3utu4D622r9zh9PWeJxBzjyPz9N/23KOGPkgOR CnndHg/GuvPKKyJxvaWc1BuEvs5T4drtCGfeQT+c= X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC1321F879C for ; Thu, 19 Jul 2012 06:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnoCj2u1KWWo for ; Thu, 19 Jul 2012 06:46:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2A321F8769 for ; Thu, 19 Jul 2012 06:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=423; q=dns/txt; s=iport; t=1342705618; x=1343915218; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=UDj4d++ZgjG5lDm5HjejV1ZDeqUmLtRQ+Wtv80vqiF8=; b=P16eSgtgirEuz+/h/vfIcxnUYteBskIz92SeX7If2QDqtBFycG+g/c44 76T9yYncLaK/FX21HdPRY4EhdKewQPDGs3GWwlLJa2e6w85NlAqpx2TOE HDRQj9xkB28RA/0ldPqHcm18fsQqaopIc24FwXVEYCTdVftMdnGgn1cAy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUJAE0OCFCtJXHA/2dsb2JhbABFhDC1EYEHgjkBJ4F9NYdrC5x2gSigA4tMhjBgA5VEgRONEIFmgmE X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208";a="103209782" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 19 Jul 2012 13:46:52 +0000 Received: from rtp-kwiereng-8714.cisco.com (rtp-kwiereng-8714.cisco.com [10.116.7.37]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6JDkpGr016426 for ; Thu, 19 Jul 2012 13:46:51 GMT From: Klaas Wierenga Date: Thu, 19 Jul 2012 15:46:50 +0200 Message-Id: <81761770-8B74-47E1-A587-66BF36AE0401@cisco.com> To: "\" X-Mailer: Apple Mail (2.1278) Subject: [abfab] WGLC on draft-ietf-abfab-gss-eap-naming-03 (ending August 3d 2012) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: abfab-bounces@ietf.org Errors-To: abfab-bounces@ietf.org X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Jul 19 09:47:21 2012 X-DSPAM-Confidence: 0.9992 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,50080fe912174415420250 X-DSPAM-Factors: 27, From*Klaas Wierenga , 0.00010, List-Post*