From nobody Wed Jun 1 07:09:48 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC3712D527 for ; Wed, 1 Jun 2016 07:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FI0uqL_exCdN for ; Wed, 1 Jun 2016 07:09:39 -0700 (PDT) Received: from mailrelay6.public.one.com (mailrelay6.public.one.com [91.198.169.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ADF012B010 for ; Wed, 1 Jun 2016 07:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=CaXIpljU3Y7h54XymymCEDBhh1culQs9K+JiOLDD/eM=; b=yR5b3XkTQv5YfAZcpR1T1D4h034KiyAwyO3UT8fHpX/vyFw9zyPMG4o2wXsr1pS/TUCCqRBW2vBit ZgPddJ6JoGOGoB4HNRiGivdUP1NMYEBwBgKBPgpkd3tmadsN1sNW+e8V6oFcCY7a+Yx55Yp+gTGAUc B22usGLAcfElTdkI= X-HalOne-Cookie: ee730185cb2b860a577a580964864f77fcd29743 X-HalOne-ID: 77c2ef1d-2802-11e6-a267-b82a72d06996 Received: from smtp.dmfs.org (unknown [217.234.99.215]) by smtpfilter3.public.one.com (Halon Mail Gateway) with ESMTPSA; Wed, 1 Jun 2016 14:09:34 +0000 (UTC) Received: from localhost.localdomain (pD9EA63D7.dip0.t-ipconnect.de [217.234.99.215]) by smtp.dmfs.org (Postfix) with ESMTPSA id 0DAFD1D7; Wed, 1 Jun 2016 15:56:09 +0200 (CEST) Message-ID: <574EEA5E.3060308@dmfs.org> Date: Wed, 01 Jun 2016 15:59:58 +0200 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paul E. Jones , webfinger@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 14:09:47 -0000 Hi Paul, we've brought up this topic during the last CalConnect conference and it was decided to revitalize the TC where the draft you mentioned originated from. We have some interest from software vendors and users to get this solved. As mentioned before, one of the major problems to solve is authentication. The issue raised was that the pure existence of a link to a configuration document in the webfinger response can reveal the existence of the account. On the other hand, requiring authentication for auto configuration results in other possible security issues and a poor user experience. The latter ones could probably be solved by making OpenID Connect a requirement for auto configuration, which, on the other hand, adds another layer of complexity and probably makes it less attractive to smaller vendors. Does anyone see any possible solution to that? I'd also like to suggest a few changes in the structure of the configuration document and to drop support for services not protected by TLS or any other transport security layer. I'll post an updated draft as a basis for discussion. I'm happy to join the upcoming IEFT meeting in Berlin and have a BOF or something if there is enough interest in that. cheers Marten Am 09.02.2016 um 02:03 schrieb Paul E. Jones: > Marten, > > Thanks for the encouraging words; it sounds like you understand the > problem that needs to be solved. > > I always felt the server side was the trivial part. As you said, it's > possible to set up a simple WebFinger server with a static file (or > sets of files), an .htaccess file, etc. I use a server that pulls > data from a database, myself. Importantly, though, the WebFinger > protocol is very simple (and I have to thank a number of folks who > forced that simplicity), so I see the server side as being far less of > a barrier. Hosting providers, for example, could very quickly and > easily support this server-side. > > The clients are the challenge. As others have noted, this requires > code changes in the clients and deployment of the clients. I'm > encouraged that you're working on client code. :) > > Having an RFC is going to be an extremely important step to actually > seeing this problem solved. That said, I did not want to spend time > on something that would be met with total rejection. It sounds like > there is at least enough interest to start a meaningful dialog, so > I'll try to put together a draft soon and we can go from there. If > you're interested to collaborate on that, you're certainly welcome. > > Paul > > ------ Original Message ------ > From: "Marten Gajda" > To: webfinger@ietf.org > Sent: 2/8/2016 5:54:58 PM > Subject: Re: [webfinger] [apps-discuss] Mail client configuration via > WebFinger > >> Hi Paul, >> >> as a client developer I'm very interested in this topic. We've >> actually implemented draft-daboo-aggregated-service-discovery-03 and >> there is at least one groupware server product which also supports it. >> >> While working on our implementation we've identified a few minor >> issues with the latest draft and we've already discussed them with >> Cyrus. I think most of these issues are solved easily. >> >> Though, the major issue has not been addressed yet. It's the issue >> mentioned by Stephen. Under certain conditions a client might have to >> ask the user upfront to authenticate, which may disclose the user's >> credentials to the wrong service. >> >> We didn't release this feature in our generic CalDAV/CardDAV clients, >> mostly due to that issue. >> >> Anyway, I think it really starts with the server developers. >> Implementing the current spec is not that much work on the server >> side. In many cases the server configuration document could just be a >> static file and setting up a simple WebFinger end point is not that >> hard either. Actually, for our corporate server we've just created a >> few static files and some redirect magic in our .htaccess file to >> provide the WebFinger stuff. >> >> On the client side it's more work, because it affects the account >> setup flow a lot. But it surely is worth the efforts if more services >> support it. >> >> However, before even the server developers can start, it requires an >> RFC. So lets start to think about how to solve the authentication issue. >> >> cheers >> >> Marten >> >> >> Am 08.02.2016 um 20:00 schrieb Paul E. Jones: >>> Cyrus, >>> >>>> Right now it is not clear to me that an ASCOT-like solution would >>>> be adopted given the use of device management. Before embarking on >>>> this we need to take a careful look at whether any solution is >>>> likely to be adopted (with the biggest burden likely being on >>>> clients/OS vendors to support it). Given the device management >>>> solutions already out there, I suspect there would be little value >>>> to m,ost of those folks to actually support ASCOT. >>> >>> I completely agree that we should try to get a sense of the >>> likelihood of success. >>> >>> Within the enterprise -- especially the larger ones -- you are >>> entirely correct that device management systems provide a good >>> solution for most of the employees. However, I interact with a lot >>> of smaller businesses that do not use such systems. Many of them >>> have a web hosting company host their domains and do not have IT >>> staff to help them on a daily basis. I'm skeptical that a device >>> management system would help that class of users, so arming hosting >>> providers with tools they can deploy to their customers would help, >>> I think. >>> >>> There are also a number of individuals who have their own domains, >>> many hosted on the many, many web hosting providers out there. Same >>> issue for most of them. >>> >>> So, I think there is a market need. I suspect if we were to create >>> a solution, hosting providers were to deploy it, and client >>> developers were to support it, people would use it. However, that's >>> a string of "ifs". I think it starts with the client developers. >>> If there were people interested to solve the problem, I think the >>> rest falls into place. >>> >>> All that said, if client developers are uninterested, there's little >>> point working to solve this problem. >>> >>>> As an alternative, the IETF might want to take a more serious look >>>> at the overall device management solutions, and see if there might >>>> be scope for standards in that area. That would allow us to build >>>> off something that is already deployed (in a number of proprietary >>>> solutions) but is today solving the problem of account setup. >>> >>> I think your suggestion is worthwhile independent of whether we >>> solve the problem for smaller businesses and individual users of >>> hosted domains. It would good if the same solution or would address >>> those needs of smaller businesses and individuals, but if it didn't, >>> it's still a step forward. >>> >>> Paul >>> >>> _______________________________________________ >>> webfinger mailing list >>> webfinger@ietf.org >>> https://www.ietf.org/mailman/listinfo/webfinger >> >> -- Marten Gajda >> CEO >> >> dmfs GmbH >> Schandauer Straße 34 >> 01309 Dresden >> GERMANY >> >> phone: +49 177 4427167 >> email: marten@dmfs.org >> >> Managing Director: Marten Gajda >> Registered address: Dresden >> Registered No.: AG Dresden HRB 34881 >> VAT Reg. No.: DE303248743 >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger > -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 From nobody Wed Jun 1 11:40:01 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD6812D0C1 for ; Wed, 1 Jun 2016 11:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNyUg5J7o8TL for ; Wed, 1 Jun 2016 11:39:56 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16B612D0D1 for ; Wed, 1 Jun 2016 11:39:31 -0700 (PDT) Received: from [156.106.219.196] ([156.106.219.196]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u51IdQp3000596 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2016 14:39:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1464806368; bh=qXAoQa/Md+HxQbVLi50CzwR5lqrR+HjDvC2t8p/Z1JQ=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=pbob01MbUgQEdC098JDqcctjvlR/kg+x0yquG5fmmMgQ1NU+mCJOf2PLB0B+xvaAr 7rZCufx4AY6ePgg+wK4so6QEkzx0hUP1WjiMPAdAS+jiWyn+jtEkb1+NdUhTLsT4jZ 8U4M5TSUoXwI1lsZICOAlGEqI0pANFAM44RQLGuU= From: "Paul E. Jones" To: "Marten Gajda" , "webfinger@ietf.org" Date: Wed, 01 Jun 2016 18:39:27 +0000 Message-Id: In-Reply-To: <574EEA5E.3060308@dmfs.org> User-Agent: eM_Client/6.0.24928.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Wed, 01 Jun 2016 14:39:28 -0400 (EDT) Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 18:39:59 -0000 Marten, I would truly love to see this move forward and have had an intention of= =20 writing a draft myself. I'd be happy to collaborate with you on one. =20 Just in the past couple of weeks, I had to help somebody set up their=20 email client remotely to use an IMAP server. It was incredibly painful=20 for me to try to step them through the process not having access to=20 their screen, etc. After that experience, I'm even more convinced that=20 a solution to this problem is needed. I personally don't think learning the existing of an account is an=20 issue, since I can discover that by merely sending an email. However,=20 if that is a concern, then the simplest solution is for the server that=20 is providing the configuration document to requires authentication=20 regardless of the user ID presented. If I were to deploy this in my own environment, I would use the same=20 user ID and password to retrieve the configuration document as is used=20 to log into the IMAP for SMTP server. Interfacing with the auth=20 functions that already exist would be fairly trivial. I don't fully=20 understand why we would want to have a different authentication=20 mechanism, given that (at least in every case I've seen) the IMAP/POP=20 and SMTP services generally validate users from the same authentication=20 functions behind the scenes. Sending credentials over HTTPS to a server= =20 to then validate in the same manner seems to make a lot of sense. So the solution I had in mind would be to query using WebFinger to get=20 the usual output for "paulej@packetizer.com". In that JRD that is=20 returned would be a link relation type "mailconfig" that refers to a=20 resource like https://dublin.packetizer.com/mailconfig/?user=3Dpaulej. =20 That web interface would require just basic authentication (since the=20 password would be encrypted with TLS) and authenticate with the auth=20 function like the other mail services. If auth is successful, it would=20 return the JSON structure that would contain the mail configuration=20 information. I could easily have something like that working very=20 quickly. I'd be very hesitant to introduce more complex authentication or=20 identity procedures, personally. As for the content of the file returned, while I very much think we=20 should only be using the latest security procedures, we have to allow=20 the document to return things like "use SSLv2" if that is indeed what=20 the IMAP server supports. These policies are really for the IT folks to= =20 dictate and I don't think the document we produce should dictate the=20 security mechanisms. It's really the place for other documents to=20 dictate best practices and any suggestion we might make might be wrong=20 in 5 years. :) That said, I'm certainly favorable to simplicity and have no strong view= =20 on exactly how the config information should be structured. I wrote up=20 an example https://tools.ietf.org/html/draft-ietf-appsawg-webfinger-03=20 that was overly trivial. It did not consider the possibility that a=20 client might have multiple protocols, for example. I think it is=20 important to provide a JSON document that is an array of mail=20 transmission options then an array of mail retrieval options. Within=20 each array, I would expect an array of configuration options ordered in=20 the preferred order of the administrator. Thus, the preferred security=20 procedures can be conveyed. So, "IMAP" and the host might be listed a=20 few times with different ports and transports (SSL and TLS and, gulp, no= =20 security). I have seen some services offered where the host name=20 actually differs based on one's geographic location. Thus, multiple=20 servers names might need to be conveyed, along with perhaps checking the= =20 physical location of the user. (But, that detail doesn't have to be a=20 part of the spec.) Importantly, since the whole process can be automated, then it is=20 entirely possible for the client to re-check the recommended=20 configuration information from time-to-time to see if there is a change=20 in the configuration details. Paul ------ Original Message ------ From: "Marten Gajda" To: "Paul E. Jones" ; "webfinger@ietf.org"=20 Sent: 6/1/2016 9:59:58 AM Subject: Re: [webfinger] [apps-discuss] Mail client configuration via=20 WebFinger >Hi Paul, > >we've brought up this topic during the last CalConnect conference and=20 >it >was decided to revitalize the TC where the draft you mentioned >originated from. We have some interest from software vendors and users >to get this solved. > >As mentioned before, one of the major problems to solve is >authentication. The issue raised was that the pure existence of a link >to a configuration document in the webfinger response can reveal the >existence of the account. On the other hand, requiring authentication >for auto configuration results in other possible security issues and a >poor user experience. The latter ones could probably be solved by=20 >making >OpenID Connect a requirement for auto configuration, which, on the=20 >other >hand, adds another layer of complexity and probably makes it less >attractive to smaller vendors. > >Does anyone see any possible solution to that? > >I'd also like to suggest a few changes in the structure of the >configuration document and to drop support for services not protected=20 >by >TLS or any other transport security layer. I'll post an updated draft=20 >as >a basis for discussion. > >I'm happy to join the upcoming IEFT meeting in Berlin and have a BOF or >something if there is enough interest in that. > >cheers > >Marten > > > > >Am 09.02.2016 um 02:03 schrieb Paul E. Jones: >> Marten, >> >> Thanks for the encouraging words; it sounds like you understand the >> problem that needs to be solved. >> >> I always felt the server side was the trivial part. As you said,=20 >>it's >> possible to set up a simple WebFinger server with a static file (or >> sets of files), an .htaccess file, etc. I use a server that pulls >> data from a database, myself. Importantly, though, the WebFinger >> protocol is very simple (and I have to thank a number of folks who >> forced that simplicity), so I see the server side as being far less=20 >>of >> a barrier. Hosting providers, for example, could very quickly and >> easily support this server-side. >> >> The clients are the challenge. As others have noted, this requires >> code changes in the clients and deployment of the clients. I'm >> encouraged that you're working on client code. :) >> >> Having an RFC is going to be an extremely important step to actually >> seeing this problem solved. That said, I did not want to spend time >> on something that would be met with total rejection. It sounds like >> there is at least enough interest to start a meaningful dialog, so >> I'll try to put together a draft soon and we can go from there. If >> you're interested to collaborate on that, you're certainly welcome. >> >> Paul >> >> ------ Original Message ------ >> From: "Marten Gajda" >> To: webfinger@ietf.org >> Sent: 2/8/2016 5:54:58 PM >> Subject: Re: [webfinger] [apps-discuss] Mail client configuration via >> WebFinger >> >>> Hi Paul, >>> >>> as a client developer I'm very interested in this topic. We've >>> actually implemented draft-daboo-aggregated-service-discovery-03 and >>> there is at least one groupware server product which also supports=20 >>>it. >>> >>> While working on our implementation we've identified a few minor >>> issues with the latest draft and we've already discussed them with >>> Cyrus. I think most of these issues are solved easily. >>> >>> Though, the major issue has not been addressed yet. It's the issue >>> mentioned by Stephen. Under certain conditions a client might have=20 >>>to >>> ask the user upfront to authenticate, which may disclose the user's >>> credentials to the wrong service. >>> >>> We didn't release this feature in our generic CalDAV/CardDAV=20 >>>clients, >>> mostly due to that issue. >>> >>> Anyway, I think it really starts with the server developers. >>> Implementing the current spec is not that much work on the server >>> side. In many cases the server configuration document could just be= =20 >>>a >>> static file and setting up a simple WebFinger end point is not that >>> hard either. Actually, for our corporate server we've just created = a >>> few static files and some redirect magic in our .htaccess file to >>> provide the WebFinger stuff. >>> >>> On the client side it's more work, because it affects the account >>> setup flow a lot. But it surely is worth the efforts if more=20 >>>services >>> support it. >>> >>> However, before even the server developers can start, it requires an >>> RFC. So lets start to think about how to solve the authentication=20 >>>issue. >>> >>> cheers >>> >>> Marten >>> >>> >>> Am 08.02.2016 um 20:00 schrieb Paul E. Jones: >>>> Cyrus, >>>> >>>>> Right now it is not clear to me that an ASCOT-like solution would >>>>> be adopted given the use of device management. Before embarking on >>>>> this we need to take a careful look at whether any solution is >>>>> likely to be adopted (with the biggest burden likely being on >>>>> clients/OS vendors to support it). Given the device management >>>>> solutions already out there, I suspect there would be little value >>>>> to m,ost of those folks to actually support ASCOT. >>>> >>>> I completely agree that we should try to get a sense of the >>>> likelihood of success. >>>> >>>> Within the enterprise -- especially the larger ones -- you are >>>> entirely correct that device management systems provide a good >>>> solution for most of the employees. However, I interact with a=20 >>>>lot >>>> of smaller businesses that do not use such systems. Many of them >>>> have a web hosting company host their domains and do not have IT >>>> staff to help them on a daily basis. I'm skeptical that a device >>>> management system would help that class of users, so arming hosting >>>> providers with tools they can deploy to their customers would help, >>>> I think. >>>> >>>> There are also a number of individuals who have their own domains, >>>> many hosted on the many, many web hosting providers out there. Same >>>> issue for most of them. >>>> >>>> So, I think there is a market need. I suspect if we were to create >>>> a solution, hosting providers were to deploy it, and client >>>> developers were to support it, people would use it. However,=20 >>>>that's >>>> a string of "ifs". I think it starts with the client developers. >>>> If there were people interested to solve the problem, I think the >>>> rest falls into place. >>>> >>>> All that said, if client developers are uninterested, there's=20 >>>>little >>>> point working to solve this problem. >>>> >>>>> As an alternative, the IETF might want to take a more serious look >>>>> at the overall device management solutions, and see if there might >>>>> be scope for standards in that area. That would allow us to build >>>>> off something that is already deployed (in a number of proprietary >>>>> solutions) but is today solving the problem of account setup. >>>> >>>> I think your suggestion is worthwhile independent of whether we >>>> solve the problem for smaller businesses and individual users of >>>> hosted domains. It would good if the same solution or would=20 >>>>address >>>> those needs of smaller businesses and individuals, but if it=20 >>>>didn't, >>>> it's still a step forward. >>>> >>>> Paul >>>> >>>> _______________________________________________ >>>> webfinger mailing list >>>> webfinger@ietf.org >>>> https://www.ietf.org/mailman/listinfo/webfinger >>> >>> -- Marten Gajda >>> CEO >>> >>> dmfs GmbH >>> Schandauer Stra=C3=9Fe 34 >>> 01309 Dresden >>> GERMANY >>> >>> phone: +49 177 4427167 >>> email: marten@dmfs.org >>> >>> Managing Director: Marten Gajda >>> Registered address: Dresden >>> Registered No.: AG Dresden HRB 34881 >>> VAT Reg. No.: DE303248743 >>> >>> _______________________________________________ >>> webfinger mailing list >>> webfinger@ietf.org >>> https://www.ietf.org/mailman/listinfo/webfinger >> > >-- >Marten Gajda >CEO > >dmfs GmbH >Schandauer Stra=C3=9Fe 34 >01309 Dresden >GERMANY > >phone: +49 177 4427167 >email: marten@dmfs.org > >Managing Director: Marten Gajda >Registered address: Dresden >Registered No.: AG Dresden HRB 34881 >VAT Reg. No.: DE303248743 > >_______________________________________________ >webfinger mailing list >webfinger@ietf.org >https://www.ietf.org/mailman/listinfo/webfinger From nobody Thu Jun 2 15:55:44 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8186712D8F1 for ; Thu, 2 Jun 2016 15:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-7Ruytn4Y1f for ; Thu, 2 Jun 2016 15:55:40 -0700 (PDT) Received: from mailrelay2.public.one.com (mailrelay2.public.one.com [91.198.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E9212D8EE for ; Thu, 2 Jun 2016 15:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=RCfvANwLSHLX7kCen0bVhID9eXNFOwul9Qwv43h7Es0=; b=Var5Ug8ci8trYeokWoZQaQ+rPeQjmw1WemJAQMsZwigkmsuzU7x10XoYeZeB2yZVimTAvrvlWf18o QXtxysnDNzx/gAwYrJIZWBeo5vS2gT7/WfI7FFGFQi8X3bBLlFVw6bzjRO66XrlK7ePXc9BykL+uN9 QwbQWYsn78S0/P8g= X-HalOne-Cookie: df7b7d27f71af0d4b65504b28df1ce6a2e481277 X-HalOne-ID: 1dbfe226-2915-11e6-8278-b82a72d03b9b Received: from smtp.dmfs.org (unknown [79.240.232.33]) by smtpfilter2.public.one.com (Halon Mail Gateway) with ESMTPSA; Thu, 2 Jun 2016 22:55:34 +0000 (UTC) Received: from localhost.localdomain (p5DDA907C.dip0.t-ipconnect.de [93.218.144.124]) by smtp.dmfs.org (Postfix) with ESMTPSA id 831F71D7; Fri, 3 Jun 2016 00:51:37 +0200 (CEST) Message-ID: <5750B965.9040506@dmfs.org> Date: Fri, 03 Jun 2016 00:55:33 +0200 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paul E. Jones , webfinger@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 22:55:43 -0000 Hi Paul, the problem is that often it's possible to use the same user id with different services. A common example is iCloud, which allows you to use your Gmail address as the login name. In that case, to set up calendar synchronization with iCloud, a user would enter his login (which is the Gmail address) to start the auto-configuration. Of course a client would first do a Webfinger request on gmail.com in that case. If that requires authentication the client needs to ask for the Gmail password first. That's where you really confuse users and it might happen that they enter their iCloud password instead, which then might be revealed to Gmail. To avoid this, it has been suggested to give users an (additional) acct: URI type login name which always contains the domain of the actual service provider. So the user would enter something like user%40gmail.com@icloud.com or maybe some generated ID like xxxx-xxxx-xxxx-xxxx@icloud.com, but I don't see how we could teach users to understand that they need to enter a different identifier to perform an auto-configuration. Cheers, Marten Am 01.06.2016 um 20:39 schrieb Paul E. Jones: > Marten, > > I would truly love to see this move forward and have had an intention > of writing a draft myself. I'd be happy to collaborate with you on > one. Just in the past couple of weeks, I had to help somebody set up > their email client remotely to use an IMAP server. It was incredibly > painful for me to try to step them through the process not having > access to their screen, etc. After that experience, I'm even more > convinced that a solution to this problem is needed. > > I personally don't think learning the existing of an account is an > issue, since I can discover that by merely sending an email. However, > if that is a concern, then the simplest solution is for the server > that is providing the configuration document to requires > authentication regardless of the user ID presented. > > If I were to deploy this in my own environment, I would use the same > user ID and password to retrieve the configuration document as is used > to log into the IMAP for SMTP server. Interfacing with the auth > functions that already exist would be fairly trivial. I don't fully > understand why we would want to have a different authentication > mechanism, given that (at least in every case I've seen) the IMAP/POP > and SMTP services generally validate users from the same > authentication functions behind the scenes. Sending credentials over > HTTPS to a server to then validate in the same manner seems to make a > lot of sense. > > So the solution I had in mind would be to query using WebFinger to get > the usual output for "paulej@packetizer.com". In that JRD that is > returned would be a link relation type "mailconfig" that refers to a > resource like https://dublin.packetizer.com/mailconfig/?user=paulej. > That web interface would require just basic authentication (since the > password would be encrypted with TLS) and authenticate with the auth > function like the other mail services. If auth is successful, it > would return the JSON structure that would contain the mail > configuration information. I could easily have something like that > working very quickly. > > I'd be very hesitant to introduce more complex authentication or > identity procedures, personally. > > As for the content of the file returned, while I very much think we > should only be using the latest security procedures, we have to allow > the document to return things like "use SSLv2" if that is indeed what > the IMAP server supports. These policies are really for the IT folks > to dictate and I don't think the document we produce should dictate > the security mechanisms. It's really the place for other documents to > dictate best practices and any suggestion we might make might be wrong > in 5 years. :) > > That said, I'm certainly favorable to simplicity and have no strong > view on exactly how the config information should be structured. I > wrote up an example > https://tools.ietf.org/html/draft-ietf-appsawg-webfinger-03 that was > overly trivial. It did not consider the possibility that a client > might have multiple protocols, for example. I think it is important > to provide a JSON document that is an array of mail transmission > options then an array of mail retrieval options. Within each array, I > would expect an array of configuration options ordered in the > preferred order of the administrator. Thus, the preferred security > procedures can be conveyed. So, "IMAP" and the host might be listed a > few times with different ports and transports (SSL and TLS and, gulp, > no security). I have seen some services offered where the host name > actually differs based on one's geographic location. Thus, multiple > servers names might need to be conveyed, along with perhaps checking > the physical location of the user. (But, that detail doesn't have to > be a part of the spec.) > > Importantly, since the whole process can be automated, then it is > entirely possible for the client to re-check the recommended > configuration information from time-to-time to see if there is a > change in the configuration details. > > Paul > > ------ Original Message ------ > From: "Marten Gajda" > To: "Paul E. Jones" ; "webfinger@ietf.org" > > Sent: 6/1/2016 9:59:58 AM > Subject: Re: [webfinger] [apps-discuss] Mail client configuration via > WebFinger > >> Hi Paul, >> >> we've brought up this topic during the last CalConnect conference and it >> was decided to revitalize the TC where the draft you mentioned >> originated from. We have some interest from software vendors and users >> to get this solved. >> >> As mentioned before, one of the major problems to solve is >> authentication. The issue raised was that the pure existence of a link >> to a configuration document in the webfinger response can reveal the >> existence of the account. On the other hand, requiring authentication >> for auto configuration results in other possible security issues and a >> poor user experience. The latter ones could probably be solved by making >> OpenID Connect a requirement for auto configuration, which, on the other >> hand, adds another layer of complexity and probably makes it less >> attractive to smaller vendors. >> >> Does anyone see any possible solution to that? >> >> I'd also like to suggest a few changes in the structure of the >> configuration document and to drop support for services not protected by >> TLS or any other transport security layer. I'll post an updated draft as >> a basis for discussion. >> >> I'm happy to join the upcoming IEFT meeting in Berlin and have a BOF or >> something if there is enough interest in that. >> >> cheers >> >> Marten >> >> >> >> >> Am 09.02.2016 um 02:03 schrieb Paul E. Jones: >>> Marten, >>> >>> Thanks for the encouraging words; it sounds like you understand the >>> problem that needs to be solved. >>> >>> I always felt the server side was the trivial part. As you said, it's >>> possible to set up a simple WebFinger server with a static file (or >>> sets of files), an .htaccess file, etc. I use a server that pulls >>> data from a database, myself. Importantly, though, the WebFinger >>> protocol is very simple (and I have to thank a number of folks who >>> forced that simplicity), so I see the server side as being far less of >>> a barrier. Hosting providers, for example, could very quickly and >>> easily support this server-side. >>> >>> The clients are the challenge. As others have noted, this requires >>> code changes in the clients and deployment of the clients. I'm >>> encouraged that you're working on client code. :) >>> >>> Having an RFC is going to be an extremely important step to actually >>> seeing this problem solved. That said, I did not want to spend time >>> on something that would be met with total rejection. It sounds like >>> there is at least enough interest to start a meaningful dialog, so >>> I'll try to put together a draft soon and we can go from there. If >>> you're interested to collaborate on that, you're certainly welcome. >>> >>> Paul >>> >>> ------ Original Message ------ >>> From: "Marten Gajda" >>> To: webfinger@ietf.org >>> Sent: 2/8/2016 5:54:58 PM >>> Subject: Re: [webfinger] [apps-discuss] Mail client configuration via >>> WebFinger >>> >>>> Hi Paul, >>>> >>>> as a client developer I'm very interested in this topic. We've >>>> actually implemented draft-daboo-aggregated-service-discovery-03 and >>>> there is at least one groupware server product which also supports >>>> it. >>>> >>>> While working on our implementation we've identified a few minor >>>> issues with the latest draft and we've already discussed them with >>>> Cyrus. I think most of these issues are solved easily. >>>> >>>> Though, the major issue has not been addressed yet. It's the issue >>>> mentioned by Stephen. Under certain conditions a client might have to >>>> ask the user upfront to authenticate, which may disclose the user's >>>> credentials to the wrong service. >>>> >>>> We didn't release this feature in our generic CalDAV/CardDAV clients, >>>> mostly due to that issue. >>>> >>>> Anyway, I think it really starts with the server developers. >>>> Implementing the current spec is not that much work on the server >>>> side. In many cases the server configuration document could just be a >>>> static file and setting up a simple WebFinger end point is not that >>>> hard either. Actually, for our corporate server we've just created a >>>> few static files and some redirect magic in our .htaccess file to >>>> provide the WebFinger stuff. >>>> >>>> On the client side it's more work, because it affects the account >>>> setup flow a lot. But it surely is worth the efforts if more services >>>> support it. >>>> >>>> However, before even the server developers can start, it requires an >>>> RFC. So lets start to think about how to solve the authentication >>>> issue. >>>> >>>> cheers >>>> >>>> Marten >>>> >>>> >>>> Am 08.02.2016 um 20:00 schrieb Paul E. Jones: >>>>> Cyrus, >>>>> >>>>>> Right now it is not clear to me that an ASCOT-like solution would >>>>>> be adopted given the use of device management. Before embarking on >>>>>> this we need to take a careful look at whether any solution is >>>>>> likely to be adopted (with the biggest burden likely being on >>>>>> clients/OS vendors to support it). Given the device management >>>>>> solutions already out there, I suspect there would be little value >>>>>> to m,ost of those folks to actually support ASCOT. >>>>> >>>>> I completely agree that we should try to get a sense of the >>>>> likelihood of success. >>>>> >>>>> Within the enterprise -- especially the larger ones -- you are >>>>> entirely correct that device management systems provide a good >>>>> solution for most of the employees. However, I interact with a lot >>>>> of smaller businesses that do not use such systems. Many of them >>>>> have a web hosting company host their domains and do not have IT >>>>> staff to help them on a daily basis. I'm skeptical that a device >>>>> management system would help that class of users, so arming hosting >>>>> providers with tools they can deploy to their customers would help, >>>>> I think. >>>>> >>>>> There are also a number of individuals who have their own domains, >>>>> many hosted on the many, many web hosting providers out there. Same >>>>> issue for most of them. >>>>> >>>>> So, I think there is a market need. I suspect if we were to create >>>>> a solution, hosting providers were to deploy it, and client >>>>> developers were to support it, people would use it. However, that's >>>>> a string of "ifs". I think it starts with the client developers. >>>>> If there were people interested to solve the problem, I think the >>>>> rest falls into place. >>>>> >>>>> All that said, if client developers are uninterested, there's little >>>>> point working to solve this problem. >>>>> >>>>>> As an alternative, the IETF might want to take a more serious look >>>>>> at the overall device management solutions, and see if there might >>>>>> be scope for standards in that area. That would allow us to build >>>>>> off something that is already deployed (in a number of proprietary >>>>>> solutions) but is today solving the problem of account setup. >>>>> >>>>> I think your suggestion is worthwhile independent of whether we >>>>> solve the problem for smaller businesses and individual users of >>>>> hosted domains. It would good if the same solution or would address >>>>> those needs of smaller businesses and individuals, but if it didn't, >>>>> it's still a step forward. >>>>> >>>>> Paul >>>>> >>>>> _______________________________________________ >>>>> webfinger mailing list >>>>> webfinger@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/webfinger >>>> >>>> -- Marten Gajda >>>> CEO >>>> >>>> dmfs GmbH >>>> Schandauer Straße 34 >>>> 01309 Dresden >>>> GERMANY >>>> >>>> phone: +49 177 4427167 >>>> email: marten@dmfs.org >>>> >>>> Managing Director: Marten Gajda >>>> Registered address: Dresden >>>> Registered No.: AG Dresden HRB 34881 >>>> VAT Reg. No.: DE303248743 >>>> >>>> _______________________________________________ >>>> webfinger mailing list >>>> webfinger@ietf.org >>>> https://www.ietf.org/mailman/listinfo/webfinger >>> >> >> -- >> Marten Gajda >> CEO >> >> dmfs GmbH >> Schandauer Straße 34 >> 01309 Dresden >> GERMANY >> >> phone: +49 177 4427167 >> email: marten@dmfs.org >> >> Managing Director: Marten Gajda >> Registered address: Dresden >> Registered No.: AG Dresden HRB 34881 >> VAT Reg. No.: DE303248743 >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger > -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 From nobody Thu Jun 2 17:43:55 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A00612B02F for ; Thu, 2 Jun 2016 17:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOjyFuQgjhU3 for ; Thu, 2 Jun 2016 17:43:52 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602301200A0 for ; Thu, 2 Jun 2016 17:43:52 -0700 (PDT) Received: (qmail 18577 invoked from network); 3 Jun 2016 00:43:50 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Jun 2016 00:43:50 -0000 Date: 3 Jun 2016 00:43:28 -0000 Message-ID: <20160603004328.12103.qmail@ary.lan> From: "John Levine" To: webfinger@ietf.org In-Reply-To: <574EEA5E.3060308@dmfs.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: marten@dmfs.org Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 00:43:54 -0000 If I may ask an obvious question, how much better in practice is this likely to be than RFC 6186? I realize that 6186 is somewhat inflexible and requires that the address or the local-part be the login credential, but it is my impression that the vast majority of mail servers are set up that way anyway. R's, John From nobody Thu Jun 2 22:42:43 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C0512D0BD for ; Thu, 2 Jun 2016 22:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIobxlqTHgqM for ; Thu, 2 Jun 2016 22:42:37 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B502712B019 for ; Thu, 2 Jun 2016 22:42:37 -0700 (PDT) Received: from [10.54.74.61] (216.239.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.239.216]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u535gWm4027682 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 01:42:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1464932554; bh=laDh4gNlbp8HkfMoKo4341RRy4Wk5XWI6t46ZLE8Qw0=; h=In-Reply-To:References:Subject:From:Date:To; b=VGV2J4V/3S5l8bHRUn0caKQWeLJIYBZsAiVGEtKUgNY6Gn6+m4Bnnv97NAv9505uR l3Nk+rLZyoZUIawwXPJE0vdaZ6gS+wjw7z5dl7owxRKnYtWAJ98xsO9Tv8wvksJLLN SaizmGXwj0rMW3E+6TihxXtdXwy+6EEKPyj3rJWs= User-Agent: K-9 Mail for Android In-Reply-To: <5750B965.9040506@dmfs.org> References: <5750B965.9040506@dmfs.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----ASYJAW6UUX4J0DG4Y306LKGLG5UOZW" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Fri, 03 Jun 2016 07:42:29 +0200 To: Marten Gajda , "webfinger@ietf.org" Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Fri, 03 Jun 2016 01:42:34 -0400 (EDT) Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 05:42:42 -0000 ------ASYJAW6UUX4J0DG4Y306LKGLG5UOZW Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Marten, At the end of all of all of this, the email client is still going to need the password for the SMTP and IMAP/POP3 service. I guess some even use different passwords for those, since email clients ask for it. I personally use Google Calendar with my email and authenticate that separately today (which looks like oauth given how it integrates). So what I would expect is a UI that asks for the passwords for each service that is being accessed, much like today. We really can't get around that. The client just has to make it clear to the user. I only suggested to use the same password to retrieve the mail config as for using email. In truth, I don't even see the security risk with that, as I can find nearly any server. Thus, it's like security through obfuscation, which we know isn't security. But, if we insist on securing it, use the email password (ideally that being the same). Calendar or other services could each have their own like relations discovered via WebFinger. Or, that info could be bundled with the email config. Either way, I think we just have to ensure the UI is clear, but the starting point be the email password. Perhaps I'm overlooking something, but I'm otherwise confused how the client will get that SMTP and IMAP password. Paul -------- Original Message -------- From: Marten Gajda Sent: June 3, 2016 12:55:33 AM GMT+02:00 To: "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger Hi Paul, the problem is that often it's possible to use the same user id with different services. A common example is iCloud, which allows you to use your Gmail address as the login name. In that case, to set up calendar synchronization with iCloud, a user would enter his login (which is the Gmail address) to start the auto-configuration. Of course a client would first do a Webfinger request on gmail.com in that case. If that requires authentication the client needs to ask for the Gmail password first. That's where you really confuse users and it might happen that they enter their iCloud password instead, which then might be revealed to Gmail. To avoid this, it has been suggested to give users an (additional) acct: URI type login name which always contains the domain of the actual service provider. So the user would enter something like user%40gmail.com@icloud.com or maybe some generated ID like xxxx-xxxx-xxxx-xxxx@icloud.com, but I don't see how we could teach users to understand that they need to enter a different identifier to perform an auto-configuration. Cheers, Marten Am 01.06.2016 um 20:39 schrieb Paul E. Jones: > Marten, > > I would truly love to see this move forward and have had an intention > of writing a draft myself. I'd be happy to collaborate with you on > one. Just in the past couple of weeks, I had to help somebody set up > their email client remotely to use an IMAP server. It was incredibly > painful for me to try to step them through the process not having > access to their screen, etc. After that experience, I'm even more > convinced that a solution to this problem is needed. > > I personally don't think learning the existing of an account is an > issue, since I can discover that by merely sending an email. However, > if that is a concern, then the simplest solution is for the server > that is providing the configuration document to requires > authentication regardless of the user ID presented. > > If I were to deploy this in my own environment, I would use the same > user ID and password to retrieve the configuration document as is used > to log into the IMAP for SMTP server. Interfacing with the auth > functions that already exist would be fairly trivial. I don't fully > understand why we would want to have a different authentication > mechanism, given that (at least in every case I've seen) the IMAP/POP > and SMTP services generally validate users from the same > authentication functions behind the scenes. Sending credentials over > HTTPS to a server to then validate in the same manner seems to make a > lot of sense. > > So the solution I had in mind would be to query using WebFinger to get > the usual output for "paulej@packetizer.com". In that JRD that is > returned would be a link relation type "mailconfig" that refers to a > resource like https://dublin.packetizer.com/mailconfig/?user=paulej. > That web interface would require just basic authentication (since the > password would be encrypted with TLS) and authenticate with the auth > function like the other mail services. If auth is successful, it > would return the JSON structure that would contain the mail > configuration information. I could easily have something like that > working very quickly. > > I'd be very hesitant to introduce more complex authentication or > identity procedures, personally. > > As for the content of the file returned, while I very much think we > should only be using the latest security procedures, we have to allow > the document to return things like "use SSLv2" if that is indeed what > the IMAP server supports. These policies are really for the IT folks > to dictate and I don't think the document we produce should dictate > the security mechanisms. It's really the place for other documents to > dictate best practices and any suggestion we might make might be wrong > in 5 years. :) > > That said, I'm certainly favorable to simplicity and have no strong > view on exactly how the config information should be structured. I > wrote up an example > https://tools.ietf.org/html/draft-ietf-appsawg-webfinger-03 that was > overly trivial. It did not consider the possibility that a client > might have multiple protocols, for example. I think it is important > to provide a JSON document that is an array of mail transmission > options then an array of mail retrieval options. Within each array, I > would expect an array of configuration options ordered in the > preferred order of the administrator. Thus, the preferred security > procedures can be conveyed. So, "IMAP" and the host might be listed a > few times with different ports and transports (SSL and TLS and, gulp, > no security). I have seen some services offered where the host name > actually differs based on one's geographic location. Thus, multiple > servers names might need to be conveyed, along with perhaps checking > the physical location of the user. (But, that detail doesn't have to > be a part of the spec.) > > Importantly, since the whole process can be automated, then it is > entirely possible for the client to re-check the recommended > configuration information from time-to-time to see if there is a > change in the configuration details. > > Paul > > ------ Original Message ------ > From: "Marten Gajda" > To: "Paul E. Jones" ; "webfinger@ietf.org" > > Sent: 6/1/2016 9:59:58 AM > Subject: Re: [webfinger] [apps-discuss] Mail client configuration via > WebFinger > >> Hi Paul, >> >> we've brought up this topic during the last CalConnect conference and it >> was decided to revitalize the TC where the draft you mentioned >> originated from. We have some interest from software vendors and users >> to get this solved. >> >> As mentioned before, one of the major problems to solve is >> authentication. The issue raised was that the pure existence of a link >> to a configuration document in the webfinger response can reveal the >> existence of the account. On the other hand, requiring authentication >> for auto configuration results in other possible security issues and a >> poor user experience. The latter ones could probably be solved by making >> OpenID Connect a requirement for auto configuration, which, on the other >> hand, adds another layer of complexity and probably makes it less >> attractive to smaller vendors. >> >> Does anyone see any possible solution to that? >> >> I'd also like to suggest a few changes in the structure of the >> configuration document and to drop support for services not protected by >> TLS or any other transport security layer. I'll post an updated draft as >> a basis for discussion. >> >> I'm happy to join the upcoming IEFT meeting in Berlin and have a BOF or >> something if there is enough interest in that. >> >> cheers >> >> Marten >> >> >> >> >> Am 09.02.2016 um 02:03 schrieb Paul E. Jones: >>> Marten, >>> >>> Thanks for the encouraging words; it sounds like you understand the >>> problem that needs to be solved. >>> >>> I always felt the server side was the trivial part. As you said, it's >>> possible to set up a simple WebFinger server with a static file (or >>> sets of files), an .htaccess file, etc. I use a server that pulls >>> data from a database, myself. Importantly, though, the WebFinger >>> protocol is very simple (and I have to thank a number of folks who >>> forced that simplicity), so I see the server side as being far less of >>> a barrier. Hosting providers, for example, could very quickly and >>> easily support this server-side. >>> >>> The clients are the challenge. As others have noted, this requires >>> code changes in the clients and deployment of the clients. I'm >>> encouraged that you're working on client code. :) >>> >>> Having an RFC is going to be an extremely important step to actually >>> seeing this problem solved. That said, I did not want to spend time >>> on something that would be met with total rejection. It sounds like >>> there is at least enough interest to start a meaningful dialog, so >>> I'll try to put together a draft soon and we can go from there. If >>> you're interested to collaborate on that, you're certainly welcome. >>> >>> Paul >>> >>> ------ Original Message ------ >>> From: "Marten Gajda" >>> To: webfinger@ietf.org >>> Sent: 2/8/2016 5:54:58 PM >>> Subject: Re: [webfinger] [apps-discuss] Mail client configuration via >>> WebFinger >>> >>>> Hi Paul, >>>> >>>> as a client developer I'm very interested in this topic. We've >>>> actually implemented draft-daboo-aggregated-service-discovery-03 and >>>> there is at least one groupware server product which also supports >>>> it. >>>> >>>> While working on our implementation we've identified a few minor >>>> issues with the latest draft and we've already discussed them with >>>> Cyrus. I think most of these issues are solved easily. >>>> >>>> Though, the major issue has not been addressed yet. It's the issue >>>> mentioned by Stephen. Under certain conditions a client might have to >>>> ask the user upfront to authenticate, which may disclose the user's >>>> credentials to the wrong service. >>>> >>>> We didn't release this feature in our generic CalDAV/CardDAV clients, >>>> mostly due to that issue. >>>> >>>> Anyway, I think it really starts with the server developers. >>>> Implementing the current spec is not that much work on the server >>>> side. In many cases the server configuration document could just be a >>>> static file and setting up a simple WebFinger end point is not that >>>> hard either. Actually, for our corporate server we've just created a >>>> few static files and some redirect magic in our .htaccess file to >>>> provide the WebFinger stuff. >>>> >>>> On the client side it's more work, because it affects the account >>>> setup flow a lot. But it surely is worth the efforts if more services >>>> support it. >>>> >>>> However, before even the server developers can start, it requires an >>>> RFC. So lets start to think about how to solve the authentication >>>> issue. >>>> >>>> cheers >>>> >>>> Marten >>>> >>>> >>>> Am 08.02.2016 um 20:00 schrieb Paul E. Jones: >>>>> Cyrus, >>>>> >>>>>> Right now it is not clear to me that an ASCOT-like solution would >>>>>> be adopted given the use of device management. Before embarking on >>>>>> this we need to take a careful look at whether any solution is >>>>>> likely to be adopted (with the biggest burden likely being on >>>>>> clients/OS vendors to support it). Given the device management >>>>>> solutions already out there, I suspect there would be little value >>>>>> to m,ost of those folks to actually support ASCOT. >>>>> >>>>> I completely agree that we should try to get a sense of the >>>>> likelihood of success. >>>>> >>>>> Within the enterprise -- especially the larger ones -- you are >>>>> entirely correct that device management systems provide a good >>>>> solution for most of the employees. However, I interact with a lot >>>>> of smaller businesses that do not use such systems. Many of them >>>>> have a web hosting company host their domains and do not have IT >>>>> staff to help them on a daily basis. I'm skeptical that a device >>>>> management system would help that class of users, so arming hosting >>>>> providers with tools they can deploy to their customers would help, >>>>> I think. >>>>> >>>>> There are also a number of individuals who have their own domains, >>>>> many hosted on the many, many web hosting providers out there. Same >>>>> issue for most of them. >>>>> >>>>> So, I think there is a market need. I suspect if we were to create >>>>> a solution, hosting providers were to deploy it, and client >>>>> developers were to support it, people would use it. However, that's >>>>> a string of "ifs". I think it starts with the client developers. >>>>> If there were people interested to solve the problem, I think the >>>>> rest falls into place. >>>>> >>>>> All that said, if client developers are uninterested, there's little >>>>> point working to solve this problem. >>>>> >>>>>> As an alternative, the IETF might want to take a more serious look >>>>>> at the overall device management solutions, and see if there might >>>>>> be scope for standards in that area. That would allow us to build >>>>>> off something that is already deployed (in a number of proprietary >>>>>> solutions) but is today solving the problem of account setup. >>>>> >>>>> I think your suggestion is worthwhile independent of whether we >>>>> solve the problem for smaller businesses and individual users of >>>>> hosted domains. It would good if the same solution or would address >>>>> those needs of smaller businesses and individuals, but if it didn't, >>>>> it's still a step forward. >>>>> >>>>> Paul >>>>> >>>>> _______________________________________________ >>>>> webfinger mailing list >>>>> webfinger@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/webfinger >>>> >>>> -- Marten Gajda >>>> CEO >>>> >>>> dmfs GmbH >>>> Schandauer Straße 34 >>>> 01309 Dresden >>>> GERMANY >>>> >>>> phone: +49 177 4427167 >>>> email: marten@dmfs.org >>>> >>>> Managing Director: Marten Gajda >>>> Registered address: Dresden >>>> Registered No.: AG Dresden HRB 34881 >>>> VAT Reg. No.: DE303248743 >>>> >>>> _______________________________________________ >>>> webfinger mailing list >>>> webfinger@ietf.org >>>> https://www.ietf.org/mailman/listinfo/webfinger >>> >> >> -- >> Marten Gajda >> CEO >> >> dmfs GmbH >> Schandauer Straße 34 >> 01309 Dresden >> GERMANY >> >> phone: +49 177 4427167 >> email: marten@dmfs.org >> >> Managing Director: Marten Gajda >> Registered address: Dresden >> Registered No.: AG Dresden HRB 34881 >> VAT Reg. No.: DE303248743 >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger > -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------ASYJAW6UUX4J0DG4Y306LKGLG5UOZW Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Marten,

At the end of all of all of this, the email client is still going to need the password for the SMTP and IMAP/POP3 service. I guess some even use different passwords for those, since email clients ask for it.

I personally use Google Calendar with my email and authenticate that separately today (which looks like oauth given how it integrates).

So what I would expect is a UI that asks for the passwords for each service that is being accessed, much like today. We really can't get around that. The client just has to make it clear to the user.

I only suggested to use the same password to retrieve the mail config as for using email. In truth, I don't even see the security risk with that, as I can find nearly any server. Thus, it's like security through obfuscation, which we know isn't security. But, if we insist on securing it, use the email password (ideally that being the same).

Calendar or other services could each have their own like relations discovered via WebFinger. Or, that info could be bundled with the email config. Either way, I think we just have to ensure the UI is clear, but the starting point be the email password.

Perhaps I'm overlooking something, but I'm otherwise confused how the client will get that SMTP and IMAP password.

Paul

From: Marten Gajda <marten@dmfs.org>
Sent: June 3, 2016 12:55:33 AM GMT+02:00
To: "Paul E. Jones" <paulej@packetizer.com>, "webfinger@ietf.org" <webfinger@ietf.org>
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger

Hi Paul,

the problem is that often it's possible to use the same user id with
different services. A common example is iCloud, which allows you to use
your Gmail address as the login name.
In that case, to set up calendar synchronization with iCloud, a user
would enter his login (which is the Gmail address) to start the
auto-configuration. Of course a client would first do a Webfinger
request on gmail.com in that case. If that requires authentication the
client needs to ask for the Gmail password first. That's where you
really confuse users and it might happen that they enter their iCloud
password instead, which then might be revealed to Gmail.

To avoid this, it has been suggested to give users an (additional) acct:
URI type login name which always contains the domain of the actual
service provider. So the user would enter something like
user%40gmail.com@icloud.com or maybe some generated ID like
xxxx-xxxx-xxxx-xxxx@icloud.com, but I don't see how we could teach users
to understand that they need to enter a different identifier to perform
an auto-configuration.

Cheers,

Marten

Am 01.06.2016 um 20:39 schrieb Paul E. Jones:
 Marten,

 I would truly love to see this move forward and have had an intention
 of writing a draft myself.  I'd be happy to collaborate with you on
 one.  Just in the past couple of weeks, I had to help somebody set up
 their email client remotely to use an IMAP server.  It was incredibly
 painful for me to try to step them through the process not having
 access to their screen, etc.  After that experience, I'm even more
 convinced that a solution to this pr!
 oblem is
needed.

 I personally don't think learning the existing of an account is an
 issue, since I can discover that by merely sending an email.  However,
 if that is a concern, then the simplest solution is for the server
 that is providing the configuration document to requires
 authentication regardless of the user ID presented.

 If I were to deploy this in my own environment, I would use the same
 user ID and password to retrieve the configuration document as is used
 to log into the IMAP for SMTP server.  Interfacing with the auth
 functions that already exist would be fairly trivial.  I don't fully
 understand why we would want to have a different authentication
 mechanism, given that (at least in every case I've seen) the IMAP/POP
 and SMTP services generally validate users from the same
 authentication functions behind the scenes.  Sending credentials over
 HTTPS to a server to then validate i!
 n the
same manner seems to make a
 lot of sense.

 So the solution I had in mind would be to query using WebFinger to get
 the usual output for "paulej@packetizer.com".  In that JRD that is
 returned would be a link relation type "mailconfig" that refers to  a
 resource like https://dublin.packetizer.com/mailconfig/?user=paulej. 
 That web interface would require just basic authentication (since the
 password would be encrypted with TLS) and authenticate with the auth
 function like the other mail services.  If auth is successful, it
 would return the JSON structure that would contain the mail
 configuration information.  I could easily have something like that
 working very quickly.

 I'd be very hesitant to introduce more complex authentication or
 identity procedures, personally.

 As for the content of the file returned, while!
  I very
much think we
 should only be using the latest security procedures, we have to allow
 the document to return things like "use SSLv2" if that is indeed what
 the IMAP server supports.  These policies are really for the IT folks
 to dictate and I don't think the document we produce should dictate
 the security mechanisms.  It's really the place for other documents to
 dictate best practices and any suggestion we might make might be wrong
 in 5 years. :)

 That said, I'm certainly favorable to simplicity and have no strong
 view on exactly how the config information should be structured.  I
 wrote up an example
 https://tools.ietf.org/html/draft-ietf-appsawg-webfinger-03 that was
 overly trivial.  It did not consider the possibility that a client
 might have multiple protocols, for example.  I think it is important
 to provide a JS!
 ON
document that is an array of mail transmission
 options then an array of mail retrieval options.  Within each array, I
 would expect an array of configuration options ordered in the
 preferred order of the administrator.  Thus, the preferred security
 procedures can be conveyed.  So, "IMAP" and the host might be listed a
 few times with different ports and transports (SSL and TLS and, gulp,
 no security).  I have seen some services offered where the host name
 actually differs based on one's geographic location.  Thus, multiple
 servers names might need to be conveyed, along with perhaps checking
 the physical location of the user.  (But, that detail doesn't have to
 be a part of the spec.)

 Importantly, since the whole process can be automated, then it is
 entirely possible for the client to re-check the recommended
 configuration information from time-to-time to see if there is a
 change in the
configuration details.

 Paul

 ------ Original Message ------
 From: "Marten Gajda" <marten@dmfs.org>
 To: "Paul E. Jones" <paulej@packetizer.com>; "webfinger@ietf.org"
 <webfinger@ietf.org>
 Sent: 6/1/2016 9:59:58 AM
 Subject: Re: [webfinger] [apps-discuss] Mail client configuration via
 WebFinger

 Hi Paul,

 we've brought up this topic during the last CalConnect conference and it
 was decided to revitalize the TC where the draft you mentioned
 originated from. We have some interest from software vendors and users
 to get this solved.

 As mentioned before, one of the major problems to solve is
 authentication. The issue raised was that the pure existence of a link
 to a configuration document in the webfinger response can reveal the
existence of the account. On the other hand, requiring authentication
 for auto configuration results in other possible security issues and a
 poor user experience. The latter ones could probably be solved by making
 OpenID Connect a requirement for auto configuration, which, on the other
 hand, adds another layer of complexity and probably makes it less
 attractive to smaller vendors.

 Does anyone see any possible solution to that?

 I'd also like to suggest a few changes in the structure of the
 configuration document and to drop support for services not protected by
 TLS or any other transport security layer. I'll post an updated draft as
 a basis for discussion.

 I'm happy to join the upcoming IEFT meeting in Berlin and have a BOF or
 something if there is enough interest in that.

 cheers

 Marten




 Am 09.02.2016 um 02:03 schrieb Paul E. Jones:
  Marten,

  Thanks for the encouraging words; it sounds like you understand the
  problem that needs to be solved.

  I always felt the server side was the trivial part.  As you said, it's
  possible to set up a simple WebFinger server with a static file (or
  sets of files), an .htaccess file, etc.  I use a server that pulls
  data from a database, myself.  Importantly, though, the WebFinger
  protocol is very simple (and I have to thank a number of folks who
  forced that simplicity), so I see the server side as being far less of
  a barrier.  Hosting providers, for example, could very quickly and
  easily support this server-side.

  The clients are the challenge.  As others have noted, this requires
  code changes in the clients and deployment of the clients.  I'm
  encoura!
 ged that
you're working on client code. :)

  Having an RFC is going to be an extremely important step to actually
  seeing this problem solved.  That said, I did not want to spend time
  on something that would be met with total rejection.  It sounds like
  there is at least enough interest to start a meaningful dialog, so
  I'll try to put together a draft soon and we can go from there.  If
  you're interested to collaborate on that, you're certainly welcome.

  Paul

  ------ Original Message ------
  From: "Marten Gajda" <marten@dmfs.org>
  To: webfinger@ietf.org
  Sent: 2/8/2016 5:54:58 PM
  Subject: Re: [webfinger] [apps-discuss] Mail client configuration via
  WebFinger

  Hi Paul,

  as a client developer I'm very interested in this topic. We've
  act!
 ually
implemented draft-daboo-aggregated-service-discovery-03 and
  there is at least one groupware server product which also supports
 it.

  While working on our implementation we've identified a few minor
  issues with the latest draft and we've already discussed them with
  Cyrus. I think most of these issues are solved easily.

  Though, the major issue has not been addressed yet. It's the issue
  mentioned by Stephen. Under certain conditions a client might have to
  ask the user upfront to authenticate, which may disclose the user's
  credentials to the wrong service.

  We didn't release this feature in our generic CalDAV/CardDAV clients,
  mostly due to that issue.

  Anyway, I think it really starts with the server developers.
  Implementing the current spec is not that much work on the server
  side. In many cases the server configuration document could just be a
  static file!
  and
setting up a simple WebFinger end point is not that
  hard either. Actually, for our corporate server we've just created a
  few static files and some redirect magic in our .htaccess file to
  provide the WebFinger stuff.

  On the client side it's more work, because it affects the account
  setup flow a lot. But it surely is worth the efforts if more services
  support it.

  However, before even the server developers can start, it requires an
  RFC. So lets start to think about how to solve the authentication
 issue.

  cheers

  Marten


  Am 08.02.2016 um 20:00 schrieb Paul E. Jones:
  Cyrus,

  Right now it is not clear to me that an ASCO!
 T-like
solution would
  be adopted given the use of device management. Before embarking on
  this we need to take a careful look at whether any solution is
  likely to be adopted (with the biggest burden likely being on
  clients/OS vendors to support it). Given the device management
  solutions already out there, I suspect there would be little value
  to m,ost of those folks to actually support ASCOT.

  I completely agree that we should try to get a sense of the
  likelihood of success.

  Within the enterprise -- especially the larger ones -- you are
  entirely correct that device management systems provide a good
  solution for most of the employees.   However, I interact with a lot
  of smaller businesses that do not use such systems.  Many of them
  have a web hosting company host their domains and do not have IT
  staff to help them on a daily basis.  I'm skeptical that a device
 
management system would help that class of users, so arming hosting
  providers with tools they can deploy to their customers would help,
  I think.

  There are also a number of individuals who have their own domains,
  many hosted on the many, many web hosting providers out there. Same
  issue for most of them.

  So, I think there is a market need.  I suspect if we were to create
  a solution, hosting providers were to deploy it, and client
  developers were to support it, people would use it.  However, that's
  a string of "ifs".  I think it starts with the client developers.
  If there were people interested to solve the problem, I think the
  rest falls into place.

  All that said, if client developers are uninterested, there's little
  point working to solve this problem.


 As an alternative, the IETF might want to take a more serious look
  at the overall device management solutions, and see if there might
  be scope for standards in that area. That would allow us to build
  off something that is already deployed (in a number of proprietary
  solutions) but is today solving the problem of account setup.

  I think your suggestion is worthwhile independent of whether we
  solve the problem for smaller businesses and individual users of
  hosted domains.  It would good if the same solution or would address
  those needs of smaller businesses and individuals, but if it didn't,
  it's still a step forward.

  Paul


  webfinger mailing list
  webfinger@ietf.org
  https://www.ietf.org/mailman/listinfo/webfinger

  -- Marten Gajda
  CEO

  dmfs Gmb!
 H
 
Schandauer Straße 34
  01309 Dresden
  GERMANY

  phone: +49 177 4427167
  email: marten@dmfs.org

  Managing Director: Marten Gajda
  Registered address: Dresden
  Registered No.: AG Dresden HRB 34881
  VAT Reg. No.: DE303248743


  webfinger mailing list
  webfinger@ietf.org
  https://www.ietf.org/mailman/listinfo/webfinger


 -- 
 Marten Gajda
 CEO

 dmfs GmbH
 Schandauer Straße 34
 01309 Dresden
 GERMANY

 phone: +49 177 4427167
 email: marten@dmfs.org

 Managing Director: Marten Gajda
 Registered address: Dresden
 Registered No.: AG Dresden HRB 34881
 VAT Reg. No.: DE303248743


 webfinger mailing list
 webfinger@ietf.org
 https://www.ietf.org/mailman/listinfo/webfinger

------ASYJAW6UUX4J0DG4Y306LKGLG5UOZW-- From nobody Fri Jun 3 02:38:25 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14C912D65D for ; Fri, 3 Jun 2016 02:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z7VpsObw9hj for ; Fri, 3 Jun 2016 02:38:21 -0700 (PDT) Received: from mailrelay2.public.one.com (mailrelay2.public.one.com [91.198.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5C812D64B for ; Fri, 3 Jun 2016 02:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=JYKllgvu+WV4+/lUvqXJ7KpIps6GY1w+CKM7b7ElW54=; b=EVGHkgPMpHV1YRVsF/fgHvw/lysbAiHuN0LzfC0cqQtsNZZnRuIkmOx16nmlVi9BKNd4jFCBseE3u UNz3QSz6iTOTl29RzlYBMjSH+a7MWA2MbIlKuyGAE9ivCJuFpWeEHuazXhHdY5AiBV0NC+BtBtgrg5 c5Yo7oE511qovPtM= X-HalOne-Cookie: 70c01d17fc65b8a2f32119af0007ff6faadb69d3 X-HalOne-ID: e705d87f-296e-11e6-8278-b82a72d03b9b Received: from smtp.dmfs.org (unknown [79.240.231.213]) by smtpfilter2.public.one.com (Halon Mail Gateway) with ESMTPSA for ; Fri, 3 Jun 2016 09:38:17 +0000 (UTC) Received: from localhost.localdomain (p5DDA907C.dip0.t-ipconnect.de [93.218.144.124]) by smtp.dmfs.org (Postfix) with ESMTPSA id 292712B1 for ; Fri, 3 Jun 2016 11:34:18 +0200 (CEST) Message-ID: <57515008.4020003@dmfs.org> Date: Fri, 03 Jun 2016 11:38:16 +0200 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: webfinger@ietf.org References: <20160603004328.12103.qmail@ary.lan> In-Reply-To: <20160603004328.12103.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 09:38:24 -0000 Hi John, good question. I see a couple of advantages over RFC 6186 (and at least some of these have led to the development of the current draft). # user specific configuration The draft we're talking about allows a service provider to return a user specific configuration file. Some example use cases are * premium services can be included for premium users only, the client of a "free user" would not attempt to set up a service that it has no access to * user specific endpoints - consider a company with an office in Europe and an office in the US. All email addresses may share the same domain, say `example.com`, but the European users actually access IMAP under `imap.eu.example.com` and the US users access IMAP under `imap.us.example.com`. A configuration document can be smart enough to return the correct endpoint for each user, while SRV can't do that. # one document to rule them all A service configuration document contains information about all services a service provider offers. You don't need to guess which services might be there. Also, the service configuration client doesn't even have to know how to handle all the services. Ideally the configuration client would run on system level and dispatch the setup of each service found in the configuration document to the respective service handlers which are registered with the system. # additional information A service configuration document allows to integrate additional information like * OAuth2 scopes that are required to access a specific service * a link to an account management page * support/operator contact information # easier to integrate ## for clients Doing an SRV lookup is not well supported by some (or many) of the existing platforms & frameworks. Many Frameworks provide methods to resolve domains back and forth, but other record types are often not supported out of the box. We're developing Android clients for CalDAV & CardDAV and to do an SRV lookup we would have to integrate a 3rd party DNS library. Of course that 3rd party library should support DNSSEC, otherwise you can't trust the result of the SRV lookup. The draft we're talking about uses HTTP based technology, which is well supported in a secure manner by pretty much every platform/framework. ## for services Setting up DNS records is not an issue for large service providers, though it can be a problem for smaller installations if your hosting service doesn't give you such control over your DNS settings. Setting up Webfinger and a service configuration document can be quite trivial. In simple cases you can get away with a few static files on your server. In other cases a simple PHP script might solve this. # works cross domain (at least in theory) Technology like OpenID Connect allows to separate the identity provider from the actual service provider. So my email provider might not be the same as my calendar provider, but both use the same identity provider for authorization. My calendar client should be able to discover my calendars, even though my user id has a completely different domain part. Services like webfist.org can make this even more versatile and gives users full control over their service configuration document, even if their email provider doesn't support it. That's it for now. There may be other good reasons to favor a service configuration document over SRV records. Cheers, Marten Am 03.06.2016 um 02:43 schrieb John Levine: > If I may ask an obvious question, how much better in practice is this > likely to be than RFC 6186? I realize that 6186 is somewhat > inflexible and requires that the address or the local-part be the > login credential, but it is my impression that the vast majority of > mail servers are set up that way anyway. > > R's, > John > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 From nobody Fri Jun 3 06:06:15 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A083A12D0A0 for ; Fri, 3 Jun 2016 06:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUurRrPFfH0y for ; Fri, 3 Jun 2016 06:06:06 -0700 (PDT) Received: from mailrelay7.public.one.com (mailrelay7.public.one.com [91.198.169.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0D412D687 for ; Fri, 3 Jun 2016 06:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=8LUIKxLZbSUuy0/owEU+F5PAlLmAGD5nxKWfHDoAr34=; b=NhHEKgHdsMwrDn16dyRkMzqfZG9pY8PNO30ySxTOMh/U6m+3x5ChpRbAhoVIVU9NgeGPmiYfDot4a +qu8MehGFvMD7c/ukbKPGU20kUg2QLVnKaWXEOpqRpHTtXn7ejz8cDZiran2Q28HQ52P8/Kr4jqz84 XqaVaglSsYjanFLA= X-HalOne-Cookie: f6a204b96eb7733f91d495add0a54e58574bdcd3 X-HalOne-ID: eab968c1-298b-11e6-a0c6-b82a72cffc46 Received: from smtp.dmfs.org (unknown [79.240.231.213]) by smtpfilter4.public.one.com (Halon Mail Gateway) with ESMTPSA; Fri, 3 Jun 2016 13:05:59 +0000 (UTC) Received: from localhost.localdomain (linux.fritz.box [192.168.2.53]) by smtp.dmfs.org (Postfix) with ESMTPSA id 3FC7B2B1; Fri, 3 Jun 2016 15:01:59 +0200 (CEST) Message-ID: <575180B6.9010902@dmfs.org> Date: Fri, 03 Jun 2016 15:05:58 +0200 From: Marten Gajda Organization: dmfs GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Paul E. Jones , webfinger@ietf.org References: <5750B965.9040506@dmfs.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030802030601020702070906" Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 13:06:12 -0000 This is a multi-part message in MIME format. --------------030802030601020702070906 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit So how would the UI work? 1) User enters user identifier, most likely an email address, like "user@example.com" and hits "next" 2) Client sends a Webfinger request to https://exampe.com/.well-known/webfinger?... to see if there is a configuration document -> response 404 Not Found a) Client falls back to "manual setup" or another auto-configuration mechanism -> response 401 Unauthorized b) Client asks for password at "example.com" and goes back to step 2 (this time with authentication) -> response 200 Ok c) client moves on to next step 3) (optional) Client presents found services to the user to let him select the services to set up 4) Client runs the setup handler for each selected service I think in general that could work but it raises two questions: 1) How to make sure the user really understands that he's authenticating at example.com in step 2b? If the user tries to configure calendar sync with "acme-calendar.com" where his login happens to be "user@example.com" he might not be prepared to being asked for his example.com password. Maybe I'm just paranoid or overcautious, but I think that it might easily happen that the users sends his acme-calendar.com password to example.com in that case (since Basic authentication is still the most common mechanism, the client basically sends the password in plain text). 2) How does the client know which credentials to use to set up the individual services in step 4? Should the client ask the user for the credentials for each service or can it assume that some of them share the same credentials? Is that something an auto-configuration document can help with? Ideally the server supports some kind of SSO mechanism like OpenID Connect, so you don't need to enter your password multiple times. But a working auto-configuration is really the precondition for this, because an OpenID Connect implementations needs a way to discover the OAuth2 scope tokens to request from the server and auto-configuration is really the way to do that, IMO. For this it would be helpful to have some mechanism to request a broader scope from the user (without allowing him to switch to a different account), but that's a different topic I guess. Cheers, Marten Am 03.06.2016 um 07:42 schrieb Paul E. Jones: > Marten, > > At the end of all of all of this, the email client is still going to > need the password for the SMTP and IMAP/POP3 service. I guess some > even use different passwords for those, since email clients ask for it. > > I personally use Google Calendar with my email and authenticate that > separately today (which looks like oauth given how it integrates). > > So what I would expect is a UI that asks for the passwords for each > service that is being accessed, much like today. We really can't get > around that. The client just has to make it clear to the user. > > I only suggested to use the same password to retrieve the mail config > as for using email. In truth, I don't even see the security risk with > that, as I can find nearly any server. Thus, it's like security > through obfuscation, which we know isn't security. But, if we insist > on securing it, use the email password (ideally that being the same). > > Calendar or other services could each have their own like relations > discovered via WebFinger. Or, that info could be bundled with the > email config. Either way, I think we just have to ensure the UI is > clear, but the starting point be the email password. > > Perhaps I'm overlooking something, but I'm otherwise confused how the > client will get that SMTP and IMAP password. > > Paul > > ------------------------------------------------------------------------ > *From:* Marten Gajda > *Sent:* June 3, 2016 12:55:33 AM GMT+02:00 > *To:* "Paul E. Jones" , "webfinger@ietf.org" > > *Subject:* Re: [webfinger] [apps-discuss] Mail client configuration > via WebFinger > > Hi Paul, > > the problem is that often it's possible to use the same user id with > different services. A common example is iCloud, which allows you to use > your Gmail address as the login name. > In that case, to set up calendar synchronization with iCloud, a user > would enter his login (which is the Gmail address) to start the > auto-configuration. Of course a client would first do a Webfinger > request ongmail.com in that case. If that requires authentication the > client needs to ask for the Gmail password first. That's where you > really confuse users and it might happen that they enter their iCloud > password instead, which then might be revealed to Gmail. > > To avoid this, it has been suggested to give users an (additional) acct: > URI type login name which always contains the domain of the actual > service provider. So the user would enter something like > user%40gmail.com @icloud.com or maybe some generated ID like > xxxx-xxxx-xxxx-xxxx@icloud.com, but I don't see how we could teach users > to understand that they need to enter a different identifier to perform > an auto-configuration. > > Cheers, > > Marten > > Am 01.06.2016 um 20:39 schrieb Paul E. Jones: > > Marten, I would truly love to see this move forward and have had > an intention of writing a draft myself. I'd be happy to > collaborate with you on one. Just in the past couple of weeks, I > had to help somebody set up their email client remotely to use an > IMAP server. It was incredibly painful for me to try to step them > through the process not having access to their screen, etc. After > that experience, I'm even more convinced that a solution to this > pr! oblem is needed. I personally don't think learning the > existing of an account is an issue, since I can discover that by > merely sending an email. However, if that is a concern, then the > simplest solution is for the server that is providing the > configuration document to requires authentication regardless of > the user ID presented. If I were to deploy this in my own > environment, I would use the same user ID and password to retrieve > the configuration document as is used to log into the IMAP for > SMTP server. Interfacing with the auth functions that already > exist would be fairly trivial. I don't fully understand why we > would want to have a different authentication mechanism, given > that (at least in every case I've seen) the IMAP/POP and SMTP > services generally validate users from the same authentication > functions behind the scenes. Sending credentials over HTTPS to a > server to then validate i! n the same manner seems to make a lot > of sense. So the solution I had in mind would be to query using > WebFinger to get the usual output for "paulej@packetizer.com". In > that JRD that is returned would be a link relation type > "mailconfig" that refers to a resource like > https://dublin.packetizer.com/mailconfig/?user=paulej. That web > interface would require just basic authentication (since the > password would be encrypted with TLS) and authenticate with the > auth function like the other mail services. If auth is successful, > it would return the JSON structure that would contain the mail > configuration information. I could easily have something like that > working very quickly. I'd be very hesitant to introduce more > complex authentication or identity procedures, personally. As for > the content of the file returned, while! I very much think we > should only be using the latest security procedures, we have to > allow the document to return things like "use SSLv2" if that is > indeed what the IMAP server supports. These policies are really > for the IT folks to dictate and I don't think the document we > produce should dictate the security mechanisms. It's really the > place for other documents to dictate best practices and any > suggestion we might make might be wrong in 5 years. :) That said, > I'm certainly favorable to simplicity and have no strong view on > exactly how the config information should be structured. I wrote > up an example > https://tools.ietf.org/html/draft-ietf-appsawg-webfinger-03 that > was overly trivial. It did not consider the possibility that a > client might have multiple protocols, for example. I think it is > important to provide a JS! ON document that is an array of mail > transmission options then an array of mail retrieval options. > Within each array, I would expect an array of configuration > options ordered in the preferred order of the administrator. Thus, > the preferred security procedures can be conveyed. So, "IMAP" and > the host might be listed a few times with different ports and > transports (SSL and TLS and, gulp, no security). I have seen some > services offered where the host name actually differs based on > one's geographic location. Thus, multiple servers names might need > to be conveyed, along with perhaps checking the physical location > of the user. (But, that detail doesn't have to be a part of the > spec.) Importantly, since the whole process can be automated, then > it is entirely possible for the client to re-check the recommended > configuration information from time-to-time to see if there is a > change in the configuration details. Paul ------ Original Message > ------ From: "Marten Gajda" To: "Paul E. Jones" > ; "webfinger@ietf.org" > Sent: 6/1/2016 9:59:58 AM Subject: Re: [webfinger] [apps-discuss] > Mail client configuration via WebFinger > > Hi Paul, we've brought up this topic during the last > CalConnect conference and it was decided to revitalize the TC > where the draft you mentioned originated from. We have some > interest from software vendors and users to get this solved. > As mentioned before, one of the major problems to solve is > authentication. The issue raised was that the pure existence > of a link to a configuration document in the webfinger > response can reveal theexistence of the account. On the other > hand, requiring authentication for auto configuration results > in other possible security issues and a poor user experience. > The latter ones could probably be solved by making OpenID > Connect a requirement for auto configuration, which, on the > other hand, adds another layer of complexity and probably > makes it less attractive to smaller vendors. Does anyone see > any possible solution to that? I'd also like to suggest a few > changes in the structure of the configuration document and to > drop support for services not protected by TLS or any other > transport security layer. I'll post an updated draft as a > basis for discussion. I'm happy to join the upcoming IEFT > meeting in Berlin and have a BOF or something if there is > enough interest in that. cheers Marten Am 09.02.2016 um 02:03 > schrieb Paul E. Jones: > > Marten, Thanks for the encouraging words; it sounds like > you understand the problem that needs to be solved. I > always felt the server side was the trivial part. As you > said, it's possible to set up a simple WebFinger server > with a static file (or sets of files), an .htaccess file, > etc. I use a server that pulls data from a database, > myself. Importantly, though, the WebFinger protocol is > very simple (and I have to thank a number of folks who > forced that simplicity), so I see the server side as being > far less of a barrier. Hosting providers, for example, > could very quickly and easily support this server-side. > The clients are the challenge. As others have noted, this > requires code changes in the clients and deployment of the > clients. I'm encoura! ged that you're working on client > code. :) Having an RFC is going to be an extremely > important step to actually seeing this problem solved. > That said, I did not want to spend time on something that > would be met with total rejection. It sounds like there is > at least enough interest to start a meaningful dialog, so > I'll try to put together a draft soon and we can go from > there. If you're interested to collaborate on that, you're > certainly welcome. Paul ------ Original Message ------ > From: "Marten Gajda" To: > webfinger@ietf.org Sent: 2/8/2016 5:54:58 PM Subject: Re: > [webfinger] [apps-discuss] Mail client configuration via > WebFinger > > Hi Paul, as a client developer I'm very interested in > this topic. We've act! ually implemented > draft-daboo-aggregated-service-discovery-03 and there > is at least one groupware server product which also > supports it. While working on our implementation we've > identified a few minor issues with the latest draft > and we've already discussed them with Cyrus. I think > most of these issues are solved easily. Though, the > major issue has not been addressed yet. It's the issue > mentioned by Stephen. Under certain conditions a > client might have to ask the user upfront to > authenticate, which may disclose the user's > credentials to the wrong service. We didn't release > this feature in our generic CalDAV/CardDAV clients, > mostly due to that issue. Anyway, I think it really > starts with the server developers. Implementing the > current spec is not that much work on the server side. > In many cases the server configuration document could > just be a static file! and setting up a simple > WebFinger end point is not that hard either. Actually, > for our corporate server we've just created a few > static files and some redirect magic in our .htaccess > file to provide the WebFinger stuff. On the client > side it's more work, because it affects the account > setup flow a lot. But it surely is worth the efforts > if more services support it. However, before even the > server developers can start, it requires an RFC. So > lets start to think about how to solve the > authentication issue. cheers Marten Am 08.02.2016 um > 20:00 schrieb Paul E. Jones: > > Cyrus, > > Right now it is not clear to me that an ASCO! > T-like solution would be adopted given the use > of device management. Before embarking on this > we need to take a careful look at whether any > solution is likely to be adopted (with the > biggest burden likely being on clients/OS > vendors to support it). Given the device > management solutions already out there, I > suspect there would be little value to m,ost > of those folks to actually support ASCOT. > > I completely agree that we should try to get a > sense of the likelihood of success. Within the > enterprise -- especially the larger ones -- you > are entirely correct that device management > systems provide a good solution for most of the > employees. However, I interact with a lot of > smaller businesses that do not use such systems. > Many of them have a web hosting company host their > domains and do not have IT staff to help them on a > daily basis. I'm skeptical that a device > management system would help that class of users, > so arming hosting providers with tools they can > deploy to their customers would help, I think. > There are also a number of individuals who have > their own domains, many hosted on the many, many > web hosting providers out there. Same issue for > most of them. So, I think there is a market need. > I suspect if we were to create a solution, hosting > providers were to deploy it, and client developers > were to support it, people would use it. However, > that's a string of "ifs". I think it starts with > the client developers. If there were people > interested to solve the problem, I think the rest > falls into place. All that said, if client > developers are uninterested, there's little point > working to solve this problem. > > As an alternative, the IETF might want to take > a more serious look at the overall device > management solutions, and see if there might > be scope for standards in that area. That > would allow us to build off something that is > already deployed (in a number of proprietary > solutions) but is today solving the problem of > account setup. > > I think your suggestion is worthwhile independent > of whether we solve the problem for smaller > businesses and individual users of hosted domains. > It would good if the same solution or would > address those needs of smaller businesses and > individuals, but if it didn't, it's still a step > forward. Paul > ------------------------------------------------------------------------ > webfinger mailing list webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > -- Marten Gajda CEO dmfs Gmb! H Schandauer Straße 34 > 01309 Dresden GERMANY phone: +49 177 4427167 email: > marten@dmfs.org Managing Director: Marten Gajda > Registered address: Dresden Registered No.: AG Dresden > HRB 34881 VAT Reg. No.: DE303248743 > ------------------------------------------------------------------------ > webfinger mailing list webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 > Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org > Managing Director: Marten Gajda Registered address: Dresden > Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 > ------------------------------------------------------------------------ > webfinger mailing list webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------030802030601020702070906 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
So how would the UI work?

1) User enters user identifier, most likely an email address, like "user@example.com" and hits "next"

2) Client sends a Webfinger request to https://exampe.com/.well-known/webfinger?... to see if there is a configuration document

  -> response 404 Not Found
   a) Client falls back to "manual setup" or another auto-configuration mechanism

  -> response 401 Unauthorized
   b) Client asks for password at "example.com" and goes back to step 2 (this time with authentication)

  -> response 200 Ok
   c) client moves on to next step

3) (optional) Client presents found services to the user to let him select the services to set up

4) Client runs the setup handler for each selected service


I think in general that could work but it raises two questions:

1) How to make sure the user really understands that he's authenticating at example.com in step 2b? If the user tries to configure calendar sync with "acme-calendar.com" where his login happens to be "user@example.com" he might not be prepared to being asked for his example.com password. Maybe I'm just paranoid or overcautious, but I think that it might easily happen that the users sends his acme-calendar.com password to example.com in that case (since Basic authentication is still the most common mechanism, the client basically sends the password in plain text).

2) How does the client know which credentials to use to set up the individual services in step 4? Should the client ask the user for the credentials for each service or can it assume that some of them share the same credentials? Is that something an auto-configuration document can help with?

Ideally the server supports some kind of SSO mechanism like OpenID Connect, so you don't need to enter your password multiple times. But a working auto-configuration is really the precondition for this, because an OpenID Connect implementations needs a way to discover the OAuth2 scope tokens to request from the server and auto-configuration is really the way to do that, IMO. For this it would be helpful to have some mechanism to request a broader scope from the user (without allowing him to switch to a different account), but that's a different topic I guess.

Cheers,

Marten





Am 03.06.2016 um 07:42 schrieb Paul E. Jones:
Marten,

At the end of all of all of this, the email client is still going to need the password for the SMTP and IMAP/POP3 service. I guess some even use different passwords for those, since email clients ask for it.

I personally use Google Calendar with my email and authenticate that separately today (which looks like oauth given how it integrates).

So what I would expect is a UI that asks for the passwords for each service that is being accessed, much like today. We really can't get around that. The client just has to make it clear to the user.

I only suggested to use the same password to retrieve the mail config as for using email. In truth, I don't even see the security risk with that, as I can find nearly any server. Thus, it's like security through obfuscation, which we know isn't security. But, if we insist on securing it, use the email password (ideally that being the same).

Calendar or other services could each have their own like relations discovered via WebFinger. Or, that info could be bundled with the email config. Either way, I think we just have to ensure the UI is clear, but the starting point be the email password.

Perhaps I'm overlooking something, but I'm otherwise confused how the client will get that SMTP and IMAP password.

Paul

From: Marten Gajda <marten@dmfs.org>
Sent: June 3, 2016 12:55:33 AM GMT+02:00
To: "Paul E. Jones" <paulej@packetizer.com>, "webfinger@ietf.org" <webfinger@ietf.org>
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger

Hi Paul,

the problem is that often it's possible to use the same user id with
different services. A common example is iCloud, which allows you to use
your Gmail address as the login name.
In that case, to set up calendar synchronization with iCloud, a user
would enter his login (which is the Gmail address) to start the
auto-configuration. Of course a client would first do a Webfinger
request on gmail.com in that case. If that requires authentication the
client needs to ask for the Gmail password first. That's where you
really confuse users and it might happen that they enter their iCloud
password instead, which then might be revealed to Gmail.

To avoid this, it has been suggested to give users an (additional) acct:
URI type login name which always contains the domain of the actual
service provider. So the user would enter something like
user%40gmail.com@icloud.com or maybe some generated ID like
xxxx-xxxx-xxxx-xxxx@icloud.com, but I don't see how we could teach users
to understand that they need to enter a different identifier to perform
an auto-configuration.

Cheers,

Marten

Am 01.06.2016 um 20:39 schrieb Paul E. Jones:

 Marten,

 I would truly love to see this move forward and have had an intention
 of writing a draft myself.  I'd be happy to collaborate with you on
 one.  Just in the past couple of weeks, I had to help somebody set up
 their email client remotely to use an IMAP server.  It was incredibly
 painful for me to try to step them through the process not having
 access to their screen, etc.  After that experience, I'm even more
 convinced that a solution to this pr!
 oblem is
needed.

 I personally don't think learning the existing of an account is an
 issue, since I can discover that by merely sending an email.  However,
 if that is a concern, then the simplest solution is for the server
 that is providing the configuration document to requires
 authentication regardless of the user ID presented.

 If I were to deploy this in my own environment, I would use the same
 user ID and password to retrieve the configuration document as is used
 to log into the IMAP for SMTP server.  Interfacing with the auth
 functions that already exist would be fairly trivial.  I don't fully
 understand why we would want to have a different authentication
 mechanism, given that (at least in every case I've seen) the IMAP/POP
 and SMTP services generally validate users from the same
 authentication functions behind the scenes.  Sending credentials over
 HTTPS to a server to then validate i!
 n the
same manner seems to make a
 lot of sense.

 So the solution I had in mind would be to query using WebFinger to get
 the usual output for "paulej@packetizer.com".  In that JRD that is
 returned would be a link relation type "mailconfig" that refers to  a
 resource like https://dublin.packetizer.com/mailconfig/?user=paulej. 
 That web interface would require just basic authentication (since the
 password would be encrypted with TLS) and authenticate with the auth
 function like the other mail services.  If auth is successful, it
 would return the JSON structure that would contain the mail
 configuration information.  I could easily have something like that
 working very quickly.

 I'd be very hesitant to introduce more complex authentication or
 identity procedures, personally.

 As for the content of the file returned, while!
  I very
much think we
 should only be using the latest security procedures, we have to allow
 the document to return things like "use SSLv2" if that is indeed what
 the IMAP server supports.  These policies are really for the IT folks
 to dictate and I don't think the document we produce should dictate
 the security mechanisms.  It's really the place for other documents to
 dictate best practices and any suggestion we might make might be wrong
 in 5 years. :)

 That said, I'm certainly favorable to simplicity and have no strong
 view on exactly how the config information should be structured.  I
 wrote up an example
 https://tools.ietf.org/html/draft-ietf-appsawg-webfinger-03 that was
 overly trivial.  It did not consider the possibility that a client
 might have multiple protocols, for example.  I think it is important
 to provide a JS!
 ON
document that is an array of mail transmission
 options then an array of mail retrieval options.  Within each array, I
 would expect an array of configuration options ordered in the
 preferred order of the administrator.  Thus, the preferred security
 procedures can be conveyed.  So, "IMAP" and the host might be listed a
 few times with different ports and transports (SSL and TLS and, gulp,
 no security).  I have seen some services offered where the host name
 actually differs based on one's geographic location.  Thus, multiple
 servers names might need to be conveyed, along with perhaps checking
 the physical location of the user.  (But, that detail doesn't have to
 be a part of the spec.)

 Importantly, since the whole process can be automated, then it is
 entirely possible for the client to re-check the recommended
 configuration information from time-to-time to see if there is a
 change in the
configuration details.

 Paul

 ------ Original Message ------
 From: "Marten Gajda" <marten@dmfs.org>
 To: "Paul E. Jones" <paulej@packetizer.com>; "webfinger@ietf.org"
 <webfinger@ietf.org>
 Sent: 6/1/2016 9:59:58 AM
 Subject: Re: [webfinger] [apps-discuss] Mail client configuration via
 WebFinger


 Hi Paul,

 we've brought up this topic during the last CalConnect conference and it
 was decided to revitalize the TC where the draft you mentioned
 originated from. We have some interest from software vendors and users
 to get this solved.

 As mentioned before, one of the major problems to solve is
 authentication. The issue raised was that the pure existence of a link
 to a configuration document in the webfinger response can reveal the
existence of the account. On the other hand, requiring authentication
 for auto configuration results in other possible security issues and a
 poor user experience. The latter ones could probably be solved by making
 OpenID Connect a requirement for auto configuration, which, on the other
 hand, adds another layer of complexity and probably makes it less
 attractive to smaller vendors.

 Does anyone see any possible solution to that?

 I'd also like to suggest a few changes in the structure of the
 configuration document and to drop support for services not protected by
 TLS or any other transport security layer. I'll post an updated draft as
 a basis for discussion.

 I'm happy to join the upcoming IEFT meeting in Berlin and have a BOF or
 something if there is enough interest in that.

 cheers

 Marten




 Am 09.02.2016 um 02:03 schrieb Paul E. Jones:

  Marten,

  Thanks for the encouraging words; it sounds like you understand the
  problem that needs to be solved.

  I always felt the server side was the trivial part.  As you said, it's
  possible to set up a simple WebFinger server with a static file (or
  sets of files), an .htaccess file, etc.  I use a server that pulls
  data from a database, myself.  Importantly, though, the WebFinger
  protocol is very simple (and I have to thank a number of folks who
  forced that simplicity), so I see the server side as being far less of
  a barrier.  Hosting providers, for example, could very quickly and
  easily support this server-side.

  The clients are the challenge.  As others have noted, this requires
  code changes in the clients and deployment of the clients.  I'm
  encoura!
 ged that
you're working on client code. :)

  Having an RFC is going to be an extremely important step to actually
  seeing this problem solved.  That said, I did not want to spend time
  on something that would be met with total rejection.  It sounds like
  there is at least enough interest to start a meaningful dialog, so
  I'll try to put together a draft soon and we can go from there.  If
  you're interested to collaborate on that, you're certainly welcome.

  Paul

  ------ Original Message ------
  From: "Marten Gajda" <marten@dmfs.org>
  To: webfinger@ietf.org
  Sent: 2/8/2016 5:54:58 PM
  Subject: Re: [webfinger] [apps-discuss] Mail client configuration via
  WebFinger


  Hi Paul,

  as a client developer I'm very interested in this topic. We've
  act!
 ually
implemented draft-daboo-aggregated-service-discovery-03 and
  there is at least one groupware server product which also supports
 it.

  While working on our implementation we've identified a few minor
  issues with the latest draft and we've already discussed them with
  Cyrus. I think most of these issues are solved easily.

  Though, the major issue has not been addressed yet. It's the issue
  mentioned by Stephen. Under certain conditions a client might have to
  ask the user upfront to authenticate, which may disclose the user's
  credentials to the wrong service.

  We didn't release this feature in our generic CalDAV/CardDAV clients,
  mostly due to that issue.

  Anyway, I think it really starts with the server developers.
  Implementing the current spec is not that much work on the server
  side. In many cases the server configuration document could just be a
  static file!
  and
setting up a simple WebFinger end point is not that
  hard either. Actually, for our corporate server we've just created a
  few static files and some redirect magic in our .htaccess file to
  provide the WebFinger stuff.

  On the client side it's more work, because it affects the account
  setup flow a lot. But it surely is worth the efforts if more services
  support it.

  However, before even the server developers can start, it requires an
  RFC. So lets start to think about how to solve the authentication
 issue.

  cheers

  Marten


  Am 08.02.2016 um 20:00 schrieb Paul E. Jones:

  Cyrus,


  Right now it is not clear to me that an ASCO!
 T-like
solution would
  be adopted given the use of device management. Before embarking on
  this we need to take a careful look at whether any solution is
  likely to be adopted (with the biggest burden likely being on
  clients/OS vendors to support it). Given the device management
  solutions already out there, I suspect there would be little value
  to m,ost of those folks to actually support ASCOT.


  I completely agree that we should try to get a sense of the
  likelihood of success.

  Within the enterprise -- especially the larger ones -- you are
  entirely correct that device management systems provide a good
  solution for most of the employees.   However, I interact with a lot
  of smaller businesses that do not use such systems.  Many of them
  have a web hosting company host their domains and do not have IT
  staff to help them on a daily basis.  I'm skeptical that a device
 
management system would help that class of users, so arming hosting
  providers with tools they can deploy to their customers would help,
  I think.

  There are also a number of individuals who have their own domains,
  many hosted on the many, many web hosting providers out there. Same
  issue for most of them.

  So, I think there is a market need.  I suspect if we were to create
  a solution, hosting providers were to deploy it, and client
  developers were to support it, people would use it.  However, that's
  a string of "ifs".  I think it starts with the client developers.
  If there were people interested to solve the problem, I think the
  rest falls into place.

  All that said, if client developers are uninterested, there's little
  point working to solve this problem.



 As an alternative, the IETF might want to take a more serious look
  at the overall device management solutions, and see if there might
  be scope for standards in that area. That would allow us to build
  off something that is already deployed (in a number of proprietary
  solutions) but is today solving the problem of account setup.


  I think your suggestion is worthwhile independent of whether we
  solve the problem for smaller businesses and individual users of
  hosted domains.  It would good if the same solution or would address
  those needs of smaller businesses and individuals, but if it didn't,
  it's still a step forward.

  Paul



  webfinger mailing list
  webfinger@ietf.org
  https://www.ietf.org/mailman/listinfo/webfinger


  -- Marten Gajda
  CEO

  dmfs Gmb!
 H
 
Schandauer Straße 34
  01309 Dresden
  GERMANY

  phone: +49 177 4427167
  email: marten@dmfs.org

  Managing Director: Marten Gajda
  Registered address: Dresden
  Registered No.: AG Dresden HRB 34881
  VAT Reg. No.: DE303248743



  webfinger mailing list
  webfinger@ietf.org
  https://www.ietf.org/mailman/listinfo/webfinger




 -- 
 Marten Gajda
 CEO

 dmfs GmbH
 Schandauer Straße 34
 01309 Dresden
 GERMANY

 phone: +49 177 4427167
 email: marten@dmfs.org

 Managing Director: Marten Gajda
 Registered address: Dresden
 Registered No.: AG Dresden HRB 34881
 VAT Reg. No.: DE303248743



 webfinger mailing list
 webfinger@ietf.org
 https://www.ietf.org/mailman/listinfo/webfinger





-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------------030802030601020702070906-- From nobody Fri Jun 3 06:40:26 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59F312D1A4 for ; Fri, 3 Jun 2016 06:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbOGOr_g9fgQ for ; Fri, 3 Jun 2016 06:40:22 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9AF012D19B for ; Fri, 3 Jun 2016 06:40:22 -0700 (PDT) Received: from [156.106.219.128] ([156.106.219.128]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u53DeHa5007684 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 09:40:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1464961219; bh=hzM4q7m4kokR+FauhPUY+koTl1TccLUWCNxqbw3B7OY=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=XXmR7hfBDyOKESJmx84JpjKHcKekbQh/CIjBe9mFUftnpzzL83mU8AD5SA1MRRDxb XEX9/lBYopDkCrBFmUcxX8nNrrxI6FRGIbhlHQCKdZ4KWxHJvtFfLaWXvfqacyjEeQ PnWSI+5BR+pj7gbjXQTlO+qz9h34+xJUUbWZ5+v8= From: "Paul E. Jones" To: "Marten Gajda" , "webfinger@ietf.org" Date: Fri, 03 Jun 2016 13:40:20 +0000 Message-Id: In-Reply-To: <575180B6.9010902@dmfs.org> User-Agent: eM_Client/6.0.24928.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBB7BB5188-A9E4-4C2D-B0FC-89C96C086F43" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Fri, 03 Jun 2016 09:40:19 -0400 (EDT) Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 13:40:26 -0000 --------=_MBB7BB5188-A9E4-4C2D-B0FC-89C96C086F43 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Marten, >So how would the UI work? > >1) User enters user identifier, most likely an email address, like=20 >mailto:user@example.com and hits "next" > >2) Client sends a Webfinger request to=20 >https://exampe.com/.well-known/webfinger?... to see if there is a=20 >configuration document > > -> response 404 Not Found > a) Client falls back to "manual setup" or another auto-configuration= =20 >mechanism > > -> response 401 Unauthorized One should not get 401 querying the WebFinger information for the user. = =20 What should happen is that the server should return a JSON object that=20 contains a link relation that might look like this: { "rel " : "mail-config", "href " :=20 "https://mailserver.example.com/config?user=3Dpaulej%40packetizer.com" } Or something like that. The mail client should query that URI it is=20 that one that should result in a potential 401. The JSON format that=20 would come back here would need to be something we define. It could be=20 based on JRD, but would not have to be. Otherwise, I think the flow looks right. > > b) Client asks for password at "example.com" and goes back to step = 2=20 >(this time with authentication) > > -> response 200 Ok > c) client moves on to next step > >3) (optional) Client presents found services to the user to let him=20 >select the services to set up > >4) Client runs the setup handler for each selected service > > >I think in general that could work but it raises two questions: > >1) How to make sure the user really understands that he's=20 >authenticating at example.com in step 2b? If the user tries to=20 >configure calendar sync with "acme-calendar.com" where his login=20 >happens to be mailto:user@example.com he might not be prepared to being= =20 >asked for his example.com password. Maybe I'm just paranoid or=20 >overcautious, but I think that it might easily happen that the users=20 >sends his acme-calendar.com password to example.com in that case (since= =20 >Basic authentication is still the most common mechanism, the client=20 >basically sends the password in plain text). Yeah, that's a valid concern. The only thing I can suggest is that the=20 Subject CN from the certificate is presented to the user. =20 Alternatively, there could be two passwords: one that is the=20 "configuration password" and one that is the email password. However, I= =20 don't think two passwords will help us. If I want to hack somebody and=20 can gain access to their WF config, I can auto-config their email client= =20 to point to my own IMAP server and just retrieve the password that way. So, I think we have to rely on the certificate presented to the mail=20 client and the user will have to know to trust it. The mail provider=20 can tell the user "when configuring email, ensure that the configuration= =20 server is mailconfig.example.com and do not provide a password if that=20 is not the name of the configuration server indicated." If the mail config information is not protected with a password, we=20 probably would want the customer to verify that the SMTP server=20 information is correct before the password is provided. These would be=20 the steps users would take if performing manual configuration, but the=20 software presents that information to the user without the user having=20 to enter it. > >2) How does the client know which credentials to use to set up the=20 >individual services in step 4? Should the client ask the user for the=20 >credentials for each service or can it assume that some of them share=20 >the same credentials? Is that something an auto-configuration document=20 >can help with? It would be nice if there is a config indicator that says "SMTP server=20 and IMAP server passwords are the same", so the client does not have to=20 ask. If we use a "config password" then we could even have the server tell=20 the client the password for services, which would transparently allow=20 those to be different. Alternatively, the client will have to ask each=20 about each one. For calendaring services, then yes: the client would have to ask the=20 user. It could ask if it's the same or different than the email=20 password or the config password. For some services, the authentication=20 mechanisms will be entirely different (like Google Calendar). The mail=20 client will just have to know how to access the service. For that=20 reason, I'm a little hesitant to suggest including calendaring service=20 config along with the email config data. We could have each of those=20 services listed in the users' WebFinger document. For example, I might=20 have this entry in my WF document: { "rel" : "calendar" "href" : "urn:whatever:google" } Note I did not provide a URL. The reason is that this is an entirely=20 different service that has an entirely different access method. Maybe=20 the client can ask the user "is paulej@packetizer.com our user ID for=20 your Google calendar?" In my case, I don't think it is. Certainly,=20 it's not my gmail ID. And, I would not want to advertise that to the=20 world, necessarily. Anyway, I think we should limit the scope of what=20 we try to do to things that are standard OR we define a generic URN that= =20 a client will just have to know how to deal with. >Ideally the server supports some kind of SSO mechanism like OpenID=20 >Connect, so you don't need to enter your password multiple times. But a= =20 >working auto-configuration is really the precondition for this, because= =20 >an OpenID Connect implementations needs a way to discover the OAuth2=20 >scope tokens to request from the server and auto-configuration is=20 >really the way to do that, IMO. For this it would be helpful to have=20 >some mechanism to request a broader scope from the user (without=20 >allowing him to switch to a different account), but that's a different=20 >topic I guess. I definitely like the idea of SSO. But, I struggle to see how we would=20 use this in practice with mail autoconfig since SMTP, IMAP, and POP=20 servers require a password, anyway. If we use that as a means to have=20 those passwords provided behind the scenes (as I indicated above), that=20 might be a good argument for using OpenID Connect. In that way, the ISP= =20 can also ensure that passwords are REALLY complex and unknown even to=20 the user. Not a bad practice, in that we can view those passwords as=20 complex tokens. Would that kind of use of OpenID Connect to retrieve the password be=20 workable? (I'll admit I don't have so much experience with OpenID=20 Connect. I implemented OpenID 2.0, but that's not ideal for what we'd=20 want to accomplish here. I don't have a good feel for how Connect might= =20 make this better.) Paul --------=_MBB7BB5188-A9E4-4C2D-B0FC-89C96C086F43 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Marten,
 
 
So how would the UI work?

1) User enter= s user identifier, most likely an email address, like mailto:user@example.com= and hits "next"

2) Client sends a Webfinger request to htt= ps://exampe.com/.well-known/webfinger?... to see if there is a configur= ation document

  -> response 404 Not Found
  = a) Client falls back to "manual setup" or another auto-configuration mecha= nism

  -> response 401 Unauthorized
 
One should not get 401 querying the WebFinger information for the user= .  What should happen is that the server should return a JSON object= that contains a link relation that might look like this:
{
    "rel " :  "mail-config",
    "href " : "https://mailserver.example.com/config?us= er=3Dpaulej%40packetizer.com"
}
 
Or something like that.  The mail client should query that URI= it is that one that should result in a potential 401.  The JSON forma= t that would come back here would need to be something we define.  = It could be based on JRD, but would not have to be.
 
Otherwise, I think the flow looks right.
 
 

   b) Client asks for password= at "example.com" and goes back to step 2 (this time with authentication)
  -> response 200 Ok
   c) client moves on to= next step

3) (optional) Client presents found services to the user= to let him select the services to set up

4) Client runs the setup= handler for each selected service


I think in general that could= work but it raises two questions:

1) How to make sure the user real= ly understands that he's authenticating at example.com in step 2b? If the= user tries to configure calendar sync with "acme-calendar.com" where his= login happens to be mailto:user@example.com he might not be prepared to being= asked for his example.com password. Maybe I'm just paranoid or overcautiou= s, but I think that it might easily happen that the users sends his acme-ca= lendar.com password to example.com in that case (since Basic authentication= is still the most common mechanism, the client basically sends the passwor= d in plain text).
 
Yeah, that's a valid concern.  The only thing I can suggest is= that the Subject CN from the certificate is presented to the user. = Alternatively, there could be two passwords: one that is the "configuratio= n password" and one that is the email password.  However, I don't thin= k two passwords will help us.  If I want to hack somebody and can gain= access to their WF config, I can auto-config their email client to point= to my own IMAP server and just retrieve the password that way.
 
So, I think we have to rely on the certificate presented to the mail= client and the user will have to know to trust it.  The mail provider= can tell the user "when configuring email, ensure that the configuration= server is mailconfig.example.com and do not provide a password if that = is not the name of the configuration server indicated."
 
If the mail config information is not protected with a password, we= probably would want the customer to verify that the SMTP server informatio= n is correct before the password is provided.  These would be the step= s users would take if performing manual configuration, but the software = presents that information to the user without the user having to enter it.<= /DIV>
 
 

2) How does the client know which credenti= als to use to set up the individual services in step 4? Should the client= ask the user for the credentials for each service or can it assume that= some of them share the same credentials? Is that something an auto-configu= ration document can help with?
 
It would be nice if there is a config indicator that says "SMTP server= and IMAP server passwords are the same", so the client does not have to= ask.
 
If we use a "config password" then we could even have the server tell= the client the password for services, which would transparently allow thos= e to be different.  Alternatively, the client will have to ask each= about each one.
 
For calendaring services, then yes: the client would have to ask the= user.  It could ask if it's the same or different than the email pass= word or the config password.  For some services, the authentication= mechanisms will be entirely different (like Google Calendar).  The= mail client will just have to know how to access the service.  For= that reason, I'm a little hesitant to suggest including calendaring servic= e config along with the email config data.  We could have each of thos= e services listed in the users' WebFinger document.  For example, I= might have this entry in my WF document:
{
    "rel" : "calendar"
    "href" : "urn:whatever:google"
}
 
Note I did not provide a URL.  The reason is that this is an enti= rely different service that has an entirely different access method. = Maybe the client can ask the user "is paulej@packetizer.com our user ID for your Google calendar?"&= nbsp; In my case, I don't think it is.  Certainly, it's not my gmail= ID.  And, I would not want to advertise that to the world, necessaril= y.  Anyway, I think we should limit the scope of what we try to do = to things that are standard OR we define a generic URN that a client will= just have to know how to deal with.
 
 
Ideally the server supports some kind of SSO= mechanism like OpenID Connect, so you don't need to enter your password= multiple times. But a working auto-configuration is really the preconditio= n for this, because an OpenID Connect implementations needs a way to discov= er the OAuth2 scope tokens to request from the server and auto-configuratio= n is really the way to do that, IMO. For this it would be helpful to have= some mechanism to request a broader scope from the user (without allowing= him to switch to a different account), but that's a different topic I gues= s.
 
I definitely like the idea of SSO.  But, I struggle to see how= we would use this in practice with mail autoconfig since SMTP, IMAP, and= POP servers require a password, anyway.  If we use that as a means= to have those passwords provided behind the scenes (as I indicated above),= that might be a good argument for using OpenID Connect.  In that way,= the ISP can also ensure that passwords are REALLY complex and unknown even= to the user.  Not a bad practice, in that we can view those passwords= as complex tokens.
 
Would that kind of use of OpenID Connect to retrieve the password be= workable?  (I'll admit I don't have so much experience with OpenID= Connect.  I implemented OpenID 2.0, but that's not ideal for what = we'd want to accomplish here.  I don't have a good feel for how Connec= t might make this better.)
 
Paul
 
--------=_MBB7BB5188-A9E4-4C2D-B0FC-89C96C086F43-- From nobody Fri Jun 3 07:44:28 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A75F12D510 for ; Fri, 3 Jun 2016 07:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJgs6fBNiYP2 for ; Fri, 3 Jun 2016 07:44:23 -0700 (PDT) Received: from mailrelay1.public.one.com (mailrelay1.public.one.com [91.198.169.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8337712D1B1 for ; Fri, 3 Jun 2016 07:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=ONgUPMSficVlg3heyA9GgSB8b1sJL1FzWtSuoRIHswI=; b=jq4CsxKpOWev82S7xyFLwDfiENrJf7n61ZidEdd4VSCqxouRoM/iBKToLQSUbvaRqkojdcxRQQBFT IcGyTHoLX1GrwhKs0IfH089pjAfOHx+rCGeNAx7mV1ncLHDSL4qTcByzor/UMN/UKkyVCw5hwXBnrF mthxGEEM8wC91qoI= X-HalOne-Cookie: d2e58729a6e3c9dab429edc4ab4ba3d49caac42c X-HalOne-ID: a6746655-2999-11e6-a8e4-b8ca3afa9d73 Received: from smtp.dmfs.org (unknown [79.240.231.213]) by smtpfilter1.public.one.com (Halon Mail Gateway) with ESMTPSA for ; Fri, 3 Jun 2016 14:44:17 +0000 (UTC) Received: from localhost.localdomain (linux.fritz.box [192.168.2.53]) by smtp.dmfs.org (Postfix) with ESMTPSA id 64A1A354 for ; Fri, 3 Jun 2016 16:40:17 +0200 (CEST) Message-ID: <575197C1.3090102@dmfs.org> Date: Fri, 03 Jun 2016 16:44:17 +0200 From: Marten Gajda Organization: dmfs GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: webfinger@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000607080106030509070906" Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 14:44:26 -0000 This is a multi-part message in MIME format. --------------000607080106030509070906 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Note that the idea behind https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 is to put the service configuration for all services of a provider into a single document. So you would receive something like this: { "rel " : "service-configuration", "href " : "https://example.com/service-configuration" } If a user uses the same account identifier at another provider the Webfinger request could return their configuration too (given there is some mechanism to add it and the provider actually supports that). { "rel " : "service-configuration", "href " : "https://example.com/service-configuration" }, { "rel " : "service-configuration", "href " : "https://acme-calendar.com/service-configuration" } Without that it would be more difficult to setup your account at acme-calendar.com with your login "user@example.com". acme-calendar.com would have to issue some kind of user-identifier like user@acme-calendar.com for auto-configuration purposes, even though you don't use it for authentication (because you use user@exampe.com for authentication). I think that's the idea behind the `acct:` URI scheme, but I don't think that you can explain to users why they need another user identifier and when to use one or the other. But that also raises the privacy concerns I mentioned earlier. If the request is not authenticated, everyone could see that you have an account at acme-calendar.com. Regarding SSO: There is an RFC that extends SASL based authentication to support the token authentication mechanisms as used by OAuth1 and OAuth2, see https://tools.ietf.org/html/rfc7628 So SSO already works with IMAP, POP3 and SMTP. Cheers Marten Am 03.06.2016 um 15:40 schrieb Paul E. Jones: > Marten, >> So how would the UI work? >> >> 1) User enters user identifier, most likely an email address, like >> mailto:user@example.com and hits "next" >> >> 2) Client sends a Webfinger request to >> https://exampe.com/.well-known/webfinger?... to see if there is a >> configuration document >> >> -> response 404 Not Found >> a) Client falls back to "manual setup" or another >> auto-configuration mechanism >> >> -> response 401 Unauthorized > One should not get 401 querying the WebFinger information for the > user. What should happen is that the server should return a JSON > object that contains a link relation that might look like this: > { > "rel " : "mail-config", > "href " : > "https://mailserver.example.com/config?user=paulej%40packetizer.com" > } > Or something like that. The mail client should query that URI it is > that one that should result in a potential 401. The JSON format that > would come back here would need to be something we define. It could > be based on JRD, but would not have to be. > Otherwise, I think the flow looks right. >> >> b) Client asks for password at "example.com" and goes back to step >> 2 (this time with authentication) >> >> -> response 200 Ok >> c) client moves on to next step >> >> 3) (optional) Client presents found services to the user to let him >> select the services to set up >> >> 4) Client runs the setup handler for each selected service >> >> >> I think in general that could work but it raises two questions: >> >> 1) How to make sure the user really understands that he's >> authenticating at example.com in step 2b? If the user tries to >> configure calendar sync with "acme-calendar.com" where his login >> happens to be mailto:user@example.com he might not be prepared to >> being asked for his example.com password. Maybe I'm just paranoid or >> overcautious, but I think that it might easily happen that the users >> sends his acme-calendar.com password to example.com in that case >> (since Basic authentication is still the most common mechanism, the >> client basically sends the password in plain text). > Yeah, that's a valid concern. The only thing I can suggest is that > the Subject CN from the certificate is presented to the user. > Alternatively, there could be two passwords: one that is the > "configuration password" and one that is the email password. However, > I don't think two passwords will help us. If I want to hack somebody > and can gain access to their WF config, I can auto-config their email > client to point to my own IMAP server and just retrieve the password > that way. > So, I think we have to rely on the certificate presented to the mail > client and the user will have to know to trust it. The mail provider > can tell the user "when configuring email, ensure that the > configuration server is mailconfig.example.com and do not provide a > password if that is not the name of the configuration server indicated." > If the mail config information is not protected with a password, we > probably would want the customer to verify that the SMTP server > information is correct before the password is provided. These would > be the steps users would take if performing manual configuration, but > the software presents that information to the user without the user > having to enter it. >> >> 2) How does the client know which credentials to use to set up the >> individual services in step 4? Should the client ask the user for the >> credentials for each service or can it assume that some of them share >> the same credentials? Is that something an auto-configuration >> document can help with? > It would be nice if there is a config indicator that says "SMTP server > and IMAP server passwords are the same", so the client does not have > to ask. > If we use a "config password" then we could even have the server tell > the client the password for services, which would transparently allow > those to be different. Alternatively, the client will have to ask > each about each one. > For calendaring services, then yes: the client would have to ask the > user. It could ask if it's the same or different than the email > password or the config password. For some services, the > authentication mechanisms will be entirely different (like Google > Calendar). The mail client will just have to know how to access the > service. For that reason, I'm a little hesitant to suggest including > calendaring service config along with the email config data. We could > have each of those services listed in the users' WebFinger document. > For example, I might have this entry in my WF document: > { > "rel" : "calendar" > "href" : "urn:whatever:google" > } > Note I did not provide a URL. The reason is that this is an entirely > different service that has an entirely different access method. Maybe > the client can ask the user "is paulej@packetizer.com > our user ID for your Google calendar?" > In my case, I don't think it is. Certainly, it's not my gmail ID. > And, I would not want to advertise that to the world, necessarily. > Anyway, I think we should limit the scope of what we try to do to > things that are standard OR we define a generic URN that a client will > just have to know how to deal with. >> Ideally the server supports some kind of SSO mechanism like OpenID >> Connect, so you don't need to enter your password multiple times. But >> a working auto-configuration is really the precondition for this, >> because an OpenID Connect implementations needs a way to discover the >> OAuth2 scope tokens to request from the server and auto-configuration >> is really the way to do that, IMO. For this it would be helpful to >> have some mechanism to request a broader scope from the user (without >> allowing him to switch to a different account), but that's a >> different topic I guess. > I definitely like the idea of SSO. But, I struggle to see how we > would use this in practice with mail autoconfig since SMTP, IMAP, and > POP servers require a password, anyway. If we use that as a means to > have those passwords provided behind the scenes (as I indicated > above), that might be a good argument for using OpenID Connect. In > that way, the ISP can also ensure that passwords are REALLY complex > and unknown even to the user. Not a bad practice, in that we can view > those passwords as complex tokens. > Would that kind of use of OpenID Connect to retrieve the password be > workable? (I'll admit I don't have so much experience with OpenID > Connect. I implemented OpenID 2.0, but that's not ideal for what we'd > want to accomplish here. I don't have a good feel for how Connect > might make this better.) > Paul > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------000607080106030509070906 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Note that the idea behind https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 is to put the service configuration for all services of a provider into a single document.

So you would receive something like this:

{
    "rel " :  "service-configuration",
}

If a user uses the same account identifier at another provider the Webfinger request could return their configuration too (given there is some mechanism to add it and the provider actually supports that).

{
    "rel " :  "service-configuration",
},
{
    "rel " :  "service-configuration",
}

Without that it would be more difficult to setup your account at acme-calendar.com with your login "user@example.com". acme-calendar.com would have to issue some kind of user-identifier like user@acme-calendar.com for auto-configuration purposes, even though you don't use it for authentication (because you use user@exampe.com for authentication). I think that's the idea behind the `acct:` URI scheme, but I don't think that you can explain to users why they need another user identifier and when to use one or the other.
But that also raises the privacy concerns I mentioned earlier. If the request is not authenticated, everyone could see that you have an account at acme-calendar.com.

Regarding SSO: There is an RFC that extends SASL based authentication to support the token authentication mechanisms as used by OAuth1 and OAuth2, see https://tools.ietf.org/html/rfc7628
So SSO already works with IMAP, POP3 and SMTP.

Cheers

Marten



Am 03.06.2016 um 15:40 schrieb Paul E. Jones:
Marten,
 
 
So how would the UI work?

1) User enters user identifier, most likely an email address, like mailto:user@example.com and hits "next"

2) Client sends a Webfinger request to https://exampe.com/.well-known/webfinger?... to see if there is a configuration document

  -> response 404 Not Found
   a) Client falls back to "manual setup" or another auto-configuration mechanism

  -> response 401 Unauthorized
 
One should not get 401 querying the WebFinger information for the user.  What should happen is that the server should return a JSON object that contains a link relation that might look like this:
{
    "rel " :  "mail-config",
}
 
Or something like that.  The mail client should query that URI it is that one that should result in a potential 401.  The JSON format that would come back here would need to be something we define.  It could be based on JRD, but would not have to be.
 
Otherwise, I think the flow looks right.
 
 

   b) Client asks for password at "example.com" and goes back to step 2 (this time with authentication)

  -> response 200 Ok
   c) client moves on to next step

3) (optional) Client presents found services to the user to let him select the services to set up

4) Client runs the setup handler for each selected service


I think in general that could work but it raises two questions:

1) How to make sure the user really understands that he's authenticating at example.com in step 2b? If the user tries to configure calendar sync with "acme-calendar.com" where his login happens to be mailto:user@example.com he might not be prepared to being asked for his example.com password. Maybe I'm just paranoid or overcautious, but I think that it might easily happen that the users sends his acme-calendar.com password to example.com in that case (since Basic authentication is still the most common mechanism, the client basically sends the password in plain text).
 
Yeah, that's a valid concern.  The only thing I can suggest is that the Subject CN from the certificate is presented to the user.  Alternatively, there could be two passwords: one that is the "configuration password" and one that is the email password.  However, I don't think two passwords will help us.  If I want to hack somebody and can gain access to their WF config, I can auto-config their email client to point to my own IMAP server and just retrieve the password that way.
 
So, I think we have to rely on the certificate presented to the mail client and the user will have to know to trust it.  The mail provider can tell the user "when configuring email, ensure that the configuration server is mailconfig.example.com and do not provide a password if that is not the name of the configuration server indicated."
 
If the mail config information is not protected with a password, we probably would want the customer to verify that the SMTP server information is correct before the password is provided.  These would be the steps users would take if performing manual configuration, but the software presents that information to the user without the user having to enter it.
 
 

2) How does the client know which credentials to use to set up the individual services in step 4? Should the client ask the user for the credentials for each service or can it assume that some of them share the same credentials? Is that something an auto-configuration document can help with?
 
It would be nice if there is a config indicator that says "SMTP server and IMAP server passwords are the same", so the client does not have to ask.
 
If we use a "config password" then we could even have the server tell the client the password for services, which would transparently allow those to be different.  Alternatively, the client will have to ask each about each one.
 
For calendaring services, then yes: the client would have to ask the user.  It could ask if it's the same or different than the email password or the config password.  For some services, the authentication mechanisms will be entirely different (like Google Calendar).  The mail client will just have to know how to access the service.  For that reason, I'm a little hesitant to suggest including calendaring service config along with the email config data.  We could have each of those services listed in the users' WebFinger document.  For example, I might have this entry in my WF document:
{
    "rel" : "calendar"
    "href" : "urn:whatever:google"
}
 
Note I did not provide a URL.  The reason is that this is an entirely different service that has an entirely different access method.  Maybe the client can ask the user "is paulej@packetizer.com our user ID for your Google calendar?"  In my case, I don't think it is.  Certainly, it's not my gmail ID.  And, I would not want to advertise that to the world, necessarily.  Anyway, I think we should limit the scope of what we try to do to things that are standard OR we define a generic URN that a client will just have to know how to deal with.
 
 
Ideally the server supports some kind of SSO mechanism like OpenID Connect, so you don't need to enter your password multiple times. But a working auto-configuration is really the precondition for this, because an OpenID Connect implementations needs a way to discover the OAuth2 scope tokens to request from the server and auto-configuration is really the way to do that, IMO. For this it would be helpful to have some mechanism to request a broader scope from the user (without allowing him to switch to a different account), but that's a different topic I guess.
 
I definitely like the idea of SSO.  But, I struggle to see how we would use this in practice with mail autoconfig since SMTP, IMAP, and POP servers require a password, anyway.  If we use that as a means to have those passwords provided behind the scenes (as I indicated above), that might be a good argument for using OpenID Connect.  In that way, the ISP can also ensure that passwords are REALLY complex and unknown even to the user.  Not a bad practice, in that we can view those passwords as complex tokens.
 
Would that kind of use of OpenID Connect to retrieve the password be workable?  (I'll admit I don't have so much experience with OpenID Connect.  I implemented OpenID 2.0, but that's not ideal for what we'd want to accomplish here.  I don't have a good feel for how Connect might make this better.)
 
Paul
 


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



-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------------000607080106030509070906-- From nobody Fri Jun 3 11:13:54 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCF712D85C for ; Fri, 3 Jun 2016 11:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK-jQp5BjUsL for ; Fri, 3 Jun 2016 11:13:49 -0700 (PDT) Received: from omr-m018e.mx.aol.com (omr-m018e.mx.aol.com [204.29.186.17]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED7912D85D for ; Fri, 3 Jun 2016 11:13:49 -0700 (PDT) Received: from mtaout-aag01.mx.aol.com (mtaout-aag01.mx.aol.com [172.26.126.77]) by omr-m018e.mx.aol.com (Outbound Mail Relay) with ESMTP id B50E7380009F; Fri, 3 Jun 2016 14:13:48 -0400 (EDT) Received: from [10.172.97.37] (unknown [10.172.97.37]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aag01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 30FA938000090; Fri, 3 Jun 2016 14:13:48 -0400 (EDT) To: Marten Gajda , "webfinger@ietf.org" References: <575197C1.3090102@dmfs.org> From: George Fletcher Organization: AOL LLC Message-ID: <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> Date: Fri, 3 Jun 2016 14:13:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <575197C1.3090102@dmfs.org> Content-Type: multipart/alternative; boundary="------------CA1E0F0B90EEB1E064781E81" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1464977628; bh=q6PsLmSGHFpLzScq9YOwyDNzdhTZ7B3MTXdjYEphOC4=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=1NvaWLEx8KFvpUv8iiD+XrwoerGW21qNRj1MMdVtYa1rHg94AHPlw82RcUj7KDarC 1iuqA7pSnwse8gbMf6EcYnBLCw/8BuWU79ar9d0HQkljR9qq6kbiMYfyS2WkQHiuxb mJTTPDIMmgb2F9busB03WC2IA9O+CQ3DAwZNy1Uo= x-aol-sid: 3039ac1a7e4d5751c8dc09ca X-AOL-IP: 10.172.97.37 Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 18:13:53 -0000 This is a multi-part message in MIME format. --------------CA1E0F0B90EEB1E064781E81 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Did a quick scan of the draft document. Given that more and more systems are trying to remove the need for passwords, it seems like the final solution needs to support 2FA and biometric mechanisms for "HTTP authentication". I definitely would not want the webfinger instance releasing my config data without my "authentication". I suppose OAuth2 could be used to protect the webfinger APIs though there is a bit of a chicken-and-egg here:) I kind of like the suggestion around returning a 401 with data in the WWW-Authenticate header on where to get a token to use with the API. This would allow the client to start and OAuth2 flow with the Authorization Server specified and that would give the user a clear indication of what password/credentials are being requested. Once the client gets the token, it uses it with the webfinger call and now the service-configuration data is returned because the token is the authorization for the specified id. Thanks, George On 6/3/16 10:44 AM, Marten Gajda wrote: > Note that the idea behind > https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 > is to put the service configuration for all services of a provider > into a single document. > > So you would receive something like this: > > { > "rel " : "service-configuration", > "href " : "https://example.com/service-configuration" > } > > If a user uses the same account identifier at another provider the > Webfinger request could return their configuration too (given there is > some mechanism to add it and the provider actually supports that). > > { > "rel " : "service-configuration", > "href " : "https://example.com/service-configuration" > }, > { > "rel " : "service-configuration", > "href " : "https://acme-calendar.com/service-configuration" > } > > Without that it would be more difficult to setup your account at > acme-calendar.com with your login "user@example.com". > acme-calendar.com would have to issue some kind of user-identifier > like user@acme-calendar.com for auto-configuration purposes, even > though you don't use it for authentication (because you use > user@exampe.com for authentication). I think that's the idea behind > the `acct:` URI scheme, but I don't think that you can explain to > users why they need another user identifier and when to use one or the > other. > But that also raises the privacy concerns I mentioned earlier. If the > request is not authenticated, everyone could see that you have an > account at acme-calendar.com. > > Regarding SSO: There is an RFC that extends SASL based authentication > to support the token authentication mechanisms as used by OAuth1 and > OAuth2, see https://tools.ietf.org/html/rfc7628 > So SSO already works with IMAP, POP3 and SMTP. > > Cheers > > Marten > > > > Am 03.06.2016 um 15:40 schrieb Paul E. Jones: >> Marten, >>> So how would the UI work? >>> >>> 1) User enters user identifier, most likely an email address, like >>> mailto:user@example.com and hits "next" >>> >>> 2) Client sends a Webfinger request to >>> https://exampe.com/.well-known/webfinger?... to see if there is a >>> configuration document >>> >>> -> response 404 Not Found >>> a) Client falls back to "manual setup" or another >>> auto-configuration mechanism >>> >>> -> response 401 Unauthorized >> One should not get 401 querying the WebFinger information for the >> user. What should happen is that the server should return a JSON >> object that contains a link relation that might look like this: >> { >> "rel " : "mail-config", >> "href " : >> "https://mailserver.example.com/config?user=paulej%40packetizer.com" >> } >> Or something like that. The mail client should query that URI it is >> that one that should result in a potential 401. The JSON format that >> would come back here would need to be something we define. It could >> be based on JRD, but would not have to be. >> Otherwise, I think the flow looks right. >>> >>> b) Client asks for password at "example.com" and goes back to >>> step 2 (this time with authentication) >>> >>> -> response 200 Ok >>> c) client moves on to next step >>> >>> 3) (optional) Client presents found services to the user to let him >>> select the services to set up >>> >>> 4) Client runs the setup handler for each selected service >>> >>> >>> I think in general that could work but it raises two questions: >>> >>> 1) How to make sure the user really understands that he's >>> authenticating at example.com in step 2b? If the user tries to >>> configure calendar sync with "acme-calendar.com" where his login >>> happens to be mailto:user@example.com he might not be prepared to >>> being asked for his example.com password. Maybe I'm just paranoid or >>> overcautious, but I think that it might easily happen that the users >>> sends his acme-calendar.com password to example.com in that case >>> (since Basic authentication is still the most common mechanism, the >>> client basically sends the password in plain text). >> Yeah, that's a valid concern. The only thing I can suggest is that >> the Subject CN from the certificate is presented to the user. >> Alternatively, there could be two passwords: one that is the >> "configuration password" and one that is the email password. >> However, I don't think two passwords will help us. If I want to hack >> somebody and can gain access to their WF config, I can auto-config >> their email client to point to my own IMAP server and just retrieve >> the password that way. >> So, I think we have to rely on the certificate presented to the mail >> client and the user will have to know to trust it. The mail provider >> can tell the user "when configuring email, ensure that the >> configuration server is mailconfig.example.com and do not provide a >> password if that is not the name of the configuration server indicated." >> If the mail config information is not protected with a password, we >> probably would want the customer to verify that the SMTP server >> information is correct before the password is provided. These would >> be the steps users would take if performing manual configuration, but >> the software presents that information to the user without the user >> having to enter it. >>> >>> 2) How does the client know which credentials to use to set up the >>> individual services in step 4? Should the client ask the user for >>> the credentials for each service or can it assume that some of them >>> share the same credentials? Is that something an auto-configuration >>> document can help with? >> It would be nice if there is a config indicator that says "SMTP >> server and IMAP server passwords are the same", so the client does >> not have to ask. >> If we use a "config password" then we could even have the server tell >> the client the password for services, which would transparently allow >> those to be different. Alternatively, the client will have to ask >> each about each one. >> For calendaring services, then yes: the client would have to ask the >> user. It could ask if it's the same or different than the email >> password or the config password. For some services, the >> authentication mechanisms will be entirely different (like Google >> Calendar). The mail client will just have to know how to access the >> service. For that reason, I'm a little hesitant to suggest including >> calendaring service config along with the email config data. We >> could have each of those services listed in the users' WebFinger >> document. For example, I might have this entry in my WF document: >> { >> "rel" : "calendar" >> "href" : "urn:whatever:google" >> } >> Note I did not provide a URL. The reason is that this is an entirely >> different service that has an entirely different access method. >> Maybe the client can ask the user "is paulej@packetizer.com >> our user ID for your Google >> calendar?" In my case, I don't think it is. Certainly, it's not my >> gmail ID. And, I would not want to advertise that to the world, >> necessarily. Anyway, I think we should limit the scope of what we try >> to do to things that are standard OR we define a generic URN that a >> client will just have to know how to deal with. >>> Ideally the server supports some kind of SSO mechanism like OpenID >>> Connect, so you don't need to enter your password multiple times. >>> But a working auto-configuration is really the precondition for >>> this, because an OpenID Connect implementations needs a way to >>> discover the OAuth2 scope tokens to request from the server and >>> auto-configuration is really the way to do that, IMO. For this it >>> would be helpful to have some mechanism to request a broader scope >>> from the user (without allowing him to switch to a different >>> account), but that's a different topic I guess. >> I definitely like the idea of SSO. But, I struggle to see how we >> would use this in practice with mail autoconfig since SMTP, IMAP, and >> POP servers require a password, anyway. If we use that as a means to >> have those passwords provided behind the scenes (as I indicated >> above), that might be a good argument for using OpenID Connect. In >> that way, the ISP can also ensure that passwords are REALLY complex >> and unknown even to the user. Not a bad practice, in that we can >> view those passwords as complex tokens. >> Would that kind of use of OpenID Connect to retrieve the password be >> workable? (I'll admit I don't have so much experience with OpenID >> Connect. I implemented OpenID 2.0, but that's not ideal for what >> we'd want to accomplish here. I don't have a good feel for how >> Connect might make this better.) >> Paul >> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger > > > -- > Marten Gajda > CEO > > dmfs GmbH > Schandauer Straße 34 > 01309 Dresden > GERMANY > > phone: +49 177 4427167 > email:marten@dmfs.org > > Managing Director: Marten Gajda > Registered address: Dresden > Registered No.: AG Dresden HRB 34881 > VAT Reg. No.: DE303248743 > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --------------CA1E0F0B90EEB1E064781E81 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Did a quick scan of the draft document. Given that more and more systems are trying to remove the need for passwords, it seems like the final solution needs to support 2FA and biometric mechanisms for "HTTP authentication". I definitely would not want the webfinger instance releasing my config data without my "authentication". I suppose OAuth2 could be used to protect the webfinger APIs though there is a bit of a chicken-and-egg here:)

I kind of like the suggestion around returning a 401 with data in the WWW-Authenticate header on where to get a token to use with the API. This would allow the client to start and OAuth2 flow with the Authorization Server specified and that would give the user a clear indication of what password/credentials are being requested. Once the client gets the token, it uses it with the webfinger call and now the service-configuration data is returned because the token is the authorization for the specified id.

Thanks,
George

On 6/3/16 10:44 AM, Marten Gajda wrote:
Note that the idea behind https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 is to put the service configuration for all services of a provider into a single document.

So you would receive something like this:

{
    "rel " :  "service-configuration",
}

If a user uses the same account identifier at another provider the Webfinger request could return their configuration too (given there is some mechanism to add it and the provider actually supports that).

{
    "rel " :  "service-configuration",
},
{
    "rel " :  "service-configuration",
}

Without that it would be more difficult to setup your account at acme-calendar.com with your login "user@example.com". acme-calendar.com would have to issue some kind of user-identifier like user@acme-calendar.com for auto-configuration purposes, even though you don't use it for authentication (because you use user@exampe.com for authentication). I think that's the idea behind the `acct:` URI scheme, but I don't think that you can explain to users why they need another user identifier and when to use one or the other.
But that also raises the privacy concerns I mentioned earlier. If the request is not authenticated, everyone could see that you have an account at acme-calendar.com.

Regarding SSO: There is an RFC that extends SASL based authentication to support the token authentication mechanisms as used by OAuth1 and OAuth2, see https://tools.ietf.org/html/rfc7628
So SSO already works with IMAP, POP3 and SMTP.

Cheers

Marten



Am 03.06.2016 um 15:40 schrieb Paul E. Jones:
Marten,
 
 
So how would the UI work?

1) User enters user identifier, most likely an email address, like mailto:user@example.com and hits "next"

2) Client sends a Webfinger request to https://exampe.com/.well-known/webfinger?... to see if there is a configuration document

  -> response 404 Not Found
   a) Client falls back to "manual setup" or another auto-configuration mechanism

  -> response 401 Unauthorized
 
One should not get 401 querying the WebFinger information for the user.  What should happen is that the server should return a JSON object that contains a link relation that might look like this:
{
    "rel " :  "mail-config",
}
 
Or something like that.  The mail client should query that URI it is that one that should result in a potential 401.  The JSON format that would come back here would need to be something we define.  It could be based on JRD, but would not have to be.
 
Otherwise, I think the flow looks right.
 
 

   b) Client asks for password at "example.com" and goes back to step 2 (this time with authentication)

  -> response 200 Ok
   c) client moves on to next step

3) (optional) Client presents found services to the user to let him select the services to set up

4) Client runs the setup handler for each selected service


I think in general that could work but it raises two questions:

1) How to make sure the user really understands that he's authenticating at example.com in step 2b? If the user tries to configure calendar sync with "acme-calendar.com" where his login happens to be mailto:user@example.com he might not be prepared to being asked for his example.com password. Maybe I'm just paranoid or overcautious, but I think that it might easily happen that the users sends his acme-calendar.com password to example.com in that case (since Basic authentication is still the most common mechanism, the client basically sends the password in plain text).
 
Yeah, that's a valid concern.  The only thing I can suggest is that the Subject CN from the certificate is presented to the user.  Alternatively, there could be two passwords: one that is the "configuration password" and one that is the email password.  However, I don't think two passwords will help us.  If I want to hack somebody and can gain access to their WF config, I can auto-config their email client to point to my own IMAP server and just retrieve the password that way.
 
So, I think we have to rely on the certificate presented to the mail client and the user will have to know to trust it.  The mail provider can tell the user "when configuring email, ensure that the configuration server is mailconfig.example.com and do not provide a password if that is not the name of the configuration server indicated."
 
If the mail config information is not protected with a password, we probably would want the customer to verify that the SMTP server information is correct before the password is provided.  These would be the steps users would take if performing manual configuration, but the software presents that information to the user without the user having to enter it.
 
 

2) How does the client know which credentials to use to set up the individual services in step 4? Should the client ask the user for the credentials for each service or can it assume that some of them share the same credentials? Is that something an auto-configuration document can help with?
 
It would be nice if there is a config indicator that says "SMTP server and IMAP server passwords are the same", so the client does not have to ask.
 
If we use a "config password" then we could even have the server tell the client the password for services, which would transparently allow those to be different.  Alternatively, the client will have to ask each about each one.
 
For calendaring services, then yes: the client would have to ask the user.  It could ask if it's the same or different than the email password or the config password.  For some services, the authentication mechanisms will be entirely different (like Google Calendar).  The mail client will just have to know how to access the service.  For that reason, I'm a little hesitant to suggest including calendaring service config along with the email config data.  We could have each of those services listed in the users' WebFinger document.  For example, I might have this entry in my WF document:
{
    "rel" : "calendar"
    "href" : "urn:whatever:google"
}
 
Note I did not provide a URL.  The reason is that this is an entirely different service that has an entirely different access method.  Maybe the client can ask the user "is paulej@packetizer.com our user ID for your Google calendar?"  In my case, I don't think it is.  Certainly, it's not my gmail ID.  And, I would not want to advertise that to the world, necessarily.  Anyway, I think we should limit the scope of what we try to do to things that are standard OR we define a generic URN that a client will just have to know how to deal with.
 
 
Ideally the server supports some kind of SSO mechanism like OpenID Connect, so you don't need to enter your password multiple times. But a working auto-configuration is really the precondition for this, because an OpenID Connect implementations needs a way to discover the OAuth2 scope tokens to request from the server and auto-configuration is really the way to do that, IMO. For this it would be helpful to have some mechanism to request a broader scope from the user (without allowing him to switch to a different account), but that's a different topic I guess.
 
I definitely like the idea of SSO.  But, I struggle to see how we would use this in practice with mail autoconfig since SMTP, IMAP, and POP servers require a password, anyway.  If we use that as a means to have those passwords provided behind the scenes (as I indicated above), that might be a good argument for using OpenID Connect.  In that way, the ISP can also ensure that passwords are REALLY complex and unknown even to the user.  Not a bad practice, in that we can view those passwords as complex tokens.
 
Would that kind of use of OpenID Connect to retrieve the password be workable?  (I'll admit I don't have so much experience with OpenID Connect.  I implemented OpenID 2.0, but that's not ideal for what we'd want to accomplish here.  I don't have a good feel for how Connect might make this better.)
 
Paul
 


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



-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743


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

--------------CA1E0F0B90EEB1E064781E81-- From nobody Sun Jun 5 14:10:26 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C9E12D636 for ; Sun, 5 Jun 2016 14:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUZOszPW-EZS for ; Sun, 5 Jun 2016 14:10:22 -0700 (PDT) Received: from mailrelay6.public.one.com (mailrelay6.public.one.com [91.198.169.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C8912D0DB for ; Sun, 5 Jun 2016 14:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=b8mbUQ3FtNTFkxS1kiaG7xmJkpGKi3wy8pH2He5GFZE=; b=vGfwEU55d0p/f2k7zM9QJCOQUgw8IguGRZKHiUtnw3JO5cVUN0uB9WHj+Gl1u478Ukg3IWK8JKJxS w6lEeSa03mYtlxdvV4yyhm8EtFtRq7ktikYWhzRa/Eh8F7eMKx4JN22ydy6X36/Y4ziTNheEXt0oSf HR3tEUc/hdSUlo7U= X-HalOne-Cookie: a95a616c2c4cbf584c8bab3fb4205a35343a004c X-HalOne-ID: 828bf28f-2b60-11e6-9f37-b82a72d06996 Received: from smtp.dmfs.org (unknown [79.240.254.154]) by smtpfilter3.public.one.com (Halon Mail Gateway) with ESMTPSA; Sun, 5 Jun 2016 21:00:18 +0000 (UTC) Received: from localhost.localdomain (p5DDA907C.dip0.t-ipconnect.de [93.218.144.124]) by smtp.dmfs.org (Postfix) with ESMTPSA id 0AE4C218; Sun, 5 Jun 2016 22:56:07 +0200 (CEST) Message-ID: <575492E1.2000805@dmfs.org> Date: Sun, 05 Jun 2016 23:00:17 +0200 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: George Fletcher , webfinger@ietf.org References: <575197C1.3090102@dmfs.org> <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> In-Reply-To: <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> Content-Type: multipart/alternative; boundary="------------070004080904060909090803" Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 21:10:25 -0000 This is a multi-part message in MIME format. --------------070004080904060909090803 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I think OpenID Connect already covers the discovery of everything you need to do OAuth2. That involves Webfinger, but there is no need to protect this request, because it doesn't contain personal information. So we don't need to reinvent the OAuth2 bootstrapping sequence. The only minor issue I see is that you may have to ask the user twice to grant access. Once to authorize the client to access the configuration document and another time to authorize the client to access the individual services. The second step is necessary, because the scope tokens of these services are not known when the first authorization request is presented to the user. The problem with that is, there doesn't seem to be a mechanism to broaden scope, without allowing the user to switch to a different account. To get access to the individual services, the client needs to start another authorization code grant. But the user is always free to log out and log in with a different account before granting access. Marten Am 03.06.2016 um 20:13 schrieb George Fletcher: > Did a quick scan of the draft document. Given that more and more > systems are trying to remove the need for passwords, it seems like the > final solution needs to support 2FA and biometric mechanisms for "HTTP > authentication". I definitely would not want the webfinger instance > releasing my config data without my "authentication". I suppose OAuth2 > could be used to protect the webfinger APIs though there is a bit of a > chicken-and-egg here:) > > I kind of like the suggestion around returning a 401 with data in the > WWW-Authenticate header on where to get a token to use with the API. > This would allow the client to start and OAuth2 flow with the > Authorization Server specified and that would give the user a clear > indication of what password/credentials are being requested. Once the > client gets the token, it uses it with the webfinger call and now the > service-configuration data is returned because the token is the > authorization for the specified id. > > Thanks, > George > > On 6/3/16 10:44 AM, Marten Gajda wrote: >> Note that the idea behind >> https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 >> is to put the service configuration for all services of a provider >> into a single document. >> >> So you would receive something like this: >> >> { >> "rel " : "service-configuration", >> "href " : "https://example.com/service-configuration" >> } >> >> If a user uses the same account identifier at another provider the >> Webfinger request could return their configuration too (given there >> is some mechanism to add it and the provider actually supports that). >> >> { >> "rel " : "service-configuration", >> "href " : "https://example.com/service-configuration" >> }, >> { >> "rel " : "service-configuration", >> "href " : "https://acme-calendar.com/service-configuration" >> } >> >> Without that it would be more difficult to setup your account at >> acme-calendar.com with your login "user@example.com". >> acme-calendar.com would have to issue some kind of user-identifier >> like user@acme-calendar.com for auto-configuration purposes, even >> though you don't use it for authentication (because you use >> user@exampe.com for authentication). I think that's the idea behind >> the `acct:` URI scheme, but I don't think that you can explain to >> users why they need another user identifier and when to use one or >> the other. >> But that also raises the privacy concerns I mentioned earlier. If the >> request is not authenticated, everyone could see that you have an >> account at acme-calendar.com. >> >> Regarding SSO: There is an RFC that extends SASL based authentication >> to support the token authentication mechanisms as used by OAuth1 and >> OAuth2, see https://tools.ietf.org/html/rfc7628 >> So SSO already works with IMAP, POP3 and SMTP. >> >> Cheers >> >> Marten >> >> >> >> Am 03.06.2016 um 15:40 schrieb Paul E. Jones: >>> Marten, >>> >>> >>>> So how would the UI work? >>>> >>>> 1) User enters user identifier, most likely an email address, like >>>> mailto:user@example.com and hits "next" >>>> >>>> 2) Client sends a Webfinger request to >>>> https://exampe.com/.well-known/webfinger?... to see if there is a >>>> configuration document >>>> >>>> -> response 404 Not Found >>>> a) Client falls back to "manual setup" or another >>>> auto-configuration mechanism >>>> >>>> -> response 401 Unauthorized >>> >>> One should not get 401 querying the WebFinger information for the >>> user. What should happen is that the server should return a JSON >>> object that contains a link relation that might look like this: >>> { >>> "rel " : "mail-config", >>> "href " : >>> "https://mailserver.example.com/config?user=paulej%40packetizer.com" >>> } >>> >>> Or something like that. The mail client should query that URI it is >>> that one that should result in a potential 401. The JSON format >>> that would come back here would need to be something we define. It >>> could be based on JRD, but would not have to be. >>> >>> Otherwise, I think the flow looks right. >>> >>> >>>> >>>> b) Client asks for password at "example.com" and goes back to >>>> step 2 (this time with authentication) >>>> >>>> -> response 200 Ok >>>> c) client moves on to next step >>>> >>>> 3) (optional) Client presents found services to the user to let him >>>> select the services to set up >>>> >>>> 4) Client runs the setup handler for each selected service >>>> >>>> >>>> I think in general that could work but it raises two questions: >>>> >>>> 1) How to make sure the user really understands that he's >>>> authenticating at example.com in step 2b? If the user tries to >>>> configure calendar sync with "acme-calendar.com" where his login >>>> happens to be mailto:user@example.com he might not be prepared to >>>> being asked for his example.com password. Maybe I'm just paranoid >>>> or overcautious, but I think that it might easily happen that the >>>> users sends his acme-calendar.com password to example.com in that >>>> case (since Basic authentication is still the most common >>>> mechanism, the client basically sends the password in plain text). >>> >>> Yeah, that's a valid concern. The only thing I can suggest is that >>> the Subject CN from the certificate is presented to the user. >>> Alternatively, there could be two passwords: one that is the >>> "configuration password" and one that is the email password. >>> However, I don't think two passwords will help us. If I want to >>> hack somebody and can gain access to their WF config, I can >>> auto-config their email client to point to my own IMAP server and >>> just retrieve the password that way. >>> >>> So, I think we have to rely on the certificate presented to the mail >>> client and the user will have to know to trust it. The mail >>> provider can tell the user "when configuring email, ensure that the >>> configuration server is mailconfig.example.com and do not provide a >>> password if that is not the name of the configuration server indicated." >>> >>> If the mail config information is not protected with a password, we >>> probably would want the customer to verify that the SMTP server >>> information is correct before the password is provided. These would >>> be the steps users would take if performing manual configuration, >>> but the software presents that information to the user without the >>> user having to enter it. >>> >>> >>>> >>>> 2) How does the client know which credentials to use to set up the >>>> individual services in step 4? Should the client ask the user for >>>> the credentials for each service or can it assume that some of them >>>> share the same credentials? Is that something an auto-configuration >>>> document can help with? >>> >>> It would be nice if there is a config indicator that says "SMTP >>> server and IMAP server passwords are the same", so the client does >>> not have to ask. >>> >>> If we use a "config password" then we could even have the server >>> tell the client the password for services, which would transparently >>> allow those to be different. Alternatively, the client will have to >>> ask each about each one. >>> >>> For calendaring services, then yes: the client would have to ask the >>> user. It could ask if it's the same or different than the email >>> password or the config password. For some services, the >>> authentication mechanisms will be entirely different (like Google >>> Calendar). The mail client will just have to know how to access the >>> service. For that reason, I'm a little hesitant to suggest >>> including calendaring service config along with the email config >>> data. We could have each of those services listed in the users' >>> WebFinger document. For example, I might have this entry in my WF >>> document: >>> { >>> "rel" : "calendar" >>> "href" : "urn:whatever:google" >>> } >>> >>> Note I did not provide a URL. The reason is that this is an >>> entirely different service that has an entirely different access >>> method. Maybe the client can ask the user "is paulej@packetizer.com >>> our user ID for your Google calendar?" In my case, I don't think it >>> is. Certainly, it's not my gmail ID. And, I would not want to >>> advertise that to the world, necessarily. Anyway, I think we should >>> limit the scope of what we try to do to things that are standard OR >>> we define a generic URN that a client will just have to know how to >>> deal with. >>> >>> >>>> Ideally the server supports some kind of SSO mechanism like OpenID >>>> Connect, so you don't need to enter your password multiple times. >>>> But a working auto-configuration is really the precondition for >>>> this, because an OpenID Connect implementations needs a way to >>>> discover the OAuth2 scope tokens to request from the server and >>>> auto-configuration is really the way to do that, IMO. For this it >>>> would be helpful to have some mechanism to request a broader scope >>>> from the user (without allowing him to switch to a different >>>> account), but that's a different topic I guess. >>> >>> I definitely like the idea of SSO. But, I struggle to see how we >>> would use this in practice with mail autoconfig since SMTP, IMAP, >>> and POP servers require a password, anyway. If we use that as a >>> means to have those passwords provided behind the scenes (as I >>> indicated above), that might be a good argument for using OpenID >>> Connect. In that way, the ISP can also ensure that passwords are >>> REALLY complex and unknown even to the user. Not a bad practice, in >>> that we can view those passwords as complex tokens. >>> >>> Would that kind of use of OpenID Connect to retrieve the password be >>> workable? (I'll admit I don't have so much experience with OpenID >>> Connect. I implemented OpenID 2.0, but that's not ideal for what >>> we'd want to accomplish here. I don't have a good feel for how >>> Connect might make this better.) >>> >>> Paul >>> >>> >>> >>> _______________________________________________ >>> webfinger mailing list >>> webfinger@ietf.org >>> https://www.ietf.org/mailman/listinfo/webfinger >> >> >> -- >> Marten Gajda >> CEO >> >> dmfs GmbH >> Schandauer Straße 34 >> 01309 Dresden >> GERMANY >> >> phone: +49 177 4427167 >> email: marten@dmfs.org >> >> Managing Director: Marten Gajda >> Registered address: Dresden >> Registered No.: AG Dresden HRB 34881 >> VAT Reg. No.: DE303248743 >> >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger > -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------070004080904060909090803 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I think OpenID Connect already covers the discovery of everything you need to do OAuth2. That involves Webfinger, but there is no need to protect this request, because it doesn't contain personal information.
So we don't need to reinvent the OAuth2 bootstrapping sequence.
The only minor issue I see is that you may have to ask the user twice to grant access. Once to authorize the client to access the configuration document and another time to authorize the client to access the individual services. The second step is necessary, because the scope tokens of these services are not known when the first authorization request is presented to the user. The problem with that is, there doesn't seem to be a mechanism to broaden scope, without allowing the user to switch to a different account. To get access to the individual services, the client needs to start another authorization code grant. But the user is always free to log out and log in with a different account before granting access.

Marten

Am 03.06.2016 um 20:13 schrieb George Fletcher:
Did a quick scan of the draft document. Given that more and more systems are trying to remove the need for passwords, it seems like the final solution needs to support 2FA and biometric mechanisms for "HTTP authentication". I definitely would not want the webfinger instance releasing my config data without my "authentication". I suppose OAuth2 could be used to protect the webfinger APIs though there is a bit of a chicken-and-egg here:)

I kind of like the suggestion around returning a 401 with data in the WWW-Authenticate header on where to get a token to use with the API. This would allow the client to start and OAuth2 flow with the Authorization Server specified and that would give the user a clear indication of what password/credentials are being requested. Once the client gets the token, it uses it with the webfinger call and now the service-configuration data is returned because the token is the authorization for the specified id.

Thanks,
George

On 6/3/16 10:44 AM, Marten Gajda wrote:
Note that the idea behind https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 is to put the service configuration for all services of a provider into a single document.

So you would receive something like this:

{
    "rel " :  "service-configuration",
}

If a user uses the same account identifier at another provider the Webfinger request could return their configuration too (given there is some mechanism to add it and the provider actually supports that).

{
    "rel " :  "service-configuration",
},
{
    "rel " :  "service-configuration",
}

Without that it would be more difficult to setup your account at acme-calendar.com with your login "user@example.com". acme-calendar.com would have to issue some kind of user-identifier like user@acme-calendar.com for auto-configuration purposes, even though you don't use it for authentication (because you use user@exampe.com for authentication). I think that's the idea behind the `acct:` URI scheme, but I don't think that you can explain to users why they need another user identifier and when to use one or the other.
But that also raises the privacy concerns I mentioned earlier. If the request is not authenticated, everyone could see that you have an account at acme-calendar.com.

Regarding SSO: There is an RFC that extends SASL based authentication to support the token authentication mechanisms as used by OAuth1 and OAuth2, see https://tools.ietf.org/html/rfc7628
So SSO already works with IMAP, POP3 and SMTP.

Cheers

Marten



Am 03.06.2016 um 15:40 schrieb Paul E. Jones:
Marten,
 
 
So how would the UI work?

1) User enters user identifier, most likely an email address, like mailto:user@example.com and hits "next"

2) Client sends a Webfinger request to https://exampe.com/.well-known/webfinger?... to see if there is a configuration document

  -> response 404 Not Found
   a) Client falls back to "manual setup" or another auto-configuration mechanism

  -> response 401 Unauthorized
 
One should not get 401 querying the WebFinger information for the user.  What should happen is that the server should return a JSON object that contains a link relation that might look like this:
{
    "rel " :  "mail-config",
}
 
Or something like that.  The mail client should query that URI it is that one that should result in a potential 401.  The JSON format that would come back here would need to be something we define.  It could be based on JRD, but would not have to be.
 
Otherwise, I think the flow looks right.
 
 

   b) Client asks for password at "example.com" and goes back to step 2 (this time with authentication)

  -> response 200 Ok
   c) client moves on to next step

3) (optional) Client presents found services to the user to let him select the services to set up

4) Client runs the setup handler for each selected service


I think in general that could work but it raises two questions:

1) How to make sure the user really understands that he's authenticating at example.com in step 2b? If the user tries to configure calendar sync with "acme-calendar.com" where his login happens to be mailto:user@example.com he might not be prepared to being asked for his example.com password. Maybe I'm just paranoid or overcautious, but I think that it might easily happen that the users sends his acme-calendar.com password to example.com in that case (since Basic authentication is still the most common mechanism, the client basically sends the password in plain text).
 
Yeah, that's a valid concern.  The only thing I can suggest is that the Subject CN from the certificate is presented to the user.  Alternatively, there could be two passwords: one that is the "configuration password" and one that is the email password.  However, I don't think two passwords will help us.  If I want to hack somebody and can gain access to their WF config, I can auto-config their email client to point to my own IMAP server and just retrieve the password that way.
 
So, I think we have to rely on the certificate presented to the mail client and the user will have to know to trust it.  The mail provider can tell the user "when configuring email, ensure that the configuration server is mailconfig.example.com and do not provide a password if that is not the name of the configuration server indicated."
 
If the mail config information is not protected with a password, we probably would want the customer to verify that the SMTP server information is correct before the password is provided.  These would be the steps users would take if performing manual configuration, but the software presents that information to the user without the user having to enter it.
 
 

2) How does the client know which credentials to use to set up the individual services in step 4? Should the client ask the user for the credentials for each service or can it assume that some of them share the same credentials? Is that something an auto-configuration document can help with?
 
It would be nice if there is a config indicator that says "SMTP server and IMAP server passwords are the same", so the client does not have to ask.
 
If we use a "config password" then we could even have the server tell the client the password for services, which would transparently allow those to be different.  Alternatively, the client will have to ask each about each one.
 
For calendaring services, then yes: the client would have to ask the user.  It could ask if it's the same or different than the email password or the config password.  For some services, the authentication mechanisms will be entirely different (like Google Calendar).  The mail client will just have to know how to access the service.  For that reason, I'm a little hesitant to suggest including calendaring service config along with the email config data.  We could have each of those services listed in the users' WebFinger document.  For example, I might have this entry in my WF document:
{
    "rel" : "calendar"
    "href" : "urn:whatever:google"
}
 
Note I did not provide a URL.  The reason is that this is an entirely different service that has an entirely different access method.  Maybe the client can ask the user "is paulej@packetizer.com our user ID for your Google calendar?"  In my case, I don't think it is.  Certainly, it's not my gmail ID.  And, I would not want to advertise that to the world, necessarily.  Anyway, I think we should limit the scope of what we try to do to things that are standard OR we define a generic URN that a client will just have to know how to deal with.
 
 
Ideally the server supports some kind of SSO mechanism like OpenID Connect, so you don't need to enter your password multiple times. But a working auto-configuration is really the precondition for this, because an OpenID Connect implementations needs a way to discover the OAuth2 scope tokens to request from the server and auto-configuration is really the way to do that, IMO. For this it would be helpful to have some mechanism to request a broader scope from the user (without allowing him to switch to a different account), but that's a different topic I guess.
 
I definitely like the idea of SSO.  But, I struggle to see how we would use this in practice with mail autoconfig since SMTP, IMAP, and POP servers require a password, anyway.  If we use that as a means to have those passwords provided behind the scenes (as I indicated above), that might be a good argument for using OpenID Connect.  In that way, the ISP can also ensure that passwords are REALLY complex and unknown even to the user.  Not a bad practice, in that we can view those passwords as complex tokens.
 
Would that kind of use of OpenID Connect to retrieve the password be workable?  (I'll admit I don't have so much experience with OpenID Connect.  I implemented OpenID 2.0, but that's not ideal for what we'd want to accomplish here.  I don't have a good feel for how Connect might make this better.)
 
Paul
 


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



-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743


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



-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------------070004080904060909090803-- From nobody Wed Jun 8 12:35:21 2016 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4CA12D73B for ; Wed, 8 Jun 2016 12:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 179ggxwsSauU for ; Wed, 8 Jun 2016 12:35:16 -0700 (PDT) Received: from mailrelay7.public.one.com (mailrelay7.public.one.com [91.198.169.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78E5F12D79C for ; Wed, 8 Jun 2016 12:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=qyLBGKBqho8MR9X3CLrhCY/Nu8ZKVi14ZSXyZ8xCNO4=; b=JuQbPxVeXF81rh96uyIkC+bMgE3e5KmcceuxQpmtUnfhhyVJWvyBUd6dF5kzeTfO+h5iwMh1VD0fF LMpehu+B8DJvesVqh7vbuPlr3WmO2Jbzjt4Z52EDfcmgmJcdGkd01kojvU36F5Sf+KnF7IYEFE4i3m MmZ6RHTQYelAB92w= X-HalOne-Cookie: 835a0043f271a4e1170ef8ef287d3768c070bc3a X-HalOne-ID: 1aff6b81-2db0-11e6-a0c6-b82a72cffc46 Received: from smtp.dmfs.org (unknown [217.234.102.98]) by smtpfilter4.public.one.com (Halon Mail Gateway) with ESMTPSA for ; Wed, 8 Jun 2016 19:35:07 +0000 (UTC) Received: from localhost.localdomain (p5DDA907C.dip0.t-ipconnect.de [93.218.144.124]) by smtp.dmfs.org (Postfix) with ESMTPSA id 3AAB42FB for ; Wed, 8 Jun 2016 21:30:41 +0200 (CEST) Message-ID: <57587369.20405@dmfs.org> Date: Wed, 08 Jun 2016 21:35:05 +0200 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: webfinger@ietf.org References: <575197C1.3090102@dmfs.org> <39fe811e-282a-2a08-2928-c78c3947a6b9@aol.com> <575492E1.2000805@dmfs.org> In-Reply-To: <575492E1.2000805@dmfs.org> Content-Type: multipart/alternative; boundary="------------060503040007080101090807" Archived-At: Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 19:35:20 -0000 This is a multi-part message in MIME format. --------------060503040007080101090807 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit All, I've created a GitHub repository to track open issues with the current draft, see https://github.com/CalConnect/AUTODISCOVERY/issues You're welcome to contribute to the discussion, either by creating a new issue or by commenting on an existing one. Thanks, Marten Am 05.06.2016 um 23:00 schrieb Marten Gajda: > I think OpenID Connect already covers the discovery of everything you > need to do OAuth2. That involves Webfinger, but there is no need to > protect this request, because it doesn't contain personal information. > So we don't need to reinvent the OAuth2 bootstrapping sequence. > The only minor issue I see is that you may have to ask the user twice > to grant access. Once to authorize the client to access the > configuration document and another time to authorize the client to > access the individual services. The second step is necessary, because > the scope tokens of these services are not known when the first > authorization request is presented to the user. The problem with that > is, there doesn't seem to be a mechanism to broaden scope, without > allowing the user to switch to a different account. To get access to > the individual services, the client needs to start another > authorization code grant. But the user is always free to log out and > log in with a different account before granting access. > > Marten > > Am 03.06.2016 um 20:13 schrieb George Fletcher: >> Did a quick scan of the draft document. Given that more and more >> systems are trying to remove the need for passwords, it seems like >> the final solution needs to support 2FA and biometric mechanisms for >> "HTTP authentication". I definitely would not want the webfinger >> instance releasing my config data without my "authentication". I >> suppose OAuth2 could be used to protect the webfinger APIs though >> there is a bit of a chicken-and-egg here:) >> >> I kind of like the suggestion around returning a 401 with data in the >> WWW-Authenticate header on where to get a token to use with the API. >> This would allow the client to start and OAuth2 flow with the >> Authorization Server specified and that would give the user a clear >> indication of what password/credentials are being requested. Once the >> client gets the token, it uses it with the webfinger call and now the >> service-configuration data is returned because the token is the >> authorization for the specified id. >> >> Thanks, >> George >> >> On 6/3/16 10:44 AM, Marten Gajda wrote: >>> Note that the idea behind >>> https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 >>> is to put the service configuration for all services of a provider >>> into a single document. >>> >>> So you would receive something like this: >>> >>> { >>> "rel " : "service-configuration", >>> "href " : "https://example.com/service-configuration" >>> } >>> >>> If a user uses the same account identifier at another provider the >>> Webfinger request could return their configuration too (given there >>> is some mechanism to add it and the provider actually supports that). >>> >>> { >>> "rel " : "service-configuration", >>> "href " : "https://example.com/service-configuration" >>> }, >>> { >>> "rel " : "service-configuration", >>> "href " : "https://acme-calendar.com/service-configuration" >>> } >>> >>> Without that it would be more difficult to setup your account at >>> acme-calendar.com with your login "user@example.com". >>> acme-calendar.com would have to issue some kind of user-identifier >>> like user@acme-calendar.com for auto-configuration purposes, even >>> though you don't use it for authentication (because you use >>> user@exampe.com for authentication). I think that's the idea behind >>> the `acct:` URI scheme, but I don't think that you can explain to >>> users why they need another user identifier and when to use one or >>> the other. >>> But that also raises the privacy concerns I mentioned earlier. If >>> the request is not authenticated, everyone could see that you have >>> an account at acme-calendar.com. >>> >>> Regarding SSO: There is an RFC that extends SASL based >>> authentication to support the token authentication mechanisms as >>> used by OAuth1 and OAuth2, see https://tools.ietf.org/html/rfc7628 >>> So SSO already works with IMAP, POP3 and SMTP. >>> >>> Cheers >>> >>> Marten >>> >>> >>> >>> Am 03.06.2016 um 15:40 schrieb Paul E. Jones: >>>> Marten, >>>> >>>> >>>>> So how would the UI work? >>>>> >>>>> 1) User enters user identifier, most likely an email address, like >>>>> mailto:user@example.com and hits "next" >>>>> >>>>> 2) Client sends a Webfinger request to >>>>> https://exampe.com/.well-known/webfinger?... to see if there is a >>>>> configuration document >>>>> >>>>> -> response 404 Not Found >>>>> a) Client falls back to "manual setup" or another >>>>> auto-configuration mechanism >>>>> >>>>> -> response 401 Unauthorized >>>> >>>> One should not get 401 querying the WebFinger information for the >>>> user. What should happen is that the server should return a JSON >>>> object that contains a link relation that might look like this: >>>> { >>>> "rel " : "mail-config", >>>> "href " : >>>> "https://mailserver.example.com/config?user=paulej%40packetizer.com" >>>> } >>>> >>>> Or something like that. The mail client should query that URI it >>>> is that one that should result in a potential 401. The JSON format >>>> that would come back here would need to be something we define. It >>>> could be based on JRD, but would not have to be. >>>> >>>> Otherwise, I think the flow looks right. >>>> >>>> >>>>> >>>>> b) Client asks for password at "example.com" and goes back to >>>>> step 2 (this time with authentication) >>>>> >>>>> -> response 200 Ok >>>>> c) client moves on to next step >>>>> >>>>> 3) (optional) Client presents found services to the user to let >>>>> him select the services to set up >>>>> >>>>> 4) Client runs the setup handler for each selected service >>>>> >>>>> >>>>> I think in general that could work but it raises two questions: >>>>> >>>>> 1) How to make sure the user really understands that he's >>>>> authenticating at example.com in step 2b? If the user tries to >>>>> configure calendar sync with "acme-calendar.com" where his login >>>>> happens to be mailto:user@example.com he might not be prepared to >>>>> being asked for his example.com password. Maybe I'm just paranoid >>>>> or overcautious, but I think that it might easily happen that the >>>>> users sends his acme-calendar.com password to example.com in that >>>>> case (since Basic authentication is still the most common >>>>> mechanism, the client basically sends the password in plain text). >>>> >>>> Yeah, that's a valid concern. The only thing I can suggest is that >>>> the Subject CN from the certificate is presented to the user. >>>> Alternatively, there could be two passwords: one that is the >>>> "configuration password" and one that is the email password. >>>> However, I don't think two passwords will help us. If I want to >>>> hack somebody and can gain access to their WF config, I can >>>> auto-config their email client to point to my own IMAP server and >>>> just retrieve the password that way. >>>> >>>> So, I think we have to rely on the certificate presented to the >>>> mail client and the user will have to know to trust it. The mail >>>> provider can tell the user "when configuring email, ensure that the >>>> configuration server is mailconfig.example.com and do not provide a >>>> password if that is not the name of the configuration server >>>> indicated." >>>> >>>> If the mail config information is not protected with a password, we >>>> probably would want the customer to verify that the SMTP server >>>> information is correct before the password is provided. These >>>> would be the steps users would take if performing manual >>>> configuration, but the software presents that information to the >>>> user without the user having to enter it. >>>> >>>> >>>>> >>>>> 2) How does the client know which credentials to use to set up the >>>>> individual services in step 4? Should the client ask the user for >>>>> the credentials for each service or can it assume that some of >>>>> them share the same credentials? Is that something an >>>>> auto-configuration document can help with? >>>> >>>> It would be nice if there is a config indicator that says "SMTP >>>> server and IMAP server passwords are the same", so the client does >>>> not have to ask. >>>> >>>> If we use a "config password" then we could even have the server >>>> tell the client the password for services, which would >>>> transparently allow those to be different. Alternatively, the >>>> client will have to ask each about each one. >>>> >>>> For calendaring services, then yes: the client would have to ask >>>> the user. It could ask if it's the same or different than the >>>> email password or the config password. For some services, the >>>> authentication mechanisms will be entirely different (like Google >>>> Calendar). The mail client will just have to know how to access >>>> the service. For that reason, I'm a little hesitant to suggest >>>> including calendaring service config along with the email config >>>> data. We could have each of those services listed in the users' >>>> WebFinger document. For example, I might have this entry in my WF >>>> document: >>>> { >>>> "rel" : "calendar" >>>> "href" : "urn:whatever:google" >>>> } >>>> >>>> Note I did not provide a URL. The reason is that this is an >>>> entirely different service that has an entirely different access >>>> method. Maybe the client can ask the user "is >>>> paulej@packetizer.com our user ID for your Google calendar?" In my >>>> case, I don't think it is. Certainly, it's not my gmail ID. And, >>>> I would not want to advertise that to the world, necessarily. >>>> Anyway, I think we should limit the scope of what we try to do to >>>> things that are standard OR we define a generic URN that a client >>>> will just have to know how to deal with. >>>> >>>> >>>>> Ideally the server supports some kind of SSO mechanism like OpenID >>>>> Connect, so you don't need to enter your password multiple times. >>>>> But a working auto-configuration is really the precondition for >>>>> this, because an OpenID Connect implementations needs a way to >>>>> discover the OAuth2 scope tokens to request from the server and >>>>> auto-configuration is really the way to do that, IMO. For this it >>>>> would be helpful to have some mechanism to request a broader scope >>>>> from the user (without allowing him to switch to a different >>>>> account), but that's a different topic I guess. >>>> >>>> I definitely like the idea of SSO. But, I struggle to see how we >>>> would use this in practice with mail autoconfig since SMTP, IMAP, >>>> and POP servers require a password, anyway. If we use that as a >>>> means to have those passwords provided behind the scenes (as I >>>> indicated above), that might be a good argument for using OpenID >>>> Connect. In that way, the ISP can also ensure that passwords are >>>> REALLY complex and unknown even to the user. Not a bad practice, >>>> in that we can view those passwords as complex tokens. >>>> >>>> Would that kind of use of OpenID Connect to retrieve the password >>>> be workable? (I'll admit I don't have so much experience with >>>> OpenID Connect. I implemented OpenID 2.0, but that's not ideal for >>>> what we'd want to accomplish here. I don't have a good feel for >>>> how Connect might make this better.) >>>> >>>> Paul >>>> >>>> >>>> >>>> _______________________________________________ >>>> webfinger mailing list >>>> webfinger@ietf.org >>>> https://www.ietf.org/mailman/listinfo/webfinger >>> >>> >>> -- >>> Marten Gajda >>> CEO >>> >>> dmfs GmbH >>> Schandauer Straße 34 >>> 01309 Dresden >>> GERMANY >>> >>> phone: +49 177 4427167 >>> email: marten@dmfs.org >>> >>> Managing Director: Marten Gajda >>> Registered address: Dresden >>> Registered No.: AG Dresden HRB 34881 >>> VAT Reg. No.: DE303248743 >>> >>> >>> _______________________________________________ >>> webfinger mailing list >>> webfinger@ietf.org >>> https://www.ietf.org/mailman/listinfo/webfinger >> > > -- > Marten Gajda > CEO > > dmfs GmbH > Schandauer Straße 34 > 01309 Dresden > GERMANY > > phone: +49 177 4427167 > email: marten@dmfs.org > > Managing Director: Marten Gajda > Registered address: Dresden > Registered No.: AG Dresden HRB 34881 > VAT Reg. No.: DE303248743 > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------060503040007080101090807 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit All,

I've created a GitHub repository to track open issues with the current draft, see https://github.com/CalConnect/AUTODISCOVERY/issues
You're welcome to contribute to the discussion, either by creating a new issue or by commenting on an existing one.

Thanks,

Marten

Am 05.06.2016 um 23:00 schrieb Marten Gajda:
I think OpenID Connect already covers the discovery of everything you need to do OAuth2. That involves Webfinger, but there is no need to protect this request, because it doesn't contain personal information.
So we don't need to reinvent the OAuth2 bootstrapping sequence.
The only minor issue I see is that you may have to ask the user twice to grant access. Once to authorize the client to access the configuration document and another time to authorize the client to access the individual services. The second step is necessary, because the scope tokens of these services are not known when the first authorization request is presented to the user. The problem with that is, there doesn't seem to be a mechanism to broaden scope, without allowing the user to switch to a different account. To get access to the individual services, the client needs to start another authorization code grant. But the user is always free to log out and log in with a different account before granting access.

Marten

Am 03.06.2016 um 20:13 schrieb George Fletcher:
Did a quick scan of the draft document. Given that more and more systems are trying to remove the need for passwords, it seems like the final solution needs to support 2FA and biometric mechanisms for "HTTP authentication". I definitely would not want the webfinger instance releasing my config data without my "authentication". I suppose OAuth2 could be used to protect the webfinger APIs though there is a bit of a chicken-and-egg here:)

I kind of like the suggestion around returning a 401 with data in the WWW-Authenticate header on where to get a token to use with the API. This would allow the client to start and OAuth2 flow with the Authorization Server specified and that would give the user a clear indication of what password/credentials are being requested. Once the client gets the token, it uses it with the webfinger call and now the service-configuration data is returned because the token is the authorization for the specified id.

Thanks,
George

On 6/3/16 10:44 AM, Marten Gajda wrote:
Note that the idea behind https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 is to put the service configuration for all services of a provider into a single document.

So you would receive something like this:

{
    "rel " :  "service-configuration",
}

If a user uses the same account identifier at another provider the Webfinger request could return their configuration too (given there is some mechanism to add it and the provider actually supports that).

{
    "rel " :  "service-configuration",
},
{
    "rel " :  "service-configuration",
}

Without that it would be more difficult to setup your account at acme-calendar.com with your login "user@example.com". acme-calendar.com would have to issue some kind of user-identifier like user@acme-calendar.com for auto-configuration purposes, even though you don't use it for authentication (because you use user@exampe.com for authentication). I think that's the idea behind the `acct:` URI scheme, but I don't think that you can explain to users why they need another user identifier and when to use one or the other.
But that also raises the privacy concerns I mentioned earlier. If the request is not authenticated, everyone could see that you have an account at acme-calendar.com.

Regarding SSO: There is an RFC that extends SASL based authentication to support the token authentication mechanisms as used by OAuth1 and OAuth2, see https://tools.ietf.org/html/rfc7628
So SSO already works with IMAP, POP3 and SMTP.

Cheers

Marten



Am 03.06.2016 um 15:40 schrieb Paul E. Jones:
Marten,
 
 
So how would the UI work?

1) User enters user identifier, most likely an email address, like mailto:user@example.com and hits "next"

2) Client sends a Webfinger request to https://exampe.com/.well-known/webfinger?... to see if there is a configuration document

  -> response 404 Not Found
   a) Client falls back to "manual setup" or another auto-configuration mechanism

  -> response 401 Unauthorized
 
One should not get 401 querying the WebFinger information for the user.  What should happen is that the server should return a JSON object that contains a link relation that might look like this:
{
    "rel " :  "mail-config",
}
 
Or something like that.  The mail client should query that URI it is that one that should result in a potential 401.  The JSON format that would come back here would need to be something we define.  It could be based on JRD, but would not have to be.
 
Otherwise, I think the flow looks right.
 
 

   b) Client asks for password at "example.com" and goes back to step 2 (this time with authentication)

  -> response 200 Ok
   c) client moves on to next step

3) (optional) Client presents found services to the user to let him select the services to set up

4) Client runs the setup handler for each selected service


I think in general that could work but it raises two questions:

1) How to make sure the user really understands that he's authenticating at example.com in step 2b? If the user tries to configure calendar sync with "acme-calendar.com" where his login happens to be mailto:user@example.com he might not be prepared to being asked for his example.com password. Maybe I'm just paranoid or overcautious, but I think that it might easily happen that the users sends his acme-calendar.com password to example.com in that case (since Basic authentication is still the most common mechanism, the client basically sends the password in plain text).
 
Yeah, that's a valid concern.  The only thing I can suggest is that the Subject CN from the certificate is presented to the user.  Alternatively, there could be two passwords: one that is the "configuration password" and one that is the email password.  However, I don't think two passwords will help us.  If I want to hack somebody and can gain access to their WF config, I can auto-config their email client to point to my own IMAP server and just retrieve the password that way.
 
So, I think we have to rely on the certificate presented to the mail client and the user will have to know to trust it.  The mail provider can tell the user "when configuring email, ensure that the configuration server is mailconfig.example.com and do not provide a password if that is not the name of the configuration server indicated."
 
If the mail config information is not protected with a password, we probably would want the customer to verify that the SMTP server information is correct before the password is provided.  These would be the steps users would take if performing manual configuration, but the software presents that information to the user without the user having to enter it.
 
 

2) How does the client know which credentials to use to set up the individual services in step 4? Should the client ask the user for the credentials for each service or can it assume that some of them share the same credentials? Is that something an auto-configuration document can help with?
 
It would be nice if there is a config indicator that says "SMTP server and IMAP server passwords are the same", so the client does not have to ask.
 
If we use a "config password" then we could even have the server tell the client the password for services, which would transparently allow those to be different.  Alternatively, the client will have to ask each about each one.
 
For calendaring services, then yes: the client would have to ask the user.  It could ask if it's the same or different than the email password or the config password.  For some services, the authentication mechanisms will be entirely different (like Google Calendar).  The mail client will just have to know how to access the service.  For that reason, I'm a little hesitant to suggest including calendaring service config along with the email config data.  We could have each of those services listed in the users' WebFinger document.  For example, I might have this entry in my WF document:
{
    "rel" : "calendar"
    "href" : "urn:whatever:google"
}
 
Note I did not provide a URL.  The reason is that this is an entirely different service that has an entirely different access method.  Maybe the client can ask the user "is paulej@packetizer.com our user ID for your Google calendar?"  In my case, I don't think it is.  Certainly, it's not my gmail ID.  And, I would not want to advertise that to the world, necessarily.  Anyway, I think we should limit the scope of what we try to do to things that are standard OR we define a generic URN that a client will just have to know how to deal with.
 
 
Ideally the server supports some kind of SSO mechanism like OpenID Connect, so you don't need to enter your password multiple times. But a working auto-configuration is really the precondition for this, because an OpenID Connect implementations needs a way to discover the OAuth2 scope tokens to request from the server and auto-configuration is really the way to do that, IMO. For this it would be helpful to have some mechanism to request a broader scope from the user (without allowing him to switch to a different account), but that's a different topic I guess.
 
I definitely like the idea of SSO.  But, I struggle to see how we would use this in practice with mail autoconfig since SMTP, IMAP, and POP servers require a password, anyway.  If we use that as a means to have those passwords provided behind the scenes (as I indicated above), that might be a good argument for using OpenID Connect.  In that way, the ISP can also ensure that passwords are REALLY complex and unknown even to the user.  Not a bad practice, in that we can view those passwords as complex tokens.
 
Would that kind of use of OpenID Connect to retrieve the password be workable?  (I'll admit I don't have so much experience with OpenID Connect.  I implemented OpenID 2.0, but that's not ideal for what we'd want to accomplish here.  I don't have a good feel for how Connect might make this better.)
 
Paul
 


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



-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743


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



-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743


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


-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------------060503040007080101090807--