From nobody Mon Mar 3 05:04:50 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E661A1A0011 for ; Mon, 3 Mar 2014 05:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNxfQoG_v-7q for ; Mon, 3 Mar 2014 05:04:47 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 6425F1A0005 for ; Mon, 3 Mar 2014 05:04:47 -0800 (PST) Received: from latte.josefsson.org (46.182.205.36.c.fiberdirekt.net [46.182.205.36]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s23D4f6Z001711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 3 Mar 2014 14:04:42 +0100 X-Hashcash: 1:22:140303:kitten@ietf.org::ojDXM/QttDtmw/rW:FtyV From: Simon Josefsson To: kitten@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Mon, 03 Mar 2014 14:04:36 +0100 Message-ID: <87ob1n5t7f.fsf@latte.josefsson.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/kXB9g7xZJs9N7_BQ7byXFToYc0Y Subject: [kitten] RFC5801bis: relaxing GS2 requirements X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 13:04:50 -0000 All, I've prepared a new version of RFC 5801 to get the GS2bis ball rolling. http://tools.ietf.org/html/draft-josefsson-kitten-gs2bis-00 So what's the reason for doing that? The problem is that RFC 6595 (SAML), RFC 6616 (OpenID) and the OAuth SASL mechanism does not really meet the GS2 requirements: in particular, they don't offer channel bindings or mutual authentication. Or more generically stated, the problem was that we hoped that all future authentication mechanisms would provide channel binding and mutual authentication, and as a result GS2 was too narrowly defined. This problem came up when RFC 6595 and RFC 6616 was prepared, and as a resolution those documents contained text on how to resolve the issue -- see the paragraph that starts with "The mutual..." in . But the problem is really with GS2, so the fix should go into GS2. To review the differences between RFC 5801 and GS2bis, I've published a HTML side-by-side diff: http://josefsson.org/sasl-gs2/draft-josefsson-kitten-gs2bis-from-rfc5801.diff.html As you can see, I've only added one section describing the problem and some new MUST wording. Clearly, this is not sufficient, and other sections must be modified, in particular the security considerations. Before doing that, I think it would be good to get the WG to think about this issue and see that the overall idea is acceptable. I can't say that I like the text, but I think it is a compromise that will result in better hormonization of GSS-API and SASL, and I have struggled to come up with anything better. For simpler commenting on the actual new material, I'm including the new section below. Feedback, suggestions, co-authors, etc, all very appreciated. Thanks, /Simon 6. When the mechanism does not support channel binding and/or mutual authentication Some authentication mechanisms does not offer mutual authentication or is unable to provide channel bindings. This is unfortunate, and usually suggests that the authentication mechanism offers limited authentication functionality. However there are situations when the lack of this functionality can be mitigated with other protection mechanisms, leading to acceptable overall security. Being able to define and use an authentication mechanism as a GSS-API mechanism and then use that GSS-API mechanism in the SASL environment using GS2 has advantages; for example, being able to re-use existing generic GS2 implementations. Further, being able to express all mechanisms that can be expressed as a GSS-API mechanisms as a SASL mechanism (and vice versa) provides design elegance and framework replacability. Therefor, this document relaxes the requirement that the GSS-API mechanism support channel bindings and/or mutual authentication. Implementing and deploying applications that supports those mechanism require some consideration, and this section discuss the relevant areas. For the discussion it helps to understand what happens with the GS2 bridge when a GSS-API mechanism does not offer channel bindings or mutual authentication. When channel bindings is not supported by the underlying mechanism, GS2 cannot protect its data (essentially: the channel binding flag and the SASL authorization identity). This means that the security of the channel binding mode breaks down and that the other side cannot trust the SASL authorization identity. When mutual authentication is not happening, the client cannot know that it sends its data to the intended server. It is acceptable to use these mechanisms with GS2 in some situations. For example, if the client uses TLS against a server, and the client verify the server's certificate properly so that server authentication has occured, then authenticating the client to the server using a "weak" GSS-API mechanism will technically work. The security properties will not be as good as they would have been if the underlying mechanism supported channel binding or mutual authentication, however they become as good as possible. This document relaxes the requirements on GSS-API mechanism so that all GSS-API mechanism can be expressed in GS2. For these mechanisms, the "gs2-cb-flag" value MUST always be "n", and the PLUS-variant of the GS2 mechanism name MUST NOT be advertised or negotiated. The SAML SASL bridge [RFC6595] and the SAML OpenID bridge [RFC6616] are two examples of documents that describe such bridges. These documents did not meet the requirements of the original GS2 bridge, but with the update in this document they are conformant. Note that both documents had discussions describing this aspect and sufficient requirements for safe implementation and deployment. From nobody Mon Mar 3 06:27:49 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073BC1A01BC for ; Mon, 3 Mar 2014 06:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHlMy_yPXY5w for ; Mon, 3 Mar 2014 06:27:46 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id EB7BB1A0017 for ; Mon, 3 Mar 2014 06:27:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 8F594206A3 for ; Mon, 3 Mar 2014 09:23:19 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjWrVqPvOwXv for ; Mon, 3 Mar 2014 09:23:19 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (dhcp-9ca7.meeting.ietf.org [31.133.156.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Mon, 3 Mar 2014 09:23:19 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A4A9483EF2; Mon, 3 Mar 2014 09:27:39 -0500 (EST) From: Sam Hartman To: kitten@ietf.org Date: Mon, 03 Mar 2014 09:27:39 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/oFhbqfzYoBfuo_L-VgIFUPt9zeU Subject: [kitten] Stepping down as Kitten co-chair sometime after London X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:27:47 -0000 There's a lot of exciting stuff going on in the GSS-API world. At a minimum, I notice Luke Howard's recent credential UI proposal. MIT and redhat have been working on similar but not entirely compatible nor entirely overlapping credentials stuff. Nicolas Williams has been proposing a lot of great ideas. There's the GS2 update. Microsoft has been busy too with Windows 8 claims, changes to Negoex and how it's integrated, moving towards deprecating SPNEGO. Kitten is not where that work is happening. We have an interesting challenge to figure out whether the IETF can serve a role in future GSS-API evolution. If so, we need to make some significant changes to make it work. If not, then the GSS-API community should find some place to coordinate activities. Speaking as someone who is trying to maintain both applications and mechanisms working across Heimdal, MIT and windows, standardization and coordination has real value. I hope the world doesn't become more fragmented. I'm not the person to help face that challenge. I'd rather be remembered as someone who contributed to the community and who stepped away when they no longer had the energy/alignment to do what is necessary. I'd rather be trusted to do a good job if I find myself returning either to a leadership role in the GSS community or something else in the standards space. To me, an important part of asking for that trust is knowing when you're going to get in the way and standing aside. These days, standardization is less my focus than it has been in the past. I'm enjoying implementing products and building Painless Security as a company. That's fun work, but it's about debugging code, writing code, building a customer base, and designing products. It's taking all my focus. I also have a fairly well established prospective of GSS-API and GSS-API standardization. Perhaps some new viewpoints are required. For these reasons, I would like to step down as Kitten co-chair shortly after the London meeting. It has been a pleasure to work with you all and I do look forward to working with you both within the GSS-API space and beyond. From nobody Mon Mar 3 07:16:39 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BB31A00CB for ; Mon, 3 Mar 2014 07:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4piZYStOKxqS for ; Mon, 3 Mar 2014 07:16:36 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 96E681A004A for ; Mon, 3 Mar 2014 07:16:36 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s23FGXsg018584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 3 Mar 2014 15:16:33 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s23FGWvL026205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Mar 2014 15:16:32 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s23FGWMU003271 for ; Mon, 3 Mar 2014 15:16:32 GMT Received: from dhcp-a198.meeting.ietf.org (/31.133.161.152) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Mar 2014 07:16:31 -0800 Message-ID: <53149CCB.40905@oracle.com> Date: Mon, 03 Mar 2014 08:16:27 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: kitten@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/oKKCJSFJLfTpSbvqTzu_uNZ5q0g Subject: [kitten] Stepping down as kitten co-chair X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 15:16:38 -0000 I too have found myself with less and less time to contribute to the kitten working group as of late. There is a lot of interesting work that is taking place in the GSS-API and SASL space that deserves more attention than I can give at the moment. I would like to help transition my role some time after London or Toronto. After that time, I would like to contribute to the working group when I can. In the mean time I would like to see how far we can get the following work items off the ground: GS2 Update (Simon has volunteered to progress) AES-SHA2 (Consensus calls are out) SASL-OAuth (Bill needs to make additional updates) SASL-SAML-EC (Scott believes that it is ready for WGLC) gssapi-extensions-iana (this would be nice to have out to be in a more autonomous state) It has been a privilege to have worked with my co-chairs over the past 6+ years: Tom Yu, Alexey Melnikov, Josh Howlett, and especially, Sam Hartman Shawn. -- From nobody Mon Mar 3 07:47:15 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8440E1A00BE for ; Mon, 3 Mar 2014 07:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5erafFgTfbDa for ; Mon, 3 Mar 2014 07:47:07 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB8A1A00B0 for ; Mon, 3 Mar 2014 07:47:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EF9C6BE2F; Mon, 3 Mar 2014 15:47:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-UAl59v-O-V; Mon, 3 Mar 2014 15:47:02 +0000 (GMT) Received: from [31.133.165.152] (dhcp-a598.meeting.ietf.org [31.133.165.152]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 29927BE4D; Mon, 3 Mar 2014 15:47:02 +0000 (GMT) Message-ID: <5314A3F6.3010309@cs.tcd.ie> Date: Mon, 03 Mar 2014 15:47:02 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Shawn M Emery , Sam Hartman References: <53149CCB.40905@oracle.com> In-Reply-To: <53149CCB.40905@oracle.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/5dTziYtCMkjH_FefmkNqexvrodw Cc: kitten@ietf.org Subject: Re: [kitten] Stepping down as kitten co-chair X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 15:47:13 -0000 Thanks Sam and Shawn, I really appreciate the work you've both being doing over the years and will I'm sure continue to do in the community. Thanks also for giving the WG time to discuss the way forward and for me to try find new chairs to work with whatever plan emerges. For the WG - you need to be thinking about what you want and how and where to go forward with this work. I look forward to that discussion on the list and this week in London. Cheers, S. On 03/03/2014 03:16 PM, Shawn M Emery wrote: > > I too have found myself with less and less time to contribute to the > kitten working group as of late. There is a lot of interesting work > that is taking place in the GSS-API and SASL space that deserves more > attention than I can give at the moment. I would like to help transition > my role some time after London or Toronto. After that time, I would > like to contribute to the working group when I can. > > In the mean time I would like to see how far we can get the following > work items off the ground: > > GS2 Update (Simon has volunteered to progress) > AES-SHA2 (Consensus calls are out) > SASL-OAuth (Bill needs to make additional updates) > SASL-SAML-EC (Scott believes that it is ready for WGLC) > gssapi-extensions-iana (this would be nice to have out to be in a > more autonomous state) > > It has been a privilege to have worked with my co-chairs over the past > 6+ years: > > Tom Yu, Alexey Melnikov, Josh Howlett, and especially, Sam Hartman > > Shawn. > -- > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > From nobody Mon Mar 3 09:56:13 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4F51A027F for ; Mon, 3 Mar 2014 09:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.22 X-Spam-Level: X-Spam-Status: No, score=-14.22 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAE9tD_e6Z6a for ; Mon, 3 Mar 2014 09:56:09 -0800 (PST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1061A0265 for ; Mon, 3 Mar 2014 09:56:04 -0800 (PST) Received: from BF1-EX10-CAHT07.y.corp.yahoo.com (bf1-ex10-caht07.corp.bf1.yahoo.com [10.74.209.204]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s23HtMWQ032661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Mar 2014 09:55:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1393869323; bh=/HW8wTbgRSlNV30Rm1V/C2CZ/O6VJ1sWgsmezNsAPLA=; h=Date:From:Reply-To:Subject; b=YtX9SecmAucwr7hF/ATZwBmnD/tr8PlOpL31IulTAyp5Kz+0RWO9q9JUveA1UhQCn jvcTQ66paEhYYReL35h6Wewu4YAxXn31OaH8GlIY/taJHwd7yW3YLArgMnpY/56ZVV cMoXDbIp0Sx0NYvJ9kpkRPth+Sk+VL9FdlfoKD7U= Received: from omp1088.mail.ne1.yahoo.com (98.138.101.177) by BF1-EX10-CAHT07.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 3 Mar 2014 12:55:21 -0500 Received: (qmail 86242 invoked by uid 1000); 3 Mar 2014 17:55:21 -0000 Received: (qmail 11107 invoked by uid 60001); 3 Mar 2014 17:55:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1393869321; bh=u/UnMb4OTnJJASiZvuDOtj+tzdJVxiPJWVATd60HUCo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=UY6Yqv/c4eLCNtlOkTSc6mLeUBauCCpLtNjhbmgizPZd6Q+Q9D4xsaQYmRl+4UQ+ZuR/ErMJ8yFjHIdy4SZnl9qcJav41ZZusqQiyCT2kzyjY6SYf6qMf9+QfpTECvQaKpWxESAwL+nf/hg8JkzSm1DP+88Ftbw+5XtGKxcTuDo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=LI1pqqnsRKWsgyAgitDwO0nkxOY+hbrQFvPVez29msEWZi+QVhpD6uEdKdgE5x10IBbcHG9xfD+WJLUIJg1ZRZEP7QO+js+qscbk1hgLY04m2XqXejjf31XHwO70aHWaE5vL+J0f4tKWSGoh4bRcmgnyQwKP0hg1W0xw29vqat4=; X-YMail-OSG: unoB5kwVM1kQBi4PxiHbL0kNxl9v3IeD3sM7LfxayFe_IUA ebyMdCl5_LNmME9LAAQN8i0fDmnjXuM9heE3ZE49vEhquMZNdB1hppsHySl3 I_DYPXrbMJDTrxQa4jIgB_UxamdCtvuk5op7OmIjPII.ABxnwSD6W8azEEOX emhXbOOJIjlfsZleLVxJ3Q4sJCJyGq21ll5X8YJ190CiUaAnVRGF.VvbcO5K qZWPagZTqPDtrmdeHqDnnEW0QZdHiYQL5.d.1FWj0j4ok6DA0GOAsdOt7lAz AcfqNPnYtzolaw.r_tG8L.OUhxuZvx55w Received: from [31.133.161.94] by web125602.mail.ne1.yahoo.com via HTTP; Mon, 03 Mar 2014 09:55:21 PST X-Rocket-MIMEInfo: 002.001, UnlhbiwKCkRvZXMgeW91ciBpbXBsZW1lbnRhdGlvbiBnZXQgdXNlciBmcm9tIHRoZSBrdnBhaXIgInVzZXIiIHBlciAtMDMgb2YgdGhlIHNwZWMgb3IgZGlkIHlvdSBmb2xrcyBkbyB0aGUgLTA0IGFuZCBsYXRlciBHUzIgaGVhZGVyICJhPSR1c2VybmFtZSIgY29uc3RydWN0PwoKVGhlcmUgaXMgInNvb24iIHRvIGJlIG1vdGlvbiBvbiB0aGUgR1MyIHNpZGUgd2hpY2ggbWlnaHQgbWFrZSB0aGUgc3R1YiBHUzIgaGVhZGVyIGZvcm1hdCBhY3R1YWxseSB1c2VmdWwgYWdhaW4sIGJ1dCBJIGFtIHNvcmVseSBpbmMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 Message-ID: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> Date: Mon, 3 Mar 2014 09:55:21 -0800 From: Bill Mills To: "rtroll@googlers.com" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1088529044-914721133-1393869321=:174" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 869323003 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/O29zV6xy-07SoWyZVcUK4W_5bnM Cc: "kitten@ietf.org" Subject: [kitten] sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 17:56:11 -0000 ---1088529044-914721133-1393869321=:174 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ryan,=0A=0ADoes your implementation get user from the kvpair "user" per -03= of the spec or did you folks do the -04 and later GS2 header "a=3D$usernam= e" construct?=0A=0AThere is "soon" to be motion on the GS2 side which might= make the stub GS2 header format actually useful again, but I am sorely inc= lined to just go with your running code and existing integrations as de-fac= to standard if you use the kvpairs.=0A=0A=A0=0A-bill=0A=0A=0A=0A-----------= ---------------------=0AWilliam J. Mills=0A"Paranoid" MUX Yahoo! ---1088529044-914721133-1393869321=:174 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ryan,

Does your implementation get user from the kvpair "user" p= er -03 of the spec or did you folks do the -04 and later GS2 header "a=3D$u= sername" construct?

There is "soon" to be motion on the GS2 side which= might make the stub GS2 header format actually useful again, but I am sore= ly inclined to just go with your running code and existing integrations as = de-facto standard if you use the kvpairs.
 
=
-bill


--------------------------------
William J. Mills=
"Paranoid" MUX Yahoo!

---1088529044-914721133-1393869321=:174-- From nobody Mon Mar 3 10:44:52 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414191A0342 for ; Mon, 3 Mar 2014 10:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZxmTA_ux-kN for ; Mon, 3 Mar 2014 10:44:50 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 659431A034D for ; Mon, 3 Mar 2014 10:44:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id CB937206A2; Mon, 3 Mar 2014 13:40:23 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O5tBJeGnCPO; Mon, 3 Mar 2014 13:40:23 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [130.129.155.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 3 Mar 2014 13:40:23 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8373F83EF2; Mon, 3 Mar 2014 13:44:45 -0500 (EST) From: Sam Hartman To: Bill Mills References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> Date: Mon, 03 Mar 2014 13:44:45 -0500 In-Reply-To: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> (Bill Mills's message of "Mon, 3 Mar 2014 09:55:21 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mO6jm3kUDc_UrmyWyF4i4Pp05Kc Cc: "kitten@ietf.org" Subject: Re: [kitten] sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 18:44:51 -0000 When we talked about removing the GS2 support, I assumed we were maintaining the GS2 header, just dropping the descriptions of the GSS-API mechanism and reference to GS2. Speaking as an individual, I'd prefer to maximize alignment with GS2 even if we do not specify as a GSS-API mechanism at this time. From nobody Mon Mar 3 11:43:31 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4971A0341 for ; Mon, 3 Mar 2014 11:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.22 X-Spam-Level: X-Spam-Status: No, score=-16.22 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, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24fND6cdC4Pt for ; Mon, 3 Mar 2014 11:43:28 -0800 (PST) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by ietfa.amsl.com (Postfix) with ESMTP id AF0621A030D for ; Mon, 3 Mar 2014 11:43:28 -0800 (PST) Received: from BF1-EX10-CAHT02.y.corp.yahoo.com (bf1-ex10-caht02.corp.bf1.yahoo.com [10.74.209.57]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s23Jh0xM010060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Mar 2014 11:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1393875781; bh=qw2RG1F258uu1IVqkPdx+49VMq4ewwEPxQpaiytgw0g=; h=References:Date:From:Reply-To:Subject:In-Reply-To; b=leALCTFqDMno98SxD+S03mxv3FVmnZsFYKoJUstGVgXm9g7oHu4iQHSmgCs0LHotJ 0ksGxYAw4X3xNlQ9uOw+9YcU8vib2v7YG5JFECT4hYZ/oGchZ13YiH0KyHVr1UEXd+ gUOn6T1ioYxq9Lwkih1ogNS1qOzMeesoMCNinF38= Received: from omp1063.mail.ne1.yahoo.com (98.138.226.162) by BF1-EX10-CAHT02.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 3 Mar 2014 14:42:59 -0500 Received: (qmail 82442 invoked by uid 1000); 3 Mar 2014 19:42:59 -0000 Received: (qmail 27179 invoked by uid 60001); 3 Mar 2014 19:42:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1393875779; bh=zfJnGc61wr6QtsGNn3ll2aehCYMN/XYVp9pVdThkNOc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FMGBdowbkxUOdPGDFeqK4s1anJmYfNqn0nZstdV1w+IWfzxsXccJgCE5vvOnkaP/21INeaGapGZXrsswzJ9Fm504/Qf7YmEHU/2DPMSnveHkbexOZ3D1vob7VDNuegiRzhcBg+9aJnreCV98PG20OKd0gF15vOaNu/svC81FJ60= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AbGzFhpSuZiY89N5B4TnPTDoug4411GHvaaan3Of6WVX3IxzZuZ+KFmGFg3zlhYaAAQQko5WWlqTHDXZmcJgaz2moiOb348UW8ZuKeMLEMHh5XnMiHIFwFKgeRBOOHLuQc2ll5AlHZkqem494b+u0997r23AYo6trprSbPXN3xU=; X-YMail-OSG: 0x9LS20VM1mXHy6KFBOxEGvQ.YFDIWT9wu3cccz8K1I4J4K TpvyECGYd_J8i.clEtOWiRFT1LfOtkfTn3BSQF9Oe9cQ8vdQfbjciUsZfHtd s8R1f4c8IDQfmH_iap4Ujra0IwW3z2ZghuP_xDxPDdoBoDJjeSKcgMPfC1MI TO9Mw2oNKFxb2BjYKiGsM4ABscS.O8gTcQA8DDYDYWTj5iGgroCM8hMA6xEd iwIV.8qbvCbEn6voaiBsFNdRwstQeBm0b00V_LLc02Xb_TA_pEemp9ZspPEs jd4CfQakZQnV2BVWzUuCh98OxZm_mHCSg Received: from [31.133.161.94] by web125604.mail.ne1.yahoo.com via HTTP; Mon, 03 Mar 2014 11:42:59 PST X-Rocket-MIMEInfo: 002.001, V2VsbCB0aGF0IGNlcnRhaW5seSB3YXNuJ3QgY2xlYXIuwqAgCgoKVGhlICpvbmx5KiB0aGluZyB3ZSBhdm9pZCBpZiB3ZSBrZWVwIHRoZSBHUzIgaGVhZGVyIGlzIGR1cGxpY2F0aW5nIHRoZSB1c2VybmFtZSBpbiB0aGUgR1MyIGhlYWRlciBhbmQgYWJvdXQgNiBleHRyYSBieXRlcyBpZiB0aGVyZSBldmVyIGlzIGEgR1MyIGJpbmRpbmcgZm9yIE9BdXRoLsKgIFllcyBpdCdzIGNsZWFuZXIgaWYgd2UgbGVhdmUgdGhlIEdTMiBoZWFkZXIgc3R1YiBpbiB0aGVyZSBpZiBHUzIgZXZlciBnZXRzIGltcGxlbWVudGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> Message-ID: <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Mon, 3 Mar 2014 11:42:59 -0800 From: Bill Mills To: Sam Hartman In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-319708309-1393875779=:29082" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 875781000 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/MBMN1RwmthBqaI5gA6avi45QsJU Cc: "kitten@ietf.org" Subject: Re: [kitten] sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 19:43:29 -0000 ---685807438-319708309-1393875779=:29082 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well that certainly wasn't clear.=A0 =0A=0A=0AThe *only* thing we avoid if = we keep the GS2 header is duplicating the username in the GS2 header and ab= out 6 extra bytes if there ever is a GS2 binding for OAuth.=A0 Yes it's cle= aner if we leave the GS2 header stub in there if GS2 ever gets implemented = for it.=0A=0AIs it a compelling enough reason to break existing implementat= ions?=0A=0A-bill=0A=0A=0A=0A--------------------------------=0AWilliam J. M= ills=0A"Paranoid" MUX Yahoo!=0A=0A=0A=0A=0A=0AOn Monday, March 3, 2014 10:4= 5 AM, Sam Hartman wrote:=0A =0AWhen we talked about remo= ving the GS2 support, I assumed we were=0Amaintaining the GS2 header, just = dropping the descriptions of the=0AGSS-API mechanism and=A0 reference to G= S2.=0A=0ASpeaking as an individual, I'd prefer to maximize alignment with G= S2=0Aeven if we do not specify as a GSS-API mechanism at this time. ---685807438-319708309-1393875779=:29082 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Well that= certainly wasn't clear. 

The *only* thing we avoid if we keep the GS2 header is dup= licating the username in the GS2 header and about 6 ext= ra bytes if there ever is a GS2 binding for OAuth.  Yes it's cl= eaner if we leave the GS2 header stub in there if GS2 ever gets implemented= for it.

Is it a compelling enough reason to break existing= implementations?

<= div>-bill


--------------------------------
William J. Mills<= br>"Paranoid" MUX Yahoo!



On Monday, March 3, 2014 10:45 AM, Sam Hartman <hartmans@mit.edu> wr= ote:
When we talked abou= t removing the GS2 support, I assumed we were
maintaining= the GS2 header, just dropping the descriptions of the
GS= S-API mechanism and  reference to GS2.

Speaking as an individual, I'd prefer to maximize alignment with GS2=
even if we do not specify as a GSS-API mechanism at this= time.



---685807438-319708309-1393875779=:29082-- From nobody Mon Mar 3 11:52:36 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844DB1A00E9; Mon, 3 Mar 2014 11:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pY7Fx8Tr-hqH; Mon, 3 Mar 2014 11:52:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBBA1A0376; Mon, 3 Mar 2014 11:52:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303195226.5711.50156.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 11:52:26 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/VJ_7AvpKeuQfrho_ls1frRlkY6E Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-rfc6112bis-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 19:52:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : Anonymity Support for Kerberos Authors : Larry Zhu Paul Leach Sam Hartman Filename : draft-ietf-kitten-rfc6112bis-00.txt Pages : 16 Date : 2014-03-03 Abstract: This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. This document obsoletes RFC 6112 and reclassifies that document as historic. RFC 6112 contained errors and the protocol described in that specification is not interoperable with any known implementation. This specification describes a protocol that interoperates with multiple implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc6112bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 3 21:11:47 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D211A0359; Mon, 3 Mar 2014 21:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGs3kgq8wSk9; Mon, 3 Mar 2014 21:11:39 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (unknown [69.163.253.163]) by ietfa.amsl.com (Postfix) with ESMTP id 47C771A0353; Mon, 3 Mar 2014 21:11:39 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id CEF1E594058; Mon, 3 Mar 2014 21:11:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=XQF+MXius5daosiIjXC9 P2VviNc=; b=uZb65MuRO0Nfyb3dC9sVS5iq8CqyhWooO4a+4fsEjJTKnwhE+PBv fX8XE9fTGSIp1mCh+gQiajn2A0R8TZThh1jQiJB6ZQiZoHweErzm9FQGTya+uyOi njXaue/ZNhK1o4USEb7O//2wYF2IuVh7bfITYRrx8k/JUBKxqcOFbpo= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 5A04C594055; Mon, 3 Mar 2014 21:11:35 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id u57so2473605wes.36 for ; Mon, 03 Mar 2014 21:11:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fMceg/6I3G79e6TQQMr4zUOAs0/ugwa2m2Ysj6UkeDo=; b=JstpNq1zucLpVqrNXG75dX/DW6//vweVg6CL6ONtBZG3h9A/UoTILpsW4k9kuPqQd4 RKTN+z0gGGis79V9zKtlMy4/r/Gr9cSuUf+a+QbeCHDFN0/QaJdsXgcJahk6hMffATMK Aa0Dcpv+WzW8mF1jvdzR+v7uAqFiQrqxcd2Ki6rBH+S2oE+3Ch13EDUplzZcO3f298Fk 2L6DPJ+tjTC50nJvzvLkigsZXeIc6KLHV6e5DYhZjzJmdkyENiGoXtKNrA6/WLON79SN kj7PobSLytKGCzt2sGeiMkB/tb92+AifN4Esq13TSZK1HfYMck1SCBpix5dYaN+G+v59 /ZAQ== MIME-Version: 1.0 X-Received: by 10.194.57.239 with SMTP id l15mr24212322wjq.40.1393909894084; Mon, 03 Mar 2014 21:11:34 -0800 (PST) Received: by 10.217.108.132 with HTTP; Mon, 3 Mar 2014 21:11:34 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Mar 2014 23:11:34 -0600 Message-ID: From: Nico Williams To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/bQG6ip-dcC34fyZvJy4G8JERBCw Cc: "kitten@ietf.org" , Andrei Popov , "tls@ietf.org" Subject: Re: [kitten] [TLS] MITM Attacks on Client Authentication after Resumption X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 05:11:44 -0000 [Cross-posting to kitten@ietf.org. Please drop one of tls or kitten when responding. For KITTEN readers, see the TLS list archives, there's an MITM vulnerability when using tls-unique in conjunction with session resumption.] On Mon, Mar 3, 2014 at 4:07 PM, Adam Langley wrote: > On Mon, Mar 3, 2014 at 4:07 PM, Andrei Popov wrote: >> It appears that the attack described is only feasible when two >> implementation defects are present: > > That's not an unreasonable characterisation of the renegotiation-based > attacks, but the problem with tls-unique is more fundamental. The problem for tls-unique is more fundamental indeed, and Andrei's characterization is not applicable. We should talk about how to fix tls-unique. The best fix may be to keep track of the original (non-resumed) connection's tls-unique CB and add that to the resumed connection's tls-unique CB. This requires adding to the session cache on the client side. In the short-term, client and server applications should not permit session resumption prior to channel-bound authentication (if using tls-unique). Except that, of course, how is the application to know if session resumption is involved? Assuming that it can't know or prevent the use of session resumption, I'd say that tls-unique is just simply not to be used. We should publish a new tls-unique that doesn't have this problem. Nico -- From nobody Tue Mar 4 00:06:22 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635CA1A03FF for ; Tue, 4 Mar 2014 00:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkLLfOtJVSPm for ; Tue, 4 Mar 2014 00:06:19 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 713C21A03EC for ; Tue, 4 Mar 2014 00:06:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 10531206A2; Tue, 4 Mar 2014 03:01:51 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C799eck0Bc5C; Tue, 4 Mar 2014 03:01:50 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [130.129.155.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 4 Mar 2014 03:01:50 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3B63C83EF2; Tue, 4 Mar 2014 03:06:13 -0500 (EST) From: Sam Hartman To: Bill Mills References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Tue, 04 Mar 2014 03:06:13 -0500 In-Reply-To: <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> (Bill Mills's message of "Mon, 3 Mar 2014 11:42:59 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/8KfBP3JuSi1c9RHXwA6Y6TSUa58 Cc: "kitten@ietf.org" Subject: Re: [kitten] sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 08:06:20 -0000 t's discuss Thursday. I'd like to understand what the user= value signifies and whether it's actually a SASL authorization identifier. I'd like to understand whether there's value in an unprotected SASL authorization identifier. From nobody Tue Mar 4 06:36:25 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D731A0125 for ; Tue, 4 Mar 2014 06:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHgdmS4L3_Md for ; Tue, 4 Mar 2014 06:36:11 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id AC52F1A0119 for ; Tue, 4 Mar 2014 06:36:10 -0800 (PST) Received: from mail65-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Tue, 4 Mar 2014 14:36:07 +0000 Received: from mail65-tx2 (localhost [127.0.0.1]) by mail65-tx2-R.bigfish.com (Postfix) with ESMTP id 175E3A026C; Tue, 4 Mar 2014 14:36:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.222; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf08; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: VPS-16(z579ehzbb2dI98dI9371Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24ach24d7h2516h2545h255eh25cch1b1cn1b1bi1155h) Received-SPF: pass (mail65-tx2: domain of osu.edu designates 164.107.81.222 as permitted sender) client-ip=164.107.81.222; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf08 ; cio-tnc-pf08 ; Received: from mail65-tx2 (localhost.localdomain [127.0.0.1]) by mail65-tx2 (MessageSwitch) id 1393943765255110_26667; Tue, 4 Mar 2014 14:36:05 +0000 (UTC) Received: from TX2EHSMHS010.bigfish.com (unknown [10.9.14.233]) by mail65-tx2.bigfish.com (Postfix) with ESMTP id 362A13A00B8; Tue, 4 Mar 2014 14:36:05 +0000 (UTC) Received: from cio-tnc-pf08 (164.107.81.222) by TX2EHSMHS010.bigfish.com (10.9.99.110) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 4 Mar 2014 14:36:04 +0000 Received: from CIO-TNC-HT06.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-tnc-pf08 (Postfix) with ESMTPS id 646482E0074; Tue, 4 Mar 2014 09:36:03 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.03.0174.001; Tue, 4 Mar 2014 09:36:03 -0500 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] [TLS] MITM Attacks on Client Authentication after Resumption Thread-Index: AQHPN7cRjDuzOiHFxUOb4nSlBWlIcg== Date: Tue, 4 Mar 2014 14:36:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.83] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/JvhBm5ufWvYyfX7C8VmyzycOMFM Cc: "kitten@ietf.org" Subject: Re: [kitten] [TLS] MITM Attacks on Client Authentication after Resumption X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:36:22 -0000 On 3/4/14, 12:11 AM, "Nico Williams" wrote: >[Cross-posting to kitten@ietf.org. Please drop one of tls or kitten >when responding. For KITTEN readers, see the TLS list archives, >there's an MITM vulnerability when using tls-unique in conjunction >with session resumption.] Is it accurate to say that the threat with tls-server-endpoint is more like the other cases discussed? I'm much more concerned about that option, because tls-unique is essentially unimplementable with most software anyway. -- Scott From nobody Tue Mar 4 07:56:35 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9511A0154 for ; Tue, 4 Mar 2014 07:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.32 X-Spam-Level: X-Spam-Status: No, score=-16.32 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, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTppGjhkL_d8 for ; Tue, 4 Mar 2014 07:56:28 -0800 (PST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id C4C941A0141 for ; Tue, 4 Mar 2014 07:56:28 -0800 (PST) Received: from GQ1-EX10-CAHT03.y.corp.yahoo.com (gq1-ex10-caht03.corp.gq1.yahoo.com [10.73.118.82]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s24Fu0m2075680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Mar 2014 07:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1393948560; bh=sf0gCdSvh1H6C3s63j+hPRlJb5loMc1Q32817yEH/FA=; h=References:Date:From:Reply-To:Subject:In-Reply-To; b=iqcVOheZDz7RN3HCx+oxg579zLybo3MaJJ42DduVrOmp2kyUNPSzNGNyWFPVzOqtP cxwOfRMBcjiGHSWdX5Nlavo7uyBKC4fMAaQtIODn2O6ekT5wDyGZh83u1qQzmvW1uB oLNGTuaA3t6Xo2xdrFTveeB4TZ0Y/4hKSmjfwRxE= Received: from omp1012.mail.ne1.yahoo.com (98.138.87.12) by GQ1-EX10-CAHT03.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 4 Mar 2014 07:55:59 -0800 Received: (qmail 41781 invoked by uid 1000); 4 Mar 2014 15:55:58 -0000 Received: (qmail 75983 invoked by uid 60001); 4 Mar 2014 15:55:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1393948558; bh=HrGQLRIzGuqeB48Avainf8QOPi9Whjfsnhjyvo9x+78=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AqMOPJr2Iyt48ZSc+JqB3gUAOjc546qU/WAEN3DAFrvtEgNpRW0/VreKbdxic2VFxeX1bBsHdtnAhR6wf2gSFW+Eu5haBXXRW4mi9baYH05XNgP1uBqIiQ3ZUkbBobjh1QuLjLCLIn3xMJWhEk35xMat1rGEUNgyFFrreMF4kwU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=O1hqmWz5j4D6JppfYcLfofuPyP3C9DrFV5k9LFkZNdw1717aDsqlQy3TExOenvMXKCW2IXHrc8L5qojOKoVVL3aSZMBUms+uA7dN50NPzqEvDlFK7RFYxq/RI24vD5uS/jFa0Xx1Fuz3NnaJ1pF5bp48dqhz63utChtIFLq0A0s=; X-YMail-OSG: M_T3jA0VM1kaVi8qrbL3sL77864FNW944V5FwoXSP8.EPf4 G1Aoe0eM7znO3INJ9ClLjMyd2lItWN9SgZ7JmUiIfw2WL2RLMeF.NLfNCKml _CcfUt.WrFtCR9Vuj1MCGYtE99wm6zmcudsjWtvDLOUc5kJwBZNFcXwjr6.p dEMqwL9eYhjCDTD8O0x.vQd3C2aY9M9GZ4eYvGo0nm0LEnIiv.1tex27EcLJ 333OcyvWZ8T2so3jFYwopuLS4cTkcHnv490F2039LyBk6Z9fHnqm0K_9NSLE PjtEyqi0p4Lyi.djRfvVmN9KurwayVzC4yTiOtQ-- Received: from [31.133.164.44] by web125602.mail.ne1.yahoo.com via HTTP; Tue, 04 Mar 2014 07:55:58 PST X-Rocket-MIMEInfo: 002.001, CgpJdCBpcyBub3QgdXNlZCBhcyBhIFNBU0wgaWRlbnRpdHkuwqAgUXVvdGluZyBmcm9tIC0wMyBhbmQgLTE0IGluIHByb2dyZXNzOgoKInVzZXIgKFJFUVVJUkVEKToKCkNvbnRhaW5zIHRoZSB1c2VyIG5hbWUgYmVpbmcgCmF1dGhlbnRpY2F0ZWQuICBUaGUgc2VydmVyIE1BWSB1c2UgdGhpcyBhcyBhIHJvdXRpbmcgb3IgZGF0YWJhc2UgbG9va3VwIApoaW50LiAgVGhlIHNlcnZlciBNVVNUIE5PVCB1c2UgdGhpcyBhcyBhdXRob3JpdGF0aXZlLCB0aGUgdXNlciBuYW1lIE1VU1QgYmUgYXNzZXJ0ZWQgYnkgdGgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> Message-ID: <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> Date: Tue, 4 Mar 2014 07:55:58 -0800 From: Bill Mills To: Sam Hartman In-Reply-To: <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1088529044-1026665938-1393948558=:69282" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 948560000 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/pb9rgZ2izOV5VHEesrNtIEXCX3M Cc: "kitten@ietf.org" Subject: Re: [kitten] sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:56:30 -0000 ---1088529044-1026665938-1393948558=:69282 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A=0AIt is not used as a SASL identity.=A0 Quoting from -03 and -14 in pro= gress:=0A=0A"user (REQUIRED):=0A=0AContains the user name being =0Aauthenti= cated. The server MAY use this as a routing or database lookup =0Ahint. T= he server MUST NOT use this as authoritative, the user name MUST be asserte= d by the OAuth credential."=0A=A0=0AAlso, looking at the Google API docs fo= r XOAUTH2, they implemented based on the -03 spec and have the "user=3D$use= rname" syntax.=A0 See https://developers.google.com/gmail/xoauth2_protocol = =0A=0ABased on Google's server API and the extant clients they have I'd lik= e to ask for a consensus call on the following:=0A=0A1) Add the -03 "user" = kvpair back into the spec.=0A=0Aa) YES or b) NO.=A0 =0A=0A2) Should we incl= ude a GS2 header"=0A=0Aa) No, let's wait for the GS2 update that deals with= things that lack mutual auth and then write a spec that defines a GS2 head= er for SASL+OAUTH.=0A=0Ab) Change the definition of "key" in kvpair to 1*(A= LPHA / ",").=A0 This makes a GS2 header followed by a ^A (i.e. "n,a=3Duser@= example.com^A") a valid kvpair which would be ignored by servers that don't= understand it. =0A=0Ac) Define a stub OPTIONAL GS2 header explicitly.=0A= =0Ad) Include a fully=0A defined GS2 header (language from draft -10).=0A= =0A=0AMy own feedback is 1: YES, 2: a or b.=0A=0A=0A-bill=0A=0A=0A=0A------= --------------------------=0AWilliam J. Mills=0A"Paranoid" MUX Yahoo!=0A=0A= =0A=0A=0A=0AOn Tuesday, March 4, 2014 12:06 AM, Sam Hartman wrote:=0A =0At's discuss Thursday.=0AI'd like to understand what t= he user=3D value signifies and whether it's=0Aactually a SASL authorization= identifier.=0A=0AI'd like to understand whether there's value in an unprot= ected SASL=0Aauthorization identifier. ---1088529044-1026665938-1393948558=:69282 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It is = not used as a SASL identity.  Quoting from -03 and -14 in progress:
"user (REQUIRED):

Contains the user name be= ing =0Aauthenticated. The server MAY use this as a routing or database loo= kup =0Ahint. The server MUST NOT use this as authoritative, the user name = MUST=0A be asserted by the OAuth credential."
 
Also, looking at the Google API docs for XOAUTH2, they implemente= d based on the -03 spec and have the "user=3D$username" syntax.  See h= ttps://developers.google.com/gmail/xoauth2_protocol

Based on Google's server API and the extant clients they hav= e I'd like to ask for a consensus call on the following:
=
1) Add the -03 "user" kvpair back into the spec.

a) YES or b) NO. 
2) Should we include a GS2 header"

a) No, let's wait for the GS2 update that deals with things th= at lack mutual auth and then write a spec that defines a GS2 header for SAS= L+OAUTH.

b) Change the definition of "= key" in kvpair to 1*(ALPHA / ",").  This makes a GS2 header followed b= y a ^A (i.e. "n,a=3Duser@example.com^A") a valid kvpair which would be ignored by serve= rs that don't understand it.

c) Defin= e a stub OPTIONAL GS2 header explicitly.

d) Include a fully=0A defined GS2 header (language from draft -10).


My own feedback is 1: Y= ES, 2: a or b.

-bill


------------------------= --------
William J. Mills
"Paranoid" MU= X Yahoo!


On Tuesday, March 4, 2014 12:06 AM, Sam Hartman <hartmans-ietf@mit.edu>= wrote:
t's discuss Thursday.
I'd like to understand = what the user=3D value signifies and whether it's
actuall= y a SASL authorization identifier.

I'd= like to understand whether there's value in an unprotected SASL
authorization identifier.



=

---1088529044-1026665938-1393948558=:69282-- From nobody Tue Mar 4 08:50:05 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD971A0243 for ; Tue, 4 Mar 2014 08:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOlDIg8U5Zo4 for ; Tue, 4 Mar 2014 08:49:57 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0641A021C for ; Tue, 4 Mar 2014 08:49:56 -0800 (PST) X-AuditID: 1209190e-f79ee6d000000c40-98-53160431676f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 6D.3B.03136.13406135; Tue, 4 Mar 2014 11:49:53 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s24GnqAS032064 for ; Tue, 4 Mar 2014 11:49:53 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s24GnpMa017784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 4 Mar 2014 11:49:52 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s24GnoMQ020488; Tue, 4 Mar 2014 11:49:50 -0500 (EST) Date: Tue, 4 Mar 2014 11:49:50 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixG6nomvIIhZs0PhPy+Lo5lUsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+L5nOntBk2DFkX/f2BsYL/B2MXJySAiYSDz6fIMNwhaTuHBv PZDNxSEkMJtJYs60LkYI5xijxO5vfUwQznUmiZ2dzUwgLUIC9RI3734Bsjk4WAS0JJYfiwEJ swmoSMx8sxFsqoiAsMTure+YQUqEBZwlNu6KAAlzCjhJXJwHsZhXwEGi+d9DmPGMEls/vQBL iAroSKzeP4UFokhQ4uTMJ2A2s4ClxL+1v1gnMArMQpKahSS1gJFpFaNsSm6Vbm5iZk5xarJu cXJiXl5qka6xXm5miV5qSukmRlDwcUry7WD8elDpEKMAB6MSD6/DFJFgIdbEsuLK3EOMkhxM SqK8/5nEgoX4kvJTKjMSizPii0pzUosPMUpwMCuJ8Jq+EA0W4k1JrKxKLcqHSUlzsCiJ89Za /AoSEkhPLEnNTk0tSC2CycpwcChJ8O5mABoqWJSanlqRlplTgpBm4uAEGc4DNPwEyGLe4oLE 3OLMdIj8KUZFKXHezyAJAZBERmkeXC8sObxiFAd6RZjXkBmoigeYWOC6XwENZgIa/OU1yNXF JYkIKakGxjnHNnEs8DxcYMYi9dK1hv2P0N35Oc0X3HtOek86Zv0o60OLBfPcj3ev31azF82e metgucTp780TexfqZ7e5yJZeOWJkftsvxESUp7rE1s7z2rscdt99Nn5qeUo15lXT5NKPHV9/ bW7u4cUNqx0EQvzCmcxOTzYyTDBYffuAZvBtOwfl2Mv5SizFGYmGWsxFxYkA+hGBlOkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/NvdOECxJwHFipemgP4qdEAuZfx0 Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 16:49:59 -0000 Digging up an old thread.... The wheels of progress have slowly spun, and the registry at http://www.iana.org/assignments/kerberos-v-gss-api/kerberos-v-gss-api.xhtml#token-types has been updated to include the rest of the token types from RFC 4121, and the values from RFCs 1964 and 6880. As expected, values from in-progress I-Ds were not included. In particular, the value 0405 from draft-ietf-krb-wg-gssapi-cfx-02 which was removed before that document became RFC 4121, and the value 0501 from draft-ietf-kitten-iakerb-00 (now -01), were not added. Apparently they were declined on the grounds that they don't meet the criteria defined in section 7.2 of draft-ietf-abfab-gss-eap: In the top-level registry titled "Kerberos V GSS-API Mechanism Parameters", a subregistry called "Kerberos GSS-API Token Type Identifiers" was created; the references for this subregistry are RFC 4121 and this document. The allocation procedure is Expert Review [RFC5226]. The Expert's primary job is to make sure that token type identifiers are requested by an appropriate requester for the RFC 4121 mechanism in which they will be used and that multiple values are not allocated for the same purpose. For RFC 4121 and this mechanism, the Expert is currently expected to make allocations for token identifiers from documents in the IETF stream; effectively, for these mechanisms, the Expert currently confirms the allocation meets the requirements of the IETF Review process. The RFC 4121 (krb5) and RFC 7055 (EAP) mechanisms appear to be specifically called out to have the expected behavior of the exper reviewer essentially be "standards action", to confirm that the assignment has had adequate IETF review. Perhaps token types used by some other mechanism could get by with a weaker review standard. To me, this seems like a(nother) bug in RFC 7055, but of course it is not one that can be reasonably fixed. I guess that the easiest way forward is to publish a quick document that reserves 0405 and 0501 noting that they were in use before the registry was established. -Ben From nobody Tue Mar 4 10:05:09 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7239E1A02BE for ; Tue, 4 Mar 2014 10:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.62 X-Spam-Level: X-Spam-Status: No, score=-15.62 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, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu0YxyrhPNlA for ; Tue, 4 Mar 2014 10:04:56 -0800 (PST) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by ietfa.amsl.com (Postfix) with ESMTP id DAFC61A02B9 for ; Tue, 4 Mar 2014 10:04:55 -0800 (PST) Received: from GQ1-EX10-CAHT16.y.corp.yahoo.com (gq1-ex10-caht16.corp.gq1.yahoo.com [10.73.119.197]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s249nOLL048280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Mar 2014 01:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1393926565; bh=B6JYUXZU4Nhc+UAq+l7NTxeLN6uL9k2DedHYLWsSFbk=; h=References:Date:From:Reply-To:Subject:In-Reply-To; b=uyzqvNFYBlnGIrz+lw4ksb+lXeRvUMC9k1F6vVHgmhtXthrH0e8l+WjaicbrU2KlV /2bkR6pzC9y9jnR/FOOodQiaGHZzc36LcJdhsmEelW9OHT6yBOoJBUjQtB7JEEZ/Rh 6C5kElY9zqqplc9H1M1+BnhX56MyRry8KvupM1HU= Received: from omp1081.mail.ne1.yahoo.com (98.138.101.170) by GQ1-EX10-CAHT16.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 4 Mar 2014 01:49:23 -0800 Received: (qmail 1427 invoked by uid 1000); 4 Mar 2014 09:49:22 -0000 Received: (qmail 3744 invoked by uid 60001); 4 Mar 2014 09:49:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1393926562; bh=VdBYBb+EE9CFO674TpaFUAAYuxIAHVKz6JbwtxhdWjU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=abeQwxFyTv0I5xkcY9V9FKSHH2wBzrKvibYbdLDyOTkvXKffSKSNT+wTgryYw3UbAYXbwURQRdOluaoCy9HmTnb2RkGO88GvdCvn8t6qvthp4IQCfw5EK2GUE8WJrO/DHuXx/jiLH6n8xnW8lsIYNvTGIRg0Aa52aBEEgC40AIg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hah8x+CXgRBSXBkOJheoSdGn0QXDO/UjkuhlAU1L0OrppiglxcuOQtVJaFoJwWp3sso2mWheDp5qChNC7qa8DV2SIXesAkg0BPXgimdxfo/MlYTbsNVagljla66da5mQBxi0jphbKOO4qF80zr6ewDKosp3+oAW8Bw/TuvG2Ndk=; X-YMail-OSG: ApNk2mIVM1kgcaAL7qLNRW.KQz3ts3fqKU_Bb0uKXVoVb8o kZRAXnP3Qngoe6paiGBvxZKSpSj7cqqh7.RkdLZ7OaUQFhdSIEYgiBPowi3f X8IJJMcdH0rUrt90WvOtGlUBJE5S.K9QAyJY1Ng_HSN2_dFiSQOZ.I82Kocs FdT2EqGgS5YqztsfOj_q9tVLv.zFmHP63ls0Fo7BZW2uI780RCRbIFU9A.Er YxB205yTqXHMcmkeH_g791dcVkuQpmyBt5Is2F5u7BbHXquF598aYN1vZeKQ 7b5oogg9Kccv7UWM2srgGqKUrnAAWeoiNRhHwOw-- Received: from [31.133.164.44] by web125603.mail.ne1.yahoo.com via HTTP; Tue, 04 Mar 2014 01:49:22 PST X-Rocket-MIMEInfo: 002.001, CgpJdCBpcyBub3QgdXNlZCBhcyBhIFNBU0wgaWRlbnRpdHkuwqAgUXVvdGluZyBmcm9tIC0wMyBhbmQgLTE0IGluIHByb2dyZXNzOgoKInVzZXIgKFJFUVVJUkVEKToKCkNvbnRhaW5zIHRoZSB1c2VyIG5hbWUgYmVpbmcgCmF1dGhlbnRpY2F0ZWQuICBUaGUgc2VydmVyIE1BWSB1c2UgdGhpcyBhcyBhIHJvdXRpbmcgb3IgZGF0YWJhc2UgbG9va3VwIApoaW50LiAgVGhlIHNlcnZlciBNVVNUIE5PVCB1c2UgdGhpcyBhcyBhdXRob3JpdGF0aXZlLCB0aGUgdXNlciBuYW1lIE1VU1QgYmUgYXNzZXJ0ZWQgYnkgdGgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> Message-ID: <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> Date: Tue, 4 Mar 2014 01:49:22 -0800 From: Bill Mills To: Sam Hartman In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="933233344-217989408-1393926562=:54403" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 926564002 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/obRKOCX0Us4E_9izK1j1Q6cbSVI Cc: "kitten@ietf.org" Subject: Re: [kitten] sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 18:04:58 -0000 --933233344-217989408-1393926562=:54403 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A=0AIt is not used as a SASL identity.=A0 Quoting from -03 and -14 in pro= gress:=0A=0A"user (REQUIRED):=0A=0AContains the user name being =0Aauthenti= cated. The server MAY use this as a routing or database lookup =0Ahint. T= he server MUST NOT use this as authoritative, the user name MUST be asserte= d by the OAuth credential."=0A=A0=0AAlso, looking at the Google API docs fo= r XOAUTH2, they implemented based on the -03 spec and have the "user=3D$use= rname" syntax.=A0 See https://developers.google.com/gmail/xoauth2_protocol = =0A=0ABased on Google's server API and the extant clients they have I'd lik= e to ask for a consensus call on the following:=0A=0A1) Add the -03 "user" = kvpair back into the spec.=0A=0Aa) YES or b) NO.=A0 =0A=0A2) Should we incl= ude a GS2 header"=0A=0Aa) No, let's wait for the GS2 update that deals with= things that lack mutual auth and then write a spec that defines a GS2 head= er for SASL+OAUTH.=0A=0Ab) Change the definition of "key" in kvpair to 1*(A= LPHA / ",").=A0 This makes a GS2 header followed by a ^A (i.e. "n,a=3Duser@= example.com^A") a valid kvpair which would be ignored by servers that don't= understand it. =0A=0Ac) Define a stub OPTIONAL GS2 header explicitly.=0A= =0Ad) Include a fully defined GS2 header (language from draft -10).=0A=0A= =0AMy own feedback is 1: YES, 2: a or b.=0A=0A=0A-bill=0A=0A=0A=0A---------= -----------------------=0AWilliam J. Mills=0A"Paranoid" MUX Yahoo!=0A=0A=0A= =0A=0A=0AOn Tuesday, March 4, 2014 12:06 AM, Sam Hartman wrote:=0A =0At's discuss Thursday.=0AI'd like to understand what the = user=3D value signifies and whether it's=0Aactually a SASL authorization id= entifier.=0A=0AI'd like to understand whether there's value in an unprotect= ed SASL=0Aauthorization identifier. --933233344-217989408-1393926562=:54403 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It is not used as a SASL iden= tity.  Quoting from -03 and -14 in progress:
"= user (REQUIRED):

Contains the user name being =0Aauthenticated. The server MAY= use this as a routing or database lookup =0Ahint. The server MUST NOT use= this as authoritative, the user name MUST=0A be asserted by the OAuth cred= ential."
 
Also, looking at the Google API docs for X= OAUTH2, they implemented based on the -03 spec and have the "user=3D$userna= me" syntax.  See https://developers.google.com/gmail/xoauth2_protocol =

Based on Google's server API and the extant clients they have I'd l= ike to ask for a consensus call on the following:

1) Add the -03 "us= er" kvpair back into the spec.

a) YES or b) NO. 

2) Sho= uld we include a GS2 header"

a) No, let's wait for the GS2 update th= at deals with things that lack mutual auth and then write a spec that defin= es a GS2 header for SASL+OAUTH.

b) Change the definition of "key" in= kvpair to 1*(ALPHA / ",").  This makes a GS2 header followed by a ^A = (i.e. "n,a=3Duser@example.com^A") a valid kvpair which would be ignored by = servers that don't understand it.

c) Define a stub OPTIONAL GS2 hea= der explicitly.

d) Include a fully defined GS2 header (language from draft -10).


My own feedback i= s 1: YES, 2: a or b.

-bill


------------------= --------------
William J. Mills
"Paranoid" MUX Yahoo!
<= br>


<= div style=3D"font-family: Courier New, courier, monaco, monospace, sans-ser= if; font-size: 14pt;">
On Tuesday, March 4, 2014 12:= 06 AM, Sam Hartman <hartmans-ietf@mit.edu> wrote:
=
t's discuss Thursday.
I'd= like to understand what the user=3D value signifies and whether it's
actually a SASL authorization identifier.

I'd like to understand whether there's value in an unpr= otected SASL
authorization identifier.



=
--933233344-217989408-1393926562=:54403-- From nobody Tue Mar 4 12:41:38 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729721A02D2 for ; Tue, 4 Mar 2014 12:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocAsFWBNrih2 for ; Tue, 4 Mar 2014 12:41:36 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (unknown [69.163.253.181]) by ietfa.amsl.com (Postfix) with ESMTP id 544E41A0235 for ; Tue, 4 Mar 2014 12:41:36 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 049DD360078 for ; Tue, 4 Mar 2014 12:41:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=N6OkdwMxh1vISC4LLExo sRmKpJo=; b=JC48rNMEUszH8T3NvkgbTfNMC+LKpqlqMTXJUaFX8XHVsQeu6PQw xWQpNh1/5Kx+XBSNhG6Dgz+2ruKr0F5tQVAHb3TQFCXHgFBcu7HB2jmOc9rJq/iV O+6L9OnwKXfLVJigUBnEJhjV2lEY79p1Lc5+DI6COKGQng68IEBUDDw= Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 862CC360075 for ; Tue, 4 Mar 2014 12:41:32 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id q58so82922wes.12 for ; Tue, 04 Mar 2014 12:41:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tv63WPHtcJ4wx+HEF/MI0teowr9or3RyhVrBWaBf/jI=; b=WeXkXU5ORWAdihgcTd8/hibXAy8cTp9HnUKGrWEfjDG3Zki7KNcwV6SArlQ1ceJetA 5Mih6+IZLwFMBx9JlFpchdAHH2vP6gHBi+1DFCR5KMLxB/HJcmmXhsfDXNzfjactR9MA SwlNZUd8xZi0OebbaRoXCFw73FgyQARoceLeSsBSCsoTtLZVD0o+MP381f2mqWvEPNmb asPkyezWTF9VyrFXYYC1Qh2EDw3o/BS+CEGPrDN4pyoztJuYezYzJFMkXhTR1WWRqhpb NO1Yr3/mwFXkK28LWdEgVSO9QSefLbtBFCCv7d6S0aG80FtMvTu0ESmhk12fAS+ptimf yr/g== MIME-Version: 1.0 X-Received: by 10.194.78.77 with SMTP id z13mr2524791wjw.64.1393965691211; Tue, 04 Mar 2014 12:41:31 -0800 (PST) Received: by 10.217.108.132 with HTTP; Tue, 4 Mar 2014 12:41:31 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Mar 2014 14:41:31 -0600 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/wcpbsb-sFPfUexJabEnzPxzk_Pg Cc: "kitten@ietf.org" Subject: Re: [kitten] [TLS] MITM Attacks on Client Authentication after Resumption X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 20:41:37 -0000 On Tue, Mar 4, 2014 at 8:36 AM, Cantor, Scott wrote: > On 3/4/14, 12:11 AM, "Nico Williams" wrote: > >>[Cross-posting to kitten@ietf.org. Please drop one of tls or kitten >>when responding. For KITTEN readers, see the TLS list archives, >>there's an MITM vulnerability when using tls-unique in conjunction >>with session resumption.] > > Is it accurate to say that the threat with tls-server-endpoint is more > like the other cases discussed? Yes. We should fix this too. > I'm much more concerned about that option, because tls-unique is > essentially unimplementable with most software anyway. I'm not so certain. At any rate, the proposed fix of binding the master secret of resumed sessions to the original session would fix tls-unique, but not tls-server-end-point. Nico -- From nobody Tue Mar 4 13:36:17 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6ED1A00F0 for ; Tue, 4 Mar 2014 13:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAiymu7Uuo1l for ; Tue, 4 Mar 2014 13:36:11 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBA51A02DD for ; Tue, 4 Mar 2014 13:36:10 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s24La6bP000693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Mar 2014 16:36:06 -0500 Received: from [10.3.113.6] ([10.3.113.6]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s24La5eC001015; Tue, 4 Mar 2014 16:36:05 -0500 From: Simo Sorce To: Benjamin Kaduk In-Reply-To: References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Tue, 04 Mar 2014 16:36:04 -0500 Message-ID: <1393968964.22047.99.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mr_MUH7DU0W7MxhX7aV0xvxodVk Cc: kitten@ietf.org Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 21:36:13 -0000 On Tue, 2014-03-04 at 11:49 -0500, Benjamin Kaduk wrote: > > To me, this seems like a(nother) bug in RFC 7055, but of course it is > not one that can be reasonably fixed. I guess that the easiest way > forward is to publish a quick document that reserves 0405 and 0501 > noting that they were in use before the registry was established. +1 if there is a registry we must avoid errors in allocations, and allocating 0405 or 0501 to something else would definitely cause standards issues. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Tue Mar 4 13:44:37 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DEF1A0139 for ; Tue, 4 Mar 2014 13:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlQI9ecXz3pA for ; Tue, 4 Mar 2014 13:44:32 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (smtp01.srv.cs.cmu.edu [128.2.217.200]) by ietfa.amsl.com (Postfix) with ESMTP id 297BF1A00F0 for ; Tue, 4 Mar 2014 13:44:32 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s24LiQWe029849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 4 Mar 2014 16:44:27 -0500 (EST) Message-ID: <1393969466.4395.211.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Simo Sorce Date: Tue, 04 Mar 2014 16:44:26 -0500 In-Reply-To: <1393968964.22047.99.camel@willson.li.ssimo.org> References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> <1393968964.22047.99.camel@willson.li.ssimo.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.200 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/JHpYwIox5OVR_IN_9RnFoSpm0WU Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 21:44:34 -0000 On Tue, 2014-03-04 at 16:36 -0500, Simo Sorce wrote: > On Tue, 2014-03-04 at 11:49 -0500, Benjamin Kaduk wrote: > > > > To me, this seems like a(nother) bug in RFC 7055, but of course it is > > not one that can be reasonably fixed. I guess that the easiest way > > forward is to publish a quick document that reserves 0405 and 0501 > > noting that they were in use before the registry was established. > > +1 if there is a registry we must avoid errors in allocations, and > allocating 0405 or 0501 to something else would definitely cause > standards issues. No, you have it backwards. The registry doesn't create the requirement to avoid conflicting allocations; it is a tool for helping to meet that requirement. We probably don't actually need to publish a document; it ought to be sufficient to point out to IANA that there is a conflict and ask that the relevant numbers be marked reserved. -- Jeff From nobody Tue Mar 4 13:46:19 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94ABA1A0177 for ; Tue, 4 Mar 2014 13:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 691TbfXMxGOw for ; Tue, 4 Mar 2014 13:46:14 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDA01A00FF for ; Tue, 4 Mar 2014 13:46:14 -0800 (PST) X-AuditID: 12074424-f79e26d000000c70-e4-531649a22ce3 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 7D.3B.03184.2A946135; Tue, 4 Mar 2014 16:46:10 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s24LkA1c005570; Tue, 4 Mar 2014 16:46:10 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s24Lk8sR027786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Mar 2014 16:46:09 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s24Lk7Px028318; Tue, 4 Mar 2014 16:46:07 -0500 (EST) Date: Tue, 4 Mar 2014 16:46:07 -0500 (EST) From: Benjamin Kaduk To: Jeffrey Hutzelman In-Reply-To: <1393969466.4395.211.camel@minbar.fac.cs.cmu.edu> Message-ID: References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> <1393968964.22047.99.camel@willson.li.ssimo.org> <1393969466.4395.211.camel@minbar.fac.cs.cmu.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrLvIUyzYYONfS4vr78+xWxzdvIrF gcljf+sxVo8lS34yBTBFcdmkpOZklqUW6dslcGVc7VnNWvCRqeLgisdMDYwLmboYOTkkBEwk Lp1azQZhi0lcuLceyObiEBKYzSRx6MQSVghnA6PEnVuroTIHmSS+PfrIDNIiJFAvsfngS3YQ m0VAS+L11xOsIDabgIrEzDcbwcaKCKhK3JsziwXEZhYQllh/bgZQLweHsICzxMZdESBhTgE7 iUtnJ4NdxCvgIHFi1jR2iPHfmCQaFhaC2KICOhKr909hgagRlDg58wnUSEuJc3+us01gFJyF JDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXXO93MwSvdSU0k2MoEBld1HZwdh8SOkQ owAHoxIP70sOsWAh1sSy4srcQ4ySHExKorw+7kAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrwx 2kA53pTEyqrUonyYlDQHi5I4b63FryAhgfTEktTs1NSC1CKYrAwHh5IE7wkPoEbBotT01Iq0 zJwShDQTByfIcB6g4XNBaniLCxJzizPTIfKnGBWlxHknglwkAJLIKM2D64UlkleM4kCvCPNe B2nnASYhuO5XQIOZgAb3gF1dXJKIkJJqYEwtWnGllmOnZuTzTwoSq5k6nmkb35/kH3yBb+sa DxODrMM1vwO0/md8VL5zJ2XVpWkZfiGFO6+nrl+hxNTHWPprfWJY+g2FVclnH585+zFEc46/ 8XyL3IPSDKu1rBO5C1aft6jMbj/btWbzytDqW9c0f201W6buN73okPp7gUXe00SPpCtOZVFi Kc5INNRiLipOBAAnP+Uw/wIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/XE_5fchHo9g28hNH31ymJReu4DE Cc: kitten@ietf.org Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 21:46:16 -0000 On Tue, 4 Mar 2014, Jeffrey Hutzelman wrote: > We probably don't actually need to publish a document; it ought to be > sufficient to point out to IANA that there is a conflict and ask that > the relevant numbers be marked reserved. I ought to be, but in practice it appears to not actually be sufficient. Unless you're saying that I should try again? -Ben From nobody Tue Mar 4 13:48:06 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543E61A00FF for ; Tue, 4 Mar 2014 13:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETvlu16-DAxn for ; Tue, 4 Mar 2014 13:47:59 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6E71A0139 for ; Tue, 4 Mar 2014 13:47:59 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s24LlsVB026394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Mar 2014 22:47:54 +0100 (MET) In-Reply-To: To: Benjamin Kaduk Date: Tue, 4 Mar 2014 22:47:54 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140304214754.32AC81AC3B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/OngaQbcLvMsIZbtBc1g_7FIqSfM Cc: kitten@ietf.org Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 21:48:03 -0000 Benjamin Kaduk wrote: > > In particular, the value 0405 from draft-ietf-krb-wg-gssapi-cfx-02 which > was removed before that document became RFC 4121, and the value 0501 from > draft-ietf-kitten-iakerb-00 (now -01), were not added. > > [...] > > To me, this seems like a(nother) bug in RFC 7055, but of course it is not > one that can be reasonably fixed. I guess that the easiest way forward is > to publish a quick document that reserves 0405 and 0501 noting that they > were in use before the registry was established. This should be easily fixed with a small amount of common sense applied by consenting AD & WG chairs, no documents necesssary. As long as we're not facing depletion of the pool, simply marking the code point as "Reserved to avoid conflicts" should be feasible. See the TLS cipher suites registry for comparison: http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 cipher suite code points 0x00, 0x040 through 0x00, 0x60 that are in the "Standards Action" range -Martin From nobody Tue Mar 4 13:55:00 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196001A02D6 for ; Tue, 4 Mar 2014 13:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaFbruqV3rgK for ; Tue, 4 Mar 2014 13:54:55 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id C17F61A02B3 for ; Tue, 4 Mar 2014 13:54:55 -0800 (PST) Received: from mail160-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Tue, 4 Mar 2014 21:54:51 +0000 Received: from mail160-tx2 (localhost [127.0.0.1]) by mail160-tx2-R.bigfish.com (Postfix) with ESMTP id C9D2C4803ED; Tue, 4 Mar 2014 21:54:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.212; KIP:(null); UIP:(null); IPV:NLI; H:cio-krc-pf05; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(z579ehzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h21e4h2216h22d0h2336h2438h2461h2476h2487h24ach24d7h2516h2545h255eh25cch25f6h1b1cn1b1bi1155h) Received-SPF: pass (mail160-tx2: domain of osu.edu designates 164.107.81.212 as permitted sender) client-ip=164.107.81.212; envelope-from=cantor.2@osu.edu; helo=cio-krc-pf05 ; cio-krc-pf05 ; Received: from mail160-tx2 (localhost.localdomain [127.0.0.1]) by mail160-tx2 (MessageSwitch) id 1393970088719892_21793; Tue, 4 Mar 2014 21:54:48 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.235]) by mail160-tx2.bigfish.com (Postfix) with ESMTP id A6FE438006B; Tue, 4 Mar 2014 21:54:48 +0000 (UTC) Received: from cio-krc-pf05 (164.107.81.212) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 4 Mar 2014 21:54:46 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-krc-pf05 (Postfix) with ESMTPS id DB9A46005A; Tue, 4 Mar 2014 16:54:45 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.03.0174.001; Tue, 4 Mar 2014 16:54:45 -0500 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] [TLS] MITM Attacks on Client Authentication after Resumption Thread-Index: AQHPN7cRjDuzOiHFxUOb4nSlBWlIcprRuKKA///AooA= Date: Tue, 4 Mar 2014 21:54:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.83] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/EnOKeJBnYrcjY8yh_4sSxOmYPac Cc: "kitten@ietf.org" Subject: Re: [kitten] [TLS] MITM Attacks on Client Authentication after Resumption X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 21:54:58 -0000 On 3/4/14, 3:41 PM, "Nico Williams" wrote: >> >> Is it accurate to say that the threat with tls-server-endpoint is more >> like the other cases discussed? > >Yes. We should fix this too. Well, my point is, if the threat model with tls-server-endpoint is that you have to not detect the change in the server certificate, I'm reasonably comfortable with the scope of that issue as it stands now. There may be broken stuff, but it should be fixable broken stuff. "Fixing" that by making it impossible with off the shelf TLS code to do channel binding would definitely not be a step forward. It so happens that the somewhat hacky way I defined channel binding with SAML is, I think, resistant to the cert changing (I'm still trying to determine that for certain), but I do understand there's still an issue there. Just doesn't seem anywhere near as bad as the tls-unique issue. -- Scott From nobody Tue Mar 4 14:17:55 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A606D1A02E6 for ; Tue, 4 Mar 2014 14:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8ImNTa95SzT for ; Tue, 4 Mar 2014 14:17:50 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 02EDC1A0339 for ; Tue, 4 Mar 2014 14:17:49 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s24MHiMb012746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Mar 2014 17:17:44 -0500 Received: from [10.3.113.6] ([10.3.113.6]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s24MHh4i019273; Tue, 4 Mar 2014 17:17:43 -0500 From: Simo Sorce To: Jeffrey Hutzelman In-Reply-To: <1393969466.4395.211.camel@minbar.fac.cs.cmu.edu> References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> <1393968964.22047.99.camel@willson.li.ssimo.org> <1393969466.4395.211.camel@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Tue, 04 Mar 2014 17:17:42 -0500 Message-ID: <1393971462.22047.132.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/PtctpDqohphyV9Qv9juMJW3vmT4 Cc: kitten@ietf.org Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 22:17:52 -0000 On Tue, 2014-03-04 at 16:44 -0500, Jeffrey Hutzelman wrote: > On Tue, 2014-03-04 at 16:36 -0500, Simo Sorce wrote: > > On Tue, 2014-03-04 at 11:49 -0500, Benjamin Kaduk wrote: > > > > > > To me, this seems like a(nother) bug in RFC 7055, but of course it is > > > not one that can be reasonably fixed. I guess that the easiest way > > > forward is to publish a quick document that reserves 0405 and 0501 > > > noting that they were in use before the registry was established. > > > > +1 if there is a registry we must avoid errors in allocations, and > > allocating 0405 or 0501 to something else would definitely cause > > standards issues. > > No, you have it backwards. The registry doesn't create the requirement > to avoid conflicting allocations; it is a tool for helping to meet that > requirement. > > We probably don't actually need to publish a document; it ought to be > sufficient to point out to IANA that there is a conflict and ask that > the relevant numbers be marked reserved. I think we are saying the same thing, I do not care what is the means of getting those numbers marked as reserved as long as it is done and quickly. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Tue Mar 4 19:33:48 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397111A01DC for ; Tue, 4 Mar 2014 19:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EztsyppCtnwY for ; Tue, 4 Mar 2014 19:33:42 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (unknown [69.163.253.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1081A01D2 for ; Tue, 4 Mar 2014 19:33:42 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 1B397428072 for ; Tue, 4 Mar 2014 19:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=JdQCqksylbsQRtTh7/ro Jm9VWow=; b=k8DfI9VzILGZEN91QX5C1rLO22rvKA0fhJslhzMPFaqBUnJRcqcT KiUljVmX4NIrPFtXtL+oU7rTk+vSRMtGD7a9ygTmSKsgemp4kJw5iD/4zBj0lxO2 WdrrH65pq7kLQWqpVBmvPA0QIGhQy0N403NOn/Sv9KrX/59tuo2E7hI= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id C283A428078 for ; Tue, 4 Mar 2014 19:33:38 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id x12so491502wgg.18 for ; Tue, 04 Mar 2014 19:33:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OjBqvcqSRWCRfCfl8QnPUTCpQXDOntK+HDS2jj/zN0E=; b=Rm4gjDOnpkwkdd6Dthoiz4GrYBl7cCyqtnQ9dYyceVe6tYMSXCbKvbyMo1YvOeN+Ik qijd6l3OoQskOruTMa/u3tnZPoTWRkaMswaOCtqVbiKzegP0xdNQ7kwS2LiyFKGYFwbp RZZpRB3TpBfh+L7sHiU5LF8VsUiSTmvWeYpvG4+Jrv8zQqqULHEEzgnZ0dZ7VN55OeNP ZUEZas3ZRFJlWA21WVVGTxtdhabezB0Su9VOeCBVnQcsjVcDH7lc+azFQNcq4iP/IZsy H26XZg4uEOVTVw92xXIF8gdX/RD8BJKUjhzHimbobpj5FYfCir0UXjismKCHJ5eX+X7i owsA== MIME-Version: 1.0 X-Received: by 10.194.57.208 with SMTP id k16mr133917wjq.95.1393990417759; Tue, 04 Mar 2014 19:33:37 -0800 (PST) Received: by 10.217.108.132 with HTTP; Tue, 4 Mar 2014 19:33:37 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Mar 2014 21:33:37 -0600 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/CeT_hhAGBc9ncZV1cx1OdIv0P1o Cc: "kitten@ietf.org" Subject: Re: [kitten] Stepping down as Kitten co-chair sometime after London X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 03:33:43 -0000 On Mon, Mar 3, 2014 at 8:27 AM, Sam Hartman wrote: > There's a lot of exciting stuff going on in the GSS-API world. [...] > > Kitten is not where that work is happening. > We have an interesting challenge to figure out whether the IETF can > serve a role in future GSS-API evolution. If so, we need to make some > significant changes to make it work. If not, then the GSS-API community > should find some place to coordinate activities. Speaking as someone > who is trying to maintain both applications and mechanisms working > across Heimdal, MIT and windows, standardization and coordination has > real value. I hope the world doesn't become more fragmented. I'm not sure why the IETF wouldn't be the place to do this work. The main problem is that we've learned that it is best for standardization to follow running code, and then it becomes an afterthought. I'm thinking that we do need a better solution. The IANA GSS namespace registry is all about having a lower cost method of evolving the GSS-API. Perhaps we could do somewhat better than that, at least for the C bindings. In any case, your and Shawn's co-chairships have been excellent; your leadership will be missed. Thanks! Nico -- From nobody Tue Mar 4 19:36:00 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDDE1A01B6 for ; Tue, 4 Mar 2014 19:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FROM_12LTRDOM=0.1, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSn7HD5iuIsb for ; Tue, 4 Mar 2014 19:35:56 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (agjbgdcfdbhe.dreamhost.com [69.163.253.174]) by ietfa.amsl.com (Postfix) with ESMTP id CB0461A00A6 for ; Tue, 4 Mar 2014 19:35:56 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 6A57976805C for ; Tue, 4 Mar 2014 19:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=96CiACKPqIIF5KzmESbwfxGJRPM=; b=SXBUpJd4kV/ yojfcf2FFlGVbaiRgkiNaoAAVsTXlLpgNw966+KShe/LgfcJGDoK8nztZ+NkFmkY bstaiVmCCzpi+E9gWOzndTpvNAoQQixx6WG/TMxYagkQP7njOKELMGXwgMWZD39w NgbQXXYHzBgwM9Hmm5SSVq6XgRZkLEqg= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 1EDD0768057 for ; Tue, 4 Mar 2014 19:35:52 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id x48so481944wes.7 for ; Tue, 04 Mar 2014 19:35:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=IkQDgNsfoMUZSSLMvJVFIWOErlLud3glAPaRDdjN0Yk=; b=QWThQZq32t6dgLxT+y9z/+uVNMBmm9R/Bk2dMm88fhEk/oJQwDjsMY0Etr4SFn45UE 9CyNhPHQZlJrlUUhLk3XK91NREH9pfnn+4c9+drM9+CldXiSW9NHJLadPofFWWoqs7Yj z1ez6K4HjeFp23UzjWRUjM2NvK+Q3Rzn3V5KjRDJL7DzcmtIrdWHIPCgFHWlWezUM5m7 PYVqAPHr6u3N2kdnfkc/BmSljspedrQvWXv1Xznlc8ApHdwp2Kg28FaM7Te4QMLRvIT4 6dx+Haw/IFNh244pAoD+Vud8G9ftwDw631agXCuxrDtVNxsyOXgO8W5JZtGMCv17yn2M Yrhw== MIME-Version: 1.0 X-Received: by 10.194.57.208 with SMTP id k16mr145171wjq.95.1393990552125; Tue, 04 Mar 2014 19:35:52 -0800 (PST) Received: by 10.217.108.132 with HTTP; Tue, 4 Mar 2014 19:35:52 -0800 (PST) Date: Tue, 4 Mar 2014 21:35:52 -0600 Message-ID: From: Nico Williams To: "kitten@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/nNNgJMjO3r4bSPqUU6coA92fDDw Subject: [kitten] New I-Ds X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 03:35:58 -0000 - An I-D on using naming attributes to implement a better S4U2Proxy: http://tools.ietf.org/html/draft-williams-kitten-impersonation-naming-attr-00 - An I-D on the use of wildcard A/AAAA RRsets in the DNS to implement per-user services. http://tools.ietf.org/html/draft-dukhovni-using-wildcard-a-rrsets-00 Nico -- From nobody Wed Mar 5 06:23:23 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341281A020E for ; Wed, 5 Mar 2014 06:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QkzsND-JIIC for ; Wed, 5 Mar 2014 06:23:17 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id E91911A01F6 for ; Wed, 5 Mar 2014 06:23:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 5D7A5206AA; Wed, 5 Mar 2014 09:18:44 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rz2KjJmE54Er; Wed, 5 Mar 2014 09:18:42 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [130.129.155.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 5 Mar 2014 09:18:42 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0987C83F00; Wed, 5 Mar 2014 09:23:09 -0500 (EST) From: Sam Hartman To: Benjamin Kaduk References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> Date: Wed, 05 Mar 2014 09:23:08 -0500 In-Reply-To: (Benjamin Kaduk's message of "Tue, 4 Mar 2014 11:49:50 -0500 (EST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/VqC-_fKVkL0rmfq0O3hABPeMxd8 Cc: kitten@ietf.org Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 14:23:19 -0000 >>>>> "Benjamin" == Benjamin Kaduk writes: Benjamin> To me, this seems like a(nother) bug in RFC 7055, but of Benjamin> course it is not one that can be reasonably fixed. I Benjamin> guess that the easiest way forward is to publish a quick Benjamin> document that reserves 0405 and 0501 noting that they were Benjamin> in use before the registry was established. I do not support reserving the iakerb value in another document. The right solution there is to finish iakerb and get it published. my preference is that the CFX context deletion token not be registered. I don't see any protocol issues that are likely to result if that code point were re-used. If the community disagrees, writing a document is the right way forward. Yes, as expert, I could have done something else. I just think it would have been the wrong choice. From nobody Wed Mar 5 06:59:27 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175E21A0713 for ; Wed, 5 Mar 2014 06:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqyqQ-84uJFs for ; Wed, 5 Mar 2014 06:59:23 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (smtp01.srv.cs.cmu.edu [128.2.217.200]) by ietfa.amsl.com (Postfix) with ESMTP id CB44C1A0527 for ; Wed, 5 Mar 2014 06:59:22 -0800 (PST) Received: from [192.168.202.157] (pool-108-39-221-65.pitbpa.fios.verizon.net [108.39.221.65]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s25ExGCd003717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 5 Mar 2014 09:59:17 -0500 (EST) Message-ID: <1394031556.4290.53.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Sam Hartman Date: Wed, 05 Mar 2014 09:59:16 -0500 In-Reply-To: References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.200 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/et5MINB24z8IbJlEVB9sm9BZ0I8 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 14:59:26 -0000 On Wed, 2014-03-05 at 09:23 -0500, Sam Hartman wrote: > >>>>> "Benjamin" == Benjamin Kaduk writes: > > > Benjamin> To me, this seems like a(nother) bug in RFC 7055, but of > Benjamin> course it is not one that can be reasonably fixed. I > Benjamin> guess that the easiest way forward is to publish a quick > Benjamin> document that reserves 0405 and 0501 noting that they were > Benjamin> in use before the registry was established. > > I do not support reserving the iakerb value in another document. > The right solution there is to finish iakerb and get it published. Agreed. For better or worse, our process generally allocates values on publication, not when a spec first appears that needs one. The right way to avoid conflicts here is for the iakerb document to say "TBA" until a value is assigned by IANA, and to mention this in its IANA considerations section. > my preference is that the CFX context deletion token not be registered. > I don't see any protocol issues that are likely to result if that code > point were re-used. > If the community disagrees, writing a document is the right way forward. I think that depends on how mechanisms might get stacked and whether there is deployed code that emits or reacts to that code point. In general, tokens used only during context establishment almost don't need to be in a common namespace at all, except that it makes it less complicated to update things when one mech builds on the context establishment of another. However, tokens which can appear after context establishment require a little more care (but are also less likely to appear or change outside of 4121 or its successors). In this particular case, I don't feel like I'm in a position to develop an opinion on whether the code points needs to be reserved, because I don't know what the existing implementation does with it. Here, we're talking about a code point used in a document which was in progress and then abandoned or superseded before the registry was created; thus, it never appeared in any published protocol specification. If we're concerned that use of such a code point might cause interop problems, then having marked it as reserved in the initial registry would have been a fine thing to do, and there is ample precedent for that. If it didn't, and we consider that an oversight, then it seems to me that publication of a new IETF-reviewed RFC is a rather heavyweight process to correct the oversight. -- Jeff From nobody Wed Mar 5 10:16:27 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EE41A0052 for ; Wed, 5 Mar 2014 10:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.655 X-Spam-Level: X-Spam-Status: No, score=0.655 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wd7Lrldq3e6V for ; Wed, 5 Mar 2014 10:16:23 -0800 (PST) Received: from nm14-vm1.bullet.mail.bf1.yahoo.com (nm14-vm1.bullet.mail.bf1.yahoo.com [98.139.213.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3388C1A013A for ; Wed, 5 Mar 2014 10:16:23 -0800 (PST) Received: from [98.139.214.32] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 05 Mar 2014 18:16:19 -0000 Received: from [98.139.212.205] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 05 Mar 2014 18:16:19 -0000 Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 05 Mar 2014 18:16:19 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 319305.3651.bm@omp1014.mail.bf1.yahoo.com Received: (qmail 67342 invoked by uid 60001); 5 Mar 2014 18:16:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394043379; bh=VlXswAzJkjpKa6HIvezUO6fSAfE/K5kXRtJJI4zZQC4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=GNSRFi6Sma8KT0OjZW92OczSMxS0qauSkOlE2wjMbr0/IX2dxSno3DsteIiTsNZzq6gMDkdJK+HwlZWhajKMZBVqbDRZzrTH5ocf8y5vU9Ms4jfynitMBOjRmhDuPUj3yJ7cTDD+CztdtuSIDlZldtqHEqktw0nzmSnRQHQYcZA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=stVVJ7JjeOl6hSKtMVdTzAyw3nhiCT5TQZSDZsKysWKjufYBSeeARjOpSUK9Rk9iwaKnoCDHAiNRPAYEoDKReItevaU4x8+KXL9vvxNq7/Svd60MjyHZ1WkmU50H5Ws26HwrZF2n69JRJKrbcmi2XARI9BR07csCMs6nESP1Azk=; X-YMail-OSG: JmLNxoQVM1lNvUfcU_9Zb.w82BVy6U5jUqjFmBy36RY7qec VrpqzOF94wc5kA_fVqabFzz12ouyPvhA4ZKqBcYY4K2mD_JtG4Mb3Fv7yCp4 wGO1LAIYqU7tbYzkT7.zh6lnx5K.U.s.UI0MTXBRLYZik.FHmu2_oDxY3CPo LO6DIcOxHyoRwllDF6DLW4sKz3mAbuQpf_5wu9ayWho7icdG0Kw.92zfVzF_ OO3s6Uw1Jiew2KtydaYuVP9LzOBoxa3SIrd7BxMdHdq8TeL91yTaKKfQBtQR Hk15gIw03EawOrQYakzkHOZuMKcInnLvYzbsNwLTkt5XuAcCvI4fkhLjnUhe TZhkpKLEAxtugxQC__BDNy4iBrFNGdXJtgQF2kKgd2cBkg0KGfo5PrJu9MBk Yb7WLzT8Kd1Eu8.Mk4vkYiN9xOd6I4f_W54Z9tmVpFMkckoKFQ22jF17H15x oSZmQxICljL_plC1KZly8ZRDsdDE7abt2u8pgVsMRkxGqw1aM7gY6FP1UivG y4VSdMO2eJ4DYufkyd2LNqguIbdy43CJ2TEJuiqRCBvJtvXh0zaacz6GeRkK wqp2NLYtDc0mzi8F. Received: from [217.36.79.41] by web142804.mail.bf1.yahoo.com via HTTP; Wed, 05 Mar 2014 10:16:19 PST X-Rocket-MIMEInfo: 002.001, SSBjYW4gY29tZSBiYWNrIG92ZXIgdG8gdGhlIEhpbHRvbiBvciBtZWV0IHVwIHNvbWV3aGVyZS4KCi1iaWxsATABAQEB X-Mailer: YahooMailWebService/0.8.177.636 Message-ID: <1394043379.77960.YahooMailNeo@web142804.mail.bf1.yahoo.com> Date: Wed, 5 Mar 2014 10:16:19 -0800 (PST) From: Bill Mills To: "kitten@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2129327256-1233741077-1394043379=:77960" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Y6N1KcNaNN_-FttdiH3MtqyaJhU Subject: [kitten] Dinner anyone? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 18:16:25 -0000 ---2129327256-1233741077-1394043379=:77960 Content-Type: text/plain; charset=us-ascii I can come back over to the Hilton or meet up somewhere. -bill ---2129327256-1233741077-1394043379=:77960 Content-Type: text/html; charset=us-ascii
I can come back over to the Hilton or meet up somewhere.

-bill
---2129327256-1233741077-1394043379=:77960-- From nobody Wed Mar 5 16:12:42 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F08C1A0005 for ; Wed, 5 Mar 2014 16:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi1lIjDl9f_3 for ; Wed, 5 Mar 2014 16:12:36 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 34FF51A000E for ; Wed, 5 Mar 2014 16:12:36 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s260CVh8014658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 6 Mar 2014 00:12:32 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s260CUA1002267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Mar 2014 00:12:31 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s260CUVL011401 for ; Thu, 6 Mar 2014 00:12:30 GMT Received: from dhcp-a4a7.meeting.ietf.org (/10.175.4.246) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 Mar 2014 16:12:30 -0800 Message-ID: <5317BD6E.6080309@oracle.com> Date: Wed, 05 Mar 2014 17:12:30 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: kitten@ietf.org References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> <1394031556.4290.53.camel@destiny.pc.cs.cmu.edu> In-Reply-To: <1394031556.4290.53.camel@destiny.pc.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/cHsmVFb-NTF0CSP1D6w1DfTyAmA Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 00:12:38 -0000 On 3/5/14 7:59 AM, Jeffrey Hutzelman wrote: > On Wed, 2014-03-05 at 09:23 -0500, Sam Hartman wrote: >>>>>>> "Benjamin" == Benjamin Kaduk writes: >> >> Benjamin> To me, this seems like a(nother) bug in RFC 7055, but of >> Benjamin> course it is not one that can be reasonably fixed. I >> Benjamin> guess that the easiest way forward is to publish a quick >> Benjamin> document that reserves 0405 and 0501 noting that they were >> Benjamin> in use before the registry was established. >> >> I do not support reserving the iakerb value in another document. >> The right solution there is to finish iakerb and get it published. > Agreed. For better or worse, our process generally allocates values on > publication, not when a spec first appears that needs one. The right > way to avoid conflicts here is for the iakerb document to say "TBA" > until a value is assigned by IANA, and to mention this in its IANA > considerations section. Speaking as an individual; I agree, but having some guidance would be helpful, as there may be a pattern in the registry that might not be intuitive to IANA. >> my preference is that the CFX context deletion token not be registered. >> I don't see any protocol issues that are likely to result if that code >> point were re-used. >> If the community disagrees, writing a document is the right way forward. > I think that depends on how mechanisms might get stacked and whether > there is deployed code that emits or reacts to that code point. In > general, tokens used only during context establishment almost don't need > to be in a common namespace at all, except that it makes it less > complicated to update things when one mech builds on the context > establishment of another. However, tokens which can appear after > context establishment require a little more care (but are also less > likely to appear or change outside of 4121 or its successors). > > In this particular case, I don't feel like I'm in a position to develop > an opinion on whether the code points needs to be reserved, because I > don't know what the existing implementation does with it. Implementers could interpret text from 2743 as requiring a token that is emitted for deleting security contexts: Optionally, the server-side application may provide a token buffer to GSS_Delete_sec_context(), to receive a context_token to be transferred to the client in order to request that client-side context-level information be deleted. > Here, we're talking about a code point used in a document which was in > progress and then abandoned or superseded before the registry was > created; thus, it never appeared in any published protocol > specification. If we're concerned that use of such a code point might > cause interop problems, then having marked it as reserved in the initial > registry would have been a fine thing to do, and there is ample > precedent for that. If it didn't, and we consider that an oversight, > then it seems to me that publication of a new IETF-reviewed RFC is a > rather heavyweight process to correct the oversight. Shawn. -- From nobody Wed Mar 5 16:41:30 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8BA1A0004 for ; Wed, 5 Mar 2014 16:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3wrDOA-N_e8 for ; Wed, 5 Mar 2014 16:41:27 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id B616E1A0010 for ; Wed, 5 Mar 2014 16:41:26 -0800 (PST) X-AuditID: 12074423-f79726d000000cc9-c6-5317c432b1dc Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id AA.E0.03273.234C7135; Wed, 5 Mar 2014 19:41:22 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s260fMUO005696 for ; Wed, 5 Mar 2014 19:41:22 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s260fKfZ024226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 5 Mar 2014 19:41:22 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s260fK3m021837; Wed, 5 Mar 2014 19:41:20 -0500 (EST) Date: Wed, 5 Mar 2014 19:41:20 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <5317BD6E.6080309@oracle.com> Message-ID: References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> <1394031556.4290.53.camel@destiny.pc.cs.cmu.edu> <5317BD6E.6080309@oracle.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsUixG6nrmt0RDzY4NB+E4ujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr421LZMFlqYqFL5uYGxhniHYxcnJICJhIPN5+mxHCFpO4cG89 WxcjF4eQwGwmidcb5zJCOMcYJdoW32KBcK4zSfx5+YAJpEVIoF5iz8MpLCA2i4CWROPHjWCj 2ARUJGa+2cgGYosICEvs3vqOuYuRg0NYwFli464IkDAnUHnHz2lMIGFeAQeJw21uEOO/M0nc Pf0NbLyogI7E6v0Q43kFBCVOznwCZjMLWEr8W/uLdQKjwCwkqVlIUgsYmVYxyqbkVunmJmbm FKcm6xYnJ+blpRbpmunlZpbopaaUbmIEh56L8g7GPweVDjEKcDAq8fBu8BMPFmJNLCuuzD3E KMnBpCTKq30YKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE9/wBoBxvSmJlVWpRPkxKmoNFSZy3 1uJXkJBAemJJanZqakFqEUxWhoNDSYJX5iBQo2BRanpqRVpmTglCmomDE2Q4D9BwfpDFvMUF ibnFmekQ+VOMilLivD8OASUEQBIZpXlwvbDU8IpRHOgVYd47IFU8wLQC1/0KaDAT0OBoPrDB JYkIKakGRrWjrUqXu/2ZZz9/bnFld/IKzVsW1yKuV3uI/Ft1Q2LZf8F+Fe87Z8/Z1MRpMTnL md5tZYjUfPHLI/h+cXx468yGvp13yrtsuMoES7zmfpDfl9yUt+SH1muOfx41v/81zCv88OlY hX5weZB/TdYn65M34pbnLvhz9EjQnbtnfz2deITzQIPJEyWW4oxEQy3mouJEAA1b7KXoAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/TL2KR2vtVZav1r7kFcpB0T66mZc Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 00:41:29 -0000 On Wed, 5 Mar 2014, Shawn M Emery wrote: > On 3/5/14 7:59 AM, Jeffrey Hutzelman wrote: >> On Wed, 2014-03-05 at 09:23 -0500, Sam Hartman wrote: >>> >>> I do not support reserving the iakerb value in another document. >>> The right solution there is to finish iakerb and get it published. >> Agreed. For better or worse, our process generally allocates values on >> publication, not when a spec first appears that needs one. The right >> way to avoid conflicts here is for the iakerb document to say "TBA" >> until a value is assigned by IANA, and to mention this in its IANA >> considerations section. For future allocation of values, leaving it TBA until a value is assigned by IANA is absolutely the right thing to do. I am concerned only with values that were already in use prior to the establishment of the registry. >> In this particular case, I don't feel like I'm in a position to develop >> an opinion on whether the code points needs to be reserved, because I >> don't know what the existing implementation does with it. It has been many months since I looked at the MIT code in question, but I am absolutely confident that we do process tokens that we receive, which use these values. I did end up looking a little bit, again; more below. > Implementers could interpret text from 2743 as requiring a token that is > emitted for deleting security contexts: > > Optionally, the server-side application may provide a token buffer to > GSS_Delete_sec_context(), to receive a context_token to be transferred to > the client in > order to request that client-side context-level information be deleted. If a buffer is provided, I think (but would have to reread to be sure) that the GSS-API library is required to produce a token. We recommend that applications neither provide a buffer nor send such tokens, of course, but not all applications heed the recommendation. >> Here, we're talking about a code point used in a document which was in >> progress and then abandoned or superseded before the registry was >> created; thus, it never appeared in any published protocol >> specification. If we're concerned that use of such a code point might >> cause interop problems, then having marked it as reserved in the initial >> registry would have been a fine thing to do, and there is ample >> precedent for that. If it didn't, and we consider that an oversight, >> then it seems to me that publication of a new IETF-reviewed RFC is a >> rather heavyweight process to correct the oversight. It never appeared in any published protocol specification, but both of these code points have appeared in shipping code, and we have no way of updating all the existing deployments. Doing a little poking in the source, it looks like MIT krb5 probably does emit tokens of type 0x0405 when asked to produce context deletion tokens. (I will try to look at what bits are actually produced, just to be sure, at some point.) Similarly, the MIT krb5 IAKERB implementation is using 0x0501 for the tokens it produces. Given that IAKERB has been in the MIT krb5 tree since 2010, and the context deletion tokens since 2009, I think it would be irresponsible to leave these code points open in the registry. I don't really care what mechanism we use to modify the registry (but of course less effort is nice). -Ben From nobody Wed Mar 5 22:10:23 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178671A00CB for ; Wed, 5 Mar 2014 22:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arT-1hpebsK8 for ; Wed, 5 Mar 2014 22:10:18 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (agjbgdcfdbid.dreamhost.com [69.163.253.183]) by ietfa.amsl.com (Postfix) with ESMTP id EC14B1A00B9 for ; Wed, 5 Mar 2014 22:10:17 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 2B219264060 for ; Wed, 5 Mar 2014 22:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=F4K8tedOJU/S9B4JiX5X Xj5v5vY=; b=BDTz8kC7y+cfx+fB6YNo7dkGetV6HhdwsqTw1WBUJLLq9zL/Iyn2 Bdh0VlogIAqBb1yB/zJCR4X29G/E9gdZDqrf362Gs0di7Q7tRmmSfFOY+69jdA/L /YuJjgDKPYgseq0hY8z0V2HnpVSZPVbtOFu2l3mT46cTH23nS9JWF1E= Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id D1415264059 for ; Wed, 5 Mar 2014 22:10:13 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id n12so2539619wgh.0 for ; Wed, 05 Mar 2014 22:10:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MHTRaYYcId+/joE8MzAyGrLsh0/eMgYVFl4U7GuFkQQ=; b=QJH3M7vaVBsHJtr9BVSv88vhFOqUEU2bJ2x6d/+bcTr6q9VnsZT5x9ZJGHDgvA1/AQ C+9wrSVICjrlx6OfVEJjqb0tLA9I36jVenBae5ewcjEtbBkKS+pA+ZxsXI3xKdIAGdP3 SYaHbpD2gIWxGVsipE34YpPY1MOAP7bT1mDi1bLKS8CUrjvQd5p4WoTBvsb7h3K41QPw akTt7Zo3eASliWPnC24frWPnkRlY5lNUwgUYWmEcDM+aWRCYf/z30U0XfauMdkwrBv4S DawI4YQL55rERHDGzE03o79Gq0IsYSnFrrS0oSOXXnDKo2BKLTTiLgYu+2NLtwgKRuHE B3fA== MIME-Version: 1.0 X-Received: by 10.194.85.168 with SMTP id i8mr6744074wjz.81.1394086212521; Wed, 05 Mar 2014 22:10:12 -0800 (PST) Received: by 10.216.199.6 with HTTP; Wed, 5 Mar 2014 22:10:12 -0800 (PST) In-Reply-To: <87ob1n5t7f.fsf@latte.josefsson.org> References: <87ob1n5t7f.fsf@latte.josefsson.org> Date: Thu, 6 Mar 2014 00:10:12 -0600 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/TGSY932FW5pWjahQD-WqgRa-tB4 Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC5801bis: relaxing GS2 requirements X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 06:10:20 -0000 On Mon, Mar 3, 2014 at 7:04 AM, Simon Josefsson wrote: > I've prepared a new version of RFC 5801 to get the GS2bis ball rolling. Thank you, and thanks for posting the diff URL, it made it very easy to review your changes. I'm very much in favor of this revision. I have only agreement and nits to contribute (spelling and number agreement corrections). > The problem is that RFC 6595 (SAML), RFC 6616 (OpenID) and the OAuth > SASL mechanism does not really meet the GS2 requirements: in particular, > they don't offer channel bindings or mutual authentication. Or more > generically stated, the problem was that we hoped that all future > authentication mechanisms would provide channel binding and mutual > authentication, and as a result GS2 was too narrowly defined. Yes, we had so hoped. As a result we made GS2's scope too narrow indeed. > [...] But the problem is > really with GS2, so the fix should go into GS2. Agreed. > As you can see, I've only added one section describing the problem and > some new MUST wording. Clearly, this is not sufficient, and other > sections must be modified, in particular the security considerations. Indeed. For example, we must say that a client that could pick a -PLUS offered by a server SHOULD take it, no? And/or we should explain that it should only take a non-PLUS GS2 mechanism (or non-GS2 mechanism with similar properties) when TLS (or similar) was used to authenticate the server to the client's satisfaction. I don't think there's much we can do to characterize the security of using a mechanism with channel binding and mutual authentication versus TLS and a mechanism that does not provide mutual auth and/or channel binding. To do more than hand-wave we'd have to get into the specifics of the mechanism and the TLS server authentication functionality and PKI and so on. All we should say is that if the client doesn't use a -PLUS mechanism with channel binding then it must have used TLS with a ciphersuite that authenticates the server to the client, and that it must do so to the client's satisfaction, whatever that might mean. > Before doing that, I think it would be good to get the WG to think about > this issue and see that the overall idea is acceptable. I can't say > that I like the text, but I think it is a compromise that will result in > better hormonization of GSS-API and SASL, and I have struggled to come > up with anything better. I'm in favor of this change. Nico -- From nobody Thu Mar 6 02:20:31 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B221A022F for ; Thu, 6 Mar 2014 02:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl26XVLr4ZvC for ; Thu, 6 Mar 2014 02:20:29 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id E87091A0220 for ; Thu, 6 Mar 2014 02:20:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 39643206AA; Thu, 6 Mar 2014 05:15:55 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvWZGnC_JWSX; Thu, 6 Mar 2014 05:15:55 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [130.129.155.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 6 Mar 2014 05:15:51 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F40FB83F8E; Thu, 6 Mar 2014 05:20:19 -0500 (EST) From: Sam Hartman To: Benjamin Kaduk References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> <1394031556.4290.53.camel@destiny.pc.cs.cmu.edu> <5317BD6E.6080309@oracle.com> Date: Thu, 06 Mar 2014 05:20:19 -0500 In-Reply-To: (Benjamin Kaduk's message of "Wed, 5 Mar 2014 19:41:20 -0500 (EST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/4yCoWrrtJOaXDNCmLhw4y0Utt-g Cc: kitten@ietf.org Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 10:20:30 -0000 So, my understanding of the situation is that we have an implementation that has chosen to ship code prior to completion of a spec in two instances. 1) CFX. In that instance, the spec evolved differently than anticipated and no longer standardizes the behavior MIT implements. 2) Iakerb. There, we still expect that the spec will use the same value as MIT. In the CFX case, I don't actually see any significant harm that would result if we were to assign the codepoint MIT uses to something else. It would be bad if we assigned that codepoint to some token other than a context deletion token intended to be passed into gss_process_context_token. However, there are no such tokens and there are no extensions under discussion that would create such tokens. In general, when you ship a draft, you take on responsibility for dealing if the IETF process doesn't go the way you anticipate. Doing that is part of doing business; it's definitely the case that there are times when you end up shipping based on drafts. I'm aware of the iakerb issue, and if iakerb moves forward at a reasonable speed, I'll certainly keep its assignment preference in mind when reviewing other allocations. IANA expert decisions can be appealed; you'd first file an appeal with me, and then I'm not sure whether it goes to the IESG as a whole or the security AD. From nobody Thu Mar 6 07:30:55 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AEB1A0064 for ; Thu, 6 Mar 2014 07:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul1zZtuGe-U7 for ; Thu, 6 Mar 2014 07:30:51 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADD11A00DD for ; Thu, 6 Mar 2014 07:30:33 -0800 (PST) X-AuditID: 12074423-f79726d000000cc9-8f-53189494b64a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id E2.91.03273.59498135; Thu, 6 Mar 2014 10:30:29 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s26FUSTT013949 for ; Thu, 6 Mar 2014 10:30:28 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s26FUQ7M009213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 6 Mar 2014 10:30:28 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s26FUQ9g013532; Thu, 6 Mar 2014 10:30:26 -0500 (EST) Date: Thu, 6 Mar 2014 10:30:26 -0500 (EST) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <53011405.4050904@mit.edu> Message-ID: References: <53011405.4050904@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixG6nrjt1ikSwwc9NrBZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrMXO5gLFjBWfPzzk7GBsaaLkZNDQsBE4uvmTnYIW0ziwr31 bF2MXBxCArOZJI6vf8II4RxjlHj3ex0rhHOdSeJUcxcjSIuQQL1Ez4evLCA2i4CWxJQZD8Bs NgEViZlvNrKB2CICwhK7t75jBrGFBWwllmzYyARicwqoS5z5/RsszivgIDGxdSrUTB+Jz9Pa wWxRAR2J1funsEDUCEqcnPkEzGYWsJQ49+c62wRGgVlIUrOQpBYwMq1ilE3JrdLNTczMKU5N 1i1OTszLSy3SNdPLzSzRS00p3cQIDj4X5R2Mfw4qHWIU4GBU4uHd4CceLMSaWFZcmXuIUZKD SUmU13eSRLAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV7ZaqAcb0piZVVqUT5MSpqDRUmct9bi V5CQQHpiSWp2ampBahFMVoaDQ0mC99BkoEbBotT01Iq0zJwShDQTByfIcB6g4Uogi3mLCxJz izPTIfKnGHU5bq/++YlRiCUvPy9VSpx3CsggAZCijNI8uDmwpPGKURzoLWHe4yBVPMCEAzfp FdASJqAl0XziIEtKEhFSUg2MJ3aUrM7o4zs1sS1xzR7hjpBW09tm5aH1fv/b+d4+OChgzvBY 5X7s+k/1EekOPo73JI/kTWBuMG+fd1zLYfdU9Xjuwx41y8JrOc+KXAm58PewaTDX5Skzm8Kf /H6f2xWavTV9bt9pFYeteVqKLravvxRZ9qrv9Vpym2Utc+SSFAnX0z93PFipxFKckWioxVxU nAgAldEM9vUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/AzuNWBFt9Fj2E7ljIJfY3vum9fE Subject: Re: [kitten] Comments on draft-ietf-kitten-iakerb-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:30:52 -0000 I read the new document, but don't have any comments to add that have not already been made. (I believe I made some editorial comments on the -00.) -Ben From nobody Thu Mar 6 11:18:10 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F3A1A01A7; Thu, 6 Mar 2014 11:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKMllyaarnUR; Thu, 6 Mar 2014 11:17:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 234D71A00B4; Thu, 6 Mar 2014 11:17:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140306191754.7684.35519.idtracker@ietfa.amsl.com> Date: Thu, 06 Mar 2014 11:17:54 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/gwQ3tJ8AJDUlSPwFolFS5fAxAu4 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-14.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 19:17:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : A set of SASL Mechanisms for OAuth Authors : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-14.txt Pages : 20 Date : 2014-03-06 Abstract: OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP- based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 6 14:51:23 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC441A011E for ; Thu, 6 Mar 2014 14:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZ3U77o2M2uz for ; Thu, 6 Mar 2014 14:51:20 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 712651A00AF for ; Thu, 6 Mar 2014 14:51:20 -0800 (PST) X-AuditID: 12074425-f79906d000000cf9-4c-5318fbe433ff Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id F4.1B.03321.4EBF8135; Thu, 6 Mar 2014 17:51:16 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s26MpEsb011924; Thu, 6 Mar 2014 17:51:15 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s26MpCUj005811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Mar 2014 17:51:14 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s26MpCcI009571; Thu, 6 Mar 2014 17:51:12 -0500 (EST) Date: Thu, 6 Mar 2014 17:51:12 -0500 (EST) From: Benjamin Kaduk To: Sam Hartman In-Reply-To: Message-ID: References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> <1394031556.4290.53.camel@destiny.pc.cs.cmu.edu> <5317BD6E.6080309@oracle.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrfvkt0Swwd0HbBZf24DE0c2rWByY PJYs+cnksXLqafYApigum5TUnMyy1CJ9uwSujJuPrrMWTBWuWPR3E2sD4wT+LkZODgkBE4m3 LefZIWwxiQv31rN1MXJxCAnMZpK4N2E+C4SzgVHi2NanjBDOQSaJ3cfPs4G0CAnUSyzau4UR xGYR0JLo/fIIzGYTUJGY+WYjWI2IgLpE+4SvYDazgLDE+nMzmLsYOTiEBZwlNu6KAAlzCqhJ fNn0D6yVV8BBYsvW1ewQu44xSyxvm8kEkhAV0JFYvX8KC0SRoMTJmU9YIGZaSvxb+4t1AqPg LCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFula6OVmluilppRuYgSFKruL6g7GCYeU DjEKcDAq8fB2LpIIFmJNLCuuzD3EKMnBpCTK++gnUIgvKT+lMiOxOCO+qDQntfgQowQHs5II r/93oBxvSmJlVWpRPkxKmoNFSZy37yxQSiA9sSQ1OzW1ILUIJivDwaEkwasOjEkhwaLU9NSK tMycEoQ0EwcnyHAeoOGxv0CGFxck5hZnpkPkTzEqSonz2oEkBEASGaV5cL2wVPKKURzoFWFe eZAVPMA0BNf9CmgwE9DgaD5xkMEliQgpqQZGf/0br9b4KcWefParQH3X15b33GZGVey2efYz 5UwZl6tkFDx0jk59wN7sxHdm2a/6LZrSAa3hl7bNPvV8yrSpsSZ+HQf3Tbl2+/d+Z1nFbouT fStY72Y8VJi/Snf2+ad6F9+6dT7KWz2vKejS/l1CifrWqyyTnl6/b7ZnftB65x1Prn+5vdv8 kRJLcUaioRZzUXEiAC7xZ6QAAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ApRtzEcihmlK7di40gdC7ufVcps Cc: kitten@ietf.org Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 22:51:22 -0000 On Thu, 6 Mar 2014, Sam Hartman wrote: > So, my understanding of the situation is that we have an implementation > that has chosen to ship code prior to completion of a spec in two > instances. > > 1) CFX. In that instance, the spec evolved differently than anticipated > and no longer standardizes the behavior MIT implements. Greg pointed out that we have removed the code that generates the CFX deletion token from our development branch, though of course older releases still generate such tokens. > 2) Iakerb. There, we still expect that the spec will use the same value > as MIT. > > In the CFX case, I don't actually see any significant harm that would > result if we were to assign the codepoint MIT uses to something else. > It would be bad if we assigned that codepoint to some token other than a > context deletion token intended to be passed into > gss_process_context_token. > However, there are no such tokens and there are no extensions under > discussion that would create such tokens. There actually is provision in RFC 2743 for tokens to be passed to gss_process_context_token which are not deletion tokens. (Last two paragraphs of 1.2.1.2.) I do not remember any provisions in RFC 4121 to account for this case, though, so I guess it is under-specified. > In general, when you ship a draft, you take on responsibility for > dealing if the IETF process doesn't go the way you anticipate. Doing > that is part of doing business; it's definitely the case that there are > times when you end up shipping based on drafts. I don't disagree with anything you say there. However, I think we should consider what the purpose of the central registry is: to document what values are in use and avoid conflicts. Given that there were already values in broad use when the registry was created, I think it is appropriate to document those values in the registry, even if it is just as "reserved to avoid conflicts", as Martin notes in the prior art. There certainly does not seem to be a shortage of values in the token type space. > IANA expert decisions can be appealed; you'd first file an appeal with > me, and then I'm not sure whether it goes to the IESG as a whole or the > security AD. Is there a magic phrase that invokes such an appeal? (Or does it go through IANA?) I am unfamiliar with the process, and not necessarily indicating intent to do so. -Ben From nobody Thu Mar 6 15:38:22 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F18A1A0160 for ; Thu, 6 Mar 2014 15:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKRTPoEvlHZW for ; Thu, 6 Mar 2014 15:38:18 -0800 (PST) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFD11A0043 for ; Thu, 6 Mar 2014 15:38:18 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id m5so3285989qaj.7 for ; Thu, 06 Mar 2014 15:38:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WxreFVWtNID/gDFTJ6OpNBdJh2aqd6fKQBmO1oduKl4=; b=XdCadf7Hv1aEWphbQvms8TAsF9E7d72oXWv3mHvXWY18gDp5nl0Gqsb5YwkX96Zqip EQrvQGYVq0D1KLD6Cv+CnBVFpgXxjF3FQxGs0/FND9Hau+h4BhsftZ56GdFYQt4gOEUi F+pi50M5+oGMwrHA6OXv33OR2qJ7ivxGtLFcE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WxreFVWtNID/gDFTJ6OpNBdJh2aqd6fKQBmO1oduKl4=; b=bZOzOMVmUdmC3rvV6FLwvpS0WJx7Bzgmmp9BM6CPDarL4k68bmk0sfX4tPcp2kYaWa YW5Hqv2nlG+6F1u7JBE4JlVkJk6XsRiqEz4pLk89MzVmz3HmHKwQ8r3hNkNWUUpfrsT5 DTxaRG2DH2KkOtvlCuAy//YwKIsVWBDrVwJ0dW4c0D2yqszbg3acA0YPijtEUGZrxKbx XcSLbU4ziH8NJaJuLMpKjmhaZGbKx2jfA7YAJ1cS8yveE7ovVJR293vvpHI2lgYZfdt9 AQuM8meftt2LXBCJ0CUIAE2JDalP2jSsPbDBYOmluG0MYn5U0pxnhW7Qh3QSGpbVrFXh xTsQ== X-Gm-Message-State: ALoCoQnI+7AseHNbQwpbqu3ezilTUTbp3JTaoBQ7jJzbcocl02LDkyTiUO+CnDEYcXa+J9PE7L5lo9BORUZmuZ466bnil7U1lceiBq+10WadS8b2hC17v/2oAHk4hUAaKNxJhlTeS6xhv24miqDw97PVFDy71QSFWLFPkpCjRUoil3trj625xsnapKFoekvdTBl8XN1EqfXM MIME-Version: 1.0 X-Received: by 10.140.100.237 with SMTP id s100mr4408878qge.114.1394149094276; Thu, 06 Mar 2014 15:38:14 -0800 (PST) Received: by 10.229.205.197 with HTTP; Thu, 6 Mar 2014 15:38:14 -0800 (PST) In-Reply-To: <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> Date: Thu, 6 Mar 2014 15:38:14 -0800 Message-ID: From: Ryan Troll To: Bill Mills Content-Type: multipart/alternative; boundary=001a1134eeb887f33204f3f8a134 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/zGltPqbkl85i8mfzvtZo8ztqRDM Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 23:38:20 -0000 --001a1134eeb887f33204f3f8a134 Content-Type: text/plain; charset=UTF-8 Apologies for the delay in responding. I understand this was discussed in today's meeting; and we're going to have a follow-up to discuss further - very reasonable. To answer Bill's original question: user= or a= --> Either works for us. If one has better implications than the other, we'll use it. -R On Tue, Mar 4, 2014 at 7:55 AM, Bill Mills wrote: > > It is not used as a SASL identity. Quoting from -03 and -14 in progress: > "user (REQUIRED): > Contains the user name being authenticated. The server MAY use this as a > routing or database lookup hint. The server MUST NOT use this as > authoritative, the user name MUST be asserted by the OAuth credential." > > Also, looking at the Google API docs for XOAUTH2, they implemented based > on the -03 spec and have the "user=$username" syntax. See > https://developers.google.com/gmail/xoauth2_protocol > > Based on Google's server API and the extant clients they have I'd like to > ask for a consensus call on the following: > > 1) Add the -03 "user" kvpair back into the spec. > > a) YES or b) NO. > > 2) Should we include a GS2 header" > > a) No, let's wait for the GS2 update that deals with things that lack > mutual auth and then write a spec that defines a GS2 header for SASL+OAUTH. > > b) Change the definition of "key" in kvpair to 1*(ALPHA / ","). This > makes a GS2 header followed by a ^A (i.e. "n,a=user@example.com^A") a > valid kvpair which would be ignored by servers that don't understand it. > > c) Define a stub OPTIONAL GS2 header explicitly. > > d) Include a fully defined GS2 header (language from draft -10). > > > My own feedback is 1: YES, 2: a or b. > > -bill > > > -------------------------------- > William J. Mills > "Paranoid" MUX Yahoo! > > > > On Tuesday, March 4, 2014 12:06 AM, Sam Hartman > wrote: > t's discuss Thursday. > I'd like to understand what the user= value signifies and whether it's > actually a SASL authorization identifier. > > I'd like to understand whether there's value in an unprotected SASL > authorization identifier. > > > > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > --001a1134eeb887f33204f3f8a134 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Apologies for the delay in responding.

= I understand this was discussed in today's meeting; and we're going= to have a follow-up to discuss further - very reasonable.

To answer Bill's original question: user=3D or a=3D --> Either = works for us. =C2=A0If one has better implications than the other, we'l= l use it.

-R



On Tue, Mar 4, 2014 at 7:55 AM, Bill Mil= ls <wmills@yahoo-inc.com> wrote:

It is not used as a SASL identity.=C2=A0 Quoting from -03 and -1= 4 in progress:
"user (REQUIRED):

Contains the user name= being=20 authenticated. The server MAY use this as a routing or database lookup=20 hint. The server MUST NOT use this as authoritative, the user name MUST be asserted by the OAuth credential."
=C2=A0
Also, looking at the Google API docs for XOAUTH2, they implemente= d based on the -03 spec and have the "user=3D$username" syntax.= =C2=A0 See https://developers.google.com/gmail/xoauth2_protocol=

Based on Google's server API and the extant clients = they have I'd like to ask for a consensus call on the following:

1) Add the -03 "user" kvpair back = into the spec.

a) YES or b) NO.=C2=A0

2) Should we include a GS2 header"

a) No, let's wait for the GS2 update that deals with things that= lack mutual auth and then write a spec that defines a GS2 header for SASL+= OAUTH.

b) Change the definition of "key" in kvpair to= 1*(ALPHA / ",").=C2=A0 This makes a GS2 header followed by a ^A = (i.e. "n,a=3Duser@exa= mple.com^A") a valid kvpair which would be ignored by servers that= don't understand it.

c) Define a= stub OPTIONAL GS2 header explicitly.

d) Include a fully defined GS2 header (language from draft -10).


My own feedback is 1: YES, 2: a or b.

-bill


----------------------= ----------
William J. Mills
"Paran= oid" MUX Yahoo!



On Tuesday, March 4, 2014 12:06 AM, Sam Hartman <hartmans-ietf@mit.edu> wrote:
t's discuss Thursday.
I'd like to understand what the user=3D value signifies and whether it&= #39;s
actually a SASL authorization identifier.

I'd like to understand whether there's= value in an unprotected SASL
authorization identifier.


<= br clear=3D"none">


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


--001a1134eeb887f33204f3f8a134-- From nobody Thu Mar 6 16:01:31 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FC21A017C for ; Thu, 6 Mar 2014 16:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZffST1eI4L7 for ; Thu, 6 Mar 2014 16:01:29 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (smtp01.srv.cs.cmu.edu [128.2.217.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC561A0160 for ; Thu, 6 Mar 2014 16:01:28 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s2701MCn009056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 6 Mar 2014 19:01:23 -0500 (EST) Message-ID: <1394150482.4395.282.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: kitten@ietf.org Date: Thu, 06 Mar 2014 19:01:22 -0500 In-Reply-To: References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> <1394031556.4290.53.camel@destiny.pc.cs.cmu.edu> <5317BD6E.6080309@oracle.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.200 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/VNXsRWSYYwHH_VSBW3CEgwt7B5k Cc: jhutz@cmu.edu Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:01:31 -0000 On Thu, 2014-03-06 at 17:51 -0500, Benjamin Kaduk wrote: > Is there a magic phrase that invokes such an appeal? (Or does it go > through IANA?) I am unfamiliar with the process, and not necessarily > indicating intent to do so. Sort of. You have to do it intentionally, stating the reason for the appeal and what remedy you want. A chair or AD or really anyone familiar with the process should be happy to help you, if you decide to go that route. Personally, I think there is usually little value in the appeal process while you are having a discussion with the original decision-maker that has not yet converged and does not yet appear not to do so. -- Jeff From nobody Thu Mar 6 16:25:46 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F331A00F1 for ; Thu, 6 Mar 2014 16:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.853 X-Spam-Level: * X-Spam-Status: No, score=1.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, FROM_12LTRDOM=0.1, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id De28iit6tPP0 for ; Thu, 6 Mar 2014 16:25:44 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (unknown [69.163.253.179]) by ietfa.amsl.com (Postfix) with ESMTP id BC1361A00CA for ; Thu, 6 Mar 2014 16:25:44 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id C8EF51DE081 for ; Thu, 6 Mar 2014 16:25:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=xPPNYPcCUpUIhaGsWByNegrEWPk=; b=cxo6Vaj24k/ NJf35NhVEmI2vIk0LDV8GgdiqL+eDp6VC+xSWu15dwsadLHB1WzJbTW9QPbx+IuC Zbovp3oYPAjqMmRLwtXfxzSD3tBel9IRRzSu07ovsaHWqodC0u7iTrjzieU0CLJC 68u3BPdO02AefllnKCCd9h0AieALsQUI= Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 786101DE070 for ; Thu, 6 Mar 2014 16:25:40 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id q58so4057179wes.26 for ; Thu, 06 Mar 2014 16:25:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=oA0S8dCRDs4ChFpEoMZh/adRSugA6LYwx2VmGbm01h0=; b=SQB8sU8qmZu/saQGdOKxl4oxMCzhlkOcZd03Cj6hlGXKR5Hs9kQ8vDNp41ESgikvaE 3rSDsNBEp8wZEuYDuSsjholLNViDI1O2Mi6ALVXVDymxoCljhXYNsVXDH0AIAtvX7C// 9/pauZer9CcHddSUU59F6g0Y7tpyVmsVOy7nv1S1SbT2FwDJY/p2WtYIkfuIVhfGFUJV jCyaP8m86e9fJtcTh5Y2QeqHayG+b7wBer+fKB1QYZadLagisRFB0GRtHwUeIf4UySv4 YEJi08FYi/mzivftAHEpUlvbtxRnXDhozTazUGFVYuj8kfl3hJevssax8bx1nkEfYliI WjUA== MIME-Version: 1.0 X-Received: by 10.194.90.196 with SMTP id by4mr14242280wjb.45.1394151938044; Thu, 06 Mar 2014 16:25:38 -0800 (PST) Received: by 10.216.199.6 with HTTP; Thu, 6 Mar 2014 16:25:38 -0800 (PST) Date: Thu, 6 Mar 2014 18:25:38 -0600 Message-ID: From: Nico Williams To: "kitten@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/TEqXm5kT4M18UdGpKLZMLJl0pvw Subject: [kitten] Our IANA registry allocation policies X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 00:25:46 -0000 should be one of two: - first-come, first-served or - Expert Review Expert Review should be required where namespaces are small or where there is value for the community in having expert review (e.g., to make sure that new GSS C bindings have OM_uint32 *minor_status first arguments). Heavy-duty allocation policies should only be required where we have reason to believe that random allocations could cause others harm (and by this I mean harm other than being pressured to implement anyone's random extensions, I mean harm as in deployment of such an extension breaking interop). I've not looked at all our registries, so I don't have more specific recommendations at this time. It'd help to have consensus on this general recommendation first. Nico -- From nobody Thu Mar 6 18:05:48 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948851A01D5 for ; Thu, 6 Mar 2014 18:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FROM_12LTRDOM=0.1, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24HZVOrwR40S for ; Thu, 6 Mar 2014 18:05:45 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (agjbgdcfdbid.dreamhost.com [69.163.253.183]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC7E1A01D1 for ; Thu, 6 Mar 2014 18:05:45 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 56A4126406A for ; Thu, 6 Mar 2014 18:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=D6OT6+8kU10chIVHeskqMMf2sY0=; b=lQCfe2yd18c wzQn8704z8Lxjhd7j8n0gwWPN3S4qwYtlW/lWK8MZ3QEV4tFj7ZGQYpBrlWGDy9V HVDulGW36ifod+woBhU7MsvEroC8Ga0CqKqLo1oTlDxv/p3DhDjQAfqPXi6phcDI EUP8W2EwR4nDm7iRfu54F0JW5EKSzsJw= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 09BE7264059 for ; Thu, 6 Mar 2014 18:05:40 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id z12so4250035wgg.17 for ; Thu, 06 Mar 2014 18:05:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=gU/Z6ypppjeaGdkJ8DgY/4CvThO2IT8x/AUnmBAaE38=; b=d6Q0D+775P10xmeqZWgGJB7W2VWGSdVOsHb16fEcjCDPJm6i3bO2WK/hlob134SZVI LePOvS1DQQP3DKg3ydSrRimStIvtOyF6m9lfjCpkAfc/1iFBr67xAWwP5IwYlhetup/7 bvL8eBCl1nzLC1sMNOPLpcuX2Dh2hNkxKoMdLipon5CICYCtjBlnN6pRLrTttMsMK1Gf e1g4oxYd+0fOGVszMbRIxsaK2Au/DfuPG18ElIlf1/5o5/Ohqmuj+0WgX65sDSp26eF6 3ut28f4pUFjeULrSBYSvEkkRtlThYFrz5fSZcokGz24vAiuOh/f52a623mg42pHhDkR4 4vvw== MIME-Version: 1.0 X-Received: by 10.194.250.34 with SMTP id yz2mr15183242wjc.18.1394157939753; Thu, 06 Mar 2014 18:05:39 -0800 (PST) Received: by 10.216.199.6 with HTTP; Thu, 6 Mar 2014 18:05:39 -0800 (PST) Date: Thu, 6 Mar 2014 20:05:39 -0600 Message-ID: From: Nico Williams To: "kitten@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/3Z20Q4I0XBuT3nhzz4HwXrb7FWI Subject: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 02:05:47 -0000 Q: What is it? It is: My answer, as I understand it the authzid is: - an advisory, application-specific value sent by the client inside the SASL mechanism's messages (i.e., protected by the mechanism, if the mechanism can do it) and - notionally it's the name of a resource (user account, mailbox, ...) that the client wants to access or access things as. Q: Why do we care about fitting things into the authzid? My answer: because we don't want mechanisms to force new _required_ input elements on existing SASL APIs. Someone please disabuse me of the above. Nico -- From nobody Thu Mar 6 23:16:32 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FD71A0239 for ; Thu, 6 Mar 2014 23:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpKuJfp-CSCa for ; Thu, 6 Mar 2014 23:16:28 -0800 (PST) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id E03FA1A01F3 for ; Thu, 6 Mar 2014 23:16:27 -0800 (PST) Received: from [98.139.212.150] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 07:16:23 -0000 Received: from [98.139.212.208] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 07:16:23 -0000 Received: from [127.0.0.1] by omp1017.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 07:16:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 530236.13823.bm@omp1017.mail.bf1.yahoo.com Received: (qmail 91368 invoked by uid 60001); 7 Mar 2014 07:16:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394176583; bh=Co4FeHEfFGa+dg7Qd4Fcv1nKAsTCZen3ADTXXF0ai9U=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=0WkAbE2yIzhyIKKpwr8xl4IF5fAED+dDZfmI+NQUXOfiWRDdZS07fLrEelr/MbGdRnklgzKYuWE1hpMqsj0oFWZigHg/R7KOIyaoMOEC94UswWFPnYoXi9d7UOCarLVK85o4CFruqYIfArUA2pNy/AXdeln+3pL0lFrkVK8ptEE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=003jd16ZRo4V/iCu/JyIkOSnx05tkcDRVUM0hSIrqQ6NOc7uDrAc3NbP3+rxKjSIXP3CZdmpHuMF9Cxiss2gp1RrvPcSquMidhH31NnfPiqFr/DHqZIKnoNwNtBISXwf+ikBQoh8xdgQ9VaMYcLrpiZ8Eq0MXiXtuNKSKFbQEA0=; X-YMail-OSG: c2JKLoYVM1nHc3ipMWjCP4lDZNR_pKW4GoUrRC9E00rPzDC cRZumfkqXiQdnvgPg4o3vJJthy2iPFXuHpq0xcXmwHXKQaz388QOtLGt3IfH fA5C27gd2GWnCAuuLmaos6k4bw5vg_UtJVkqs.mWL.1oee_njI6phdUqOInG u7Mmkt97RDP1.dEmx9A3zBI_zS0Tj9PVEw52E0enye1u3KojdDo8xTgGIZ_t QK0ZLyFTFt1zYeuI4uOSnxL9m2Sh7UPWNI67kFuNktnb4riYtOHEi3SITX74 lH95OlZPTJlqk39.jJiwMqBk1CEXJHEINoELthSS11uFfB2RIH9f_pZg923D L90zhDGh3d7NcXpyoW8Ca4VsK.5J0l9WKUL4iHD3K2RhHoqzkOqlvzaNP0k6 CntTp88cSLUQHP1rlrZNPEtCepM90ctpVoVjOlPJpKLyr9nvFIUYzHdEnptD 9PQGtUcnzwRHVMzdEvYQqIxDpepzcgNWxBEo4AkJXU2NzlpyOM0eL61U3hBc I2Nu6Tz.jrKQXYs.aoMSUUqCyCLU_80gOcKKY2XjSVfdISai7Htg_eBmA7.C PUNZIvP91DhqmnhhHPi_7sudZpQ-- Received: from [217.36.79.41] by web142802.mail.bf1.yahoo.com via HTTP; Thu, 06 Mar 2014 23:16:23 PST X-Rocket-MIMEInfo: 002.001, SWYgYXV0aHppZCBpcyBhbiBhZHZpc29yeSB2YWx1ZSBmb3IgdGhlIHVzZXIgYmVpbmcgYXV0aGVudGljYXRlZCBhbmQgbm90IHRoZSBwcm94eSB0aGVuIHRoYXQgZml0cyBuaWNlbHkuIMKgSSdkIGhhcHBpbHkgZGVmaW5lICJ1c2VyIiBpbiB0aGUgc3BlYyBhczoKCiJDb250YWlucyB0aGUgdXNlciBuYW1lIGJlaW5nIGF1dGhlbnRpY2F0ZWQsIHRoZSBTQVNMIGF1dGhvcml6YXRpb24gaWRlbnRpZmllcsKgCihhdXRoemlkKS4gIFRoZcKgc2VydmVyIE1BWSB1c2UgdGhpcyBhcyBhIHJvdXRpbmcgb3IgZGF0YWIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: Message-ID: <1394176583.51714.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Thu, 6 Mar 2014 23:16:23 -0800 (PST) From: Bill Mills To: Nico Williams , "kitten@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-702468019-1394176583=:51714" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/IsyoHiHawBwCYohOx1Po4-aMMO8 Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 07:16:30 -0000 --1397251415-702468019-1394176583=:51714 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable If authzid is an advisory value for the user being authenticated and not th= e proxy then that fits nicely. =A0I'd happily define "user" in the spec as:= =0A=0A"Contains the user name being authenticated, the SASL authorization i= dentifier=A0=0A(authzid). The=A0server MAY use this as a routing or databa= se lookup hint. The=0Aserver MUST NOT use this as authoritative, the user = name MUST=A0be obtained=0Afrom the OAuth credential."=0A=0AIf that works fo= r you.=0A=0A-bill=0A=0A=0A=0AOn Thursday, March 6, 2014 6:05 PM, Nico Willi= ams wrote:=0A =0AQ: What is it?=A0 It is:=0A=0AMy a= nswer, as I understand it the authzid is:=0A=0A- an advisory, application-s= pecific value sent by the client inside=0Athe SASL mechanism's messages (i.= e., protected by the mechanism, if=0Athe mechanism can do it)=0A=0Aand=0A= =0A- notionally it's the name of a resource (user account, mailbox, ...)=0A= that the client wants to access or access things as.=0A=0AQ: Why do we care= about fitting things into the authzid?=0A=0AMy answer: because we don't wa= nt mechanisms to force new _required_=0Ainput elements on existing SASL API= s.=0A=0ASomeone please disabuse me of the above.=0A=0ANico=0A--=0A=0A______= _________________________________________=0AKitten mailing list=0AKitten@ie= tf.org=0Ahttps://www.ietf.org/mailman/listinfo/kitten --1397251415-702468019-1394176583=:51714 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
If authzid is an advisory value for the user being= authenticated and not the proxy then that fits nicely.  I'd happily d= efine "user" in the spec as:

"Contains the user na= me being authenticated, the SASL authorization identifier 
(authzid). The  server MU= ST NOT use this as authoritative, the user name MUST be obtained
from the OAuth credential."

If that works for you.
<= br>
-bill


On Thursday, March 6, 2014 6:05 PM, Nico Williams &l= t;nico@cryptonector.com> wrote:
Q: What is it?  It is:

My answer, as I understand it= the authzid is:

- an advisory, application-specific value sent by = the client inside
the SASL mechanism's messages (i.e., protected by the mechanism,= if
the mechanism can do it)

and

- notionally it's the na= me of a resource (user account, mailbox, ...)
that the client wants to a= ccess or access things as.

Q: Why do we care about fitting things in= to the authzid?

My answer: because we don't want mechanisms to force= new _required_
input elements on existing SASL APIs.

Someone ple= ase disabuse me of the above.

Nico
--

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


--1397251415-702468019-1394176583=:51714-- From nobody Fri Mar 7 04:53:18 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642671A0273 for ; Fri, 7 Mar 2014 04:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_4JQLuTkkts for ; Fri, 7 Mar 2014 04:53:14 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 88B4C1A013F for ; Fri, 7 Mar 2014 04:53:14 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s27Cr89v028094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Mar 2014 12:53:09 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s27Cr8fU028134; Fri, 7 Mar 2014 12:53:08 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.175.28.73] (dhcp-uk-twvpn-1-vpnpool-10-175-29-83.vpn.oracle.com [10.175.29.83]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built Jan 22 2014)) with ESMTPA id <0N2200A7NH3ZM100@gotmail.us.oracle.com>; Fri, 07 Mar 2014 04:52:49 -0800 (PST) Date: Fri, 07 Mar 2014 12:52:47 +0000 From: Chris Newman To: Nico Williams , kitten@ietf.org Message-id: In-reply-to: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/b5BUlSPz9v116ylLwJ_yt8n7V3E Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 12:53:16 -0000 --On March 6, 2014 20:05:39 -0600 Nico Williams wrote: > Q: What is it? It is: > > My answer, as I understand it the authzid is: > > - an advisory, application-specific value sent by the client inside > the SASL mechanism's messages (i.e., protected by the mechanism, if > the mechanism can do it) > > and > > - notionally it's the name of a resource (user account, mailbox, ...) > that the client wants to access or access things as. SASL has two identities: "the user whose credentials are provided" (authentication id) and "the user to login/authenticate as" (authorization id). The former is in a namespace determined by the underlying identity system. Some mechanisms, like Kerberos, force a namespace on the identity system. Some mechanisms, like PLAIN, tend to work with a wide variety of identity systems. The authorization id is in a namespace determined by the application consuming SASL. Both of these identities are often user@host syntax in practice, but there are exceptions (e.g., LDAP DNs). Two common scenarios for authorization identity are: using administrative credentials to login as another user, or a secretary using her credentials to login as her boss. If the supplied credentials are not authorized to login as the authorization identity, that should result in a SASL failure (with an authorization failed error code if the enclosing protocol has one). > Q: Why do we care about fitting things into the authzid? > > My answer: because we don't want mechanisms to force new _required_ > input elements on existing SASL APIs. I do not consider this an important design consideration, although it may be desirable to improve deployability of a mechanism. SASL's important function is a protocol design abstraction -- allowing an authentication mechanism suitable for multiple protocols to be encapsulated in multiple protocols without having to write how to do it separately for each one. Using a SASL API is completely optional and I've seen several cases where I consider SASL API usage harmful. - Chris From nobody Fri Mar 7 06:37:41 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2BB1A0118 for ; Fri, 7 Mar 2014 06:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 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, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BblZMhm_kkdP for ; Fri, 7 Mar 2014 06:37:36 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id D6FC71A0073 for ; Fri, 7 Mar 2014 06:37:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1394203051; d=isode.com; s=selector; i=@isode.com; bh=NA2f998J5yEgkLMidpbIEMJQ7DUpGZ9/IHGhvj++VVk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Lks6vcLqpEtuPajaeAcE4M7JlDKObdRmXKEKC9ileyacw2rjmy4Uc00uFG0kf1ZwVUacHl qLEpDak87etRKJXXpE8g+FKTy1DqZosJi2id3zM+G9BzURit/65f4pho12dFvn0MyYJbNb LDKn4+hfdxuVW+NIgfhL+M6fAc/G10Q=; Received: from [IPv6:2001:67c:1231:998:8568:1db6:7216:1d63] ((unknown) [31.130.238.210]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 7 Mar 2014 14:37:31 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (11B651) In-Reply-To: <1394176583.51714.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Fri, 7 Mar 2014 14:41:48 +0000 Message-Id: <4E333EB6-3D42-4DD1-A7CF-15F82922CFE9@isode.com> References: <1394176583.51714.YahooMailNeo@web142802.mail.bf1.yahoo.com> To: Bill Mills , Nico Williams MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-B4025B4C-D0FC-495C-947A-EEC815E75A55 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ZPDQptYicCuLzl3W1W0o20tiwg4 Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 14:37:38 -0000 --Apple-Mail-B4025B4C-D0FC-495C-947A-EEC815E75A55 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Maybe this is nitpicking, but: > On Thursday, March 6, 2014 6:05 PM, Nico Williams w= rote: > Q: What is it? It is: >=20 > My answer, as I understand it the authzid is: >=20 > - an advisory, This is not quite correct. Authentication engine needs to obey the specified= value and can't just ignore it. Specific algorithm how an authenticated use= r is authorised to act as an authzid is implementation and protocol specifi= c. > application-specific value sent by the client inside > the SASL mechanism's messages (i.e., protected by the mechanism, if > the mechanism can do it) This part is correct. >=20 > and >=20 > - notionally it's the name of a resource (user account, mailbox, ...) > that the client wants to access or access things as. --Apple-Mail-B4025B4C-D0FC-495C-947A-EEC815E75A55 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Maybe this is nitpicking, but:

On T= hursday, March 6, 2014 6:05 PM, Nico Williams <= nico@cryptonector.com> wrote:
Q: What is it?  It is:

= My answer, as I understand it the authzid is:

- an advisory,

This is not quite correct. Authentication eng= ine needs to obey the specified value and can't just ignore it. Specific alg= orithm how an authenticated user is  authorised to act as an authzid is= implementation and protocol specific.

application-specific value sent by the client inside
the SASL mechanism's messages (i.e., protected by the mechanism, i= f
the mechanism can do it)

This part= is correct.
and

- notionally it's the name of a resource (user account, mailbox= , ...)
that the client wants to access or access things as.
= --Apple-Mail-B4025B4C-D0FC-495C-947A-EEC815E75A55-- From nobody Fri Mar 7 07:12:31 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E821A01FC for ; Fri, 7 Mar 2014 07:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tmJRCALMbEV for ; Fri, 7 Mar 2014 07:12:27 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD691A0097 for ; Fri, 7 Mar 2014 07:12:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6D723206AC; Fri, 7 Mar 2014 10:07:50 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phlHcaibCV-O; Fri, 7 Mar 2014 10:07:50 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [217.41.226.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 7 Mar 2014 10:07:49 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0F17283F8D; Fri, 7 Mar 2014 10:12:20 -0500 (EST) From: Sam Hartman To: Benjamin Kaduk References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> <1394031556.4290.53.camel@destiny.pc.cs.cmu.edu> <5317BD6E.6080309@oracle.com> Date: Fri, 07 Mar 2014 10:12:20 -0500 In-Reply-To: (Benjamin Kaduk's message of "Thu, 6 Mar 2014 17:51:12 -0500 (EST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/27LKzs8wzgvkoAFbm7cqZMl_-y0 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 15:12:29 -0000 >>>>> "Benjamin" == Benjamin Kaduk writes: Benjamin> There actually is provision in RFC 2743 for tokens to be Benjamin> passed to gss_process_context_token which are not deletion Benjamin> tokens. (Last two paragraphs of 1.2.1.2.) I do not Benjamin> remember any provisions in RFC 4121 to account for this Benjamin> case, though, so I guess it is under-specified. Right, but no provisions to create such tokens. If we start thinking about that, making sure that RFC 4121 doesn't use the token type used by CFX would be potentially desirable.. >> In general, when you ship a draft, you take on responsibility for >> dealing if the IETF process doesn't go the way you anticipate. >> Doing that is part of doing business; it's definitely the case >> that there are times when you end up shipping based on drafts. Benjamin> I don't disagree with anything you say there. Benjamin> However, I think we should consider what the purpose of Benjamin> the central registry is: to document what values are in Benjamin> use and avoid conflicts. Given that there were already Benjamin> values in broad use when the registry was created, I think Benjamin> it is appropriate to document those values in the Benjamin> registry, even if it is just as "reserved to avoid Benjamin> conflicts", as Martin notes in the prior art. There Benjamin> certainly does not seem to be a shortage of values in the Benjamin> token type space. >> IANA expert decisions can be appealed; you'd first file an appeal >> with me, and then I'm not sure whether it goes to the IESG as a >> whole or the security AD. Benjamin> Is there a magic phrase that invokes such an appeal? (Or Benjamin> does it go through IANA?) I am unfamiliar with the Benjamin> process, and not necessarily indicating intent to do so. I'm not sure if there are more formal ways, but just drop me a note if you decide it's important enough to appeal and say that. INcluding rationale would be good. From nobody Fri Mar 7 07:40:40 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A87E1A023A for ; Fri, 7 Mar 2014 07:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTnCsYfw8JHN for ; Fri, 7 Mar 2014 07:40:38 -0800 (PST) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED1B1A01E0 for ; Fri, 7 Mar 2014 07:40:38 -0800 (PST) Received: from [98.139.215.141] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 15:40:33 -0000 Received: from [98.139.212.226] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 15:40:33 -0000 Received: from [127.0.0.1] by omp1035.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 15:40:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 590758.96956.bm@omp1035.mail.bf1.yahoo.com Received: (qmail 76960 invoked by uid 60001); 7 Mar 2014 15:40:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394206833; bh=rYpvo/1p42DVViafW86HXoMt4pdNMzOKUWMj+N4KkqY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Qd7GiRdFNrxRGDun5VnCOtGskqQ+3sGGwAzFPMtvL1yZA4OCYgYLssj9DkQZPucdA3poy433SGzKbVuG43cf4FYNb2VaK4E+aYlDVwPktkeftAQ40bUNl9Hv7h4VVlTbHS/HJQmxy69zHLMd2ys+NL7XuSZBbxei8Uq/2iuuDOE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=zAIiAGlPU8kzxuq+8BsZp9lnakesG5KBa/3luNmH1qYjf1FjnQglASPUkmiDMYDgXE1p4F/7V1w8Oq4fkQKoYZHFpdrLRo1fkbCAB5XiXja1EYOOtDMpmRvfw5rIyqLb9oufViFaGtGZULr0s9W+JZ3BnAueHQLlCjBQm6I8XO8=; X-YMail-OSG: i5Ki4gQVM1nfZw4rlwZvcK4mEZoq.Mv8QaS9rFpsRKUxyDY Wuh7kYuEof9a4KRFVxLxoltdGC0Nts9XlFrlEgIi9UEKRng2ReW3fJGi._jy NmJjNh53fakTatHtdL8dm_PfLSswMem4H.3aEBbtDfAZH8mU6KPoueeXZaAt WrcKUiFmVv9.CnKxWjJ2MuQEbttqZb2T38gUe61d4jgiIuXKt3IdAlbmIrLs PrAu7CGriL6LIaJ1raM8ugUZh5SyMNN7Pjg88Bg21BXMD.TE7L0AVxNCwan2 1dxVJTrlgetUhFkjYEij4o3bZdT_yR0Z5g4YjwZIXggXQ1LnIbLPiN1eSMVi LCDRAIJ3BoQi8gIy8oLgVPvpAaGD5zhrPOR0FDtKRMFW5Rg4t_oM5Zwn.qgC I7WwNeiko5MduiNyJtIDccaU6fgHOly7mTQxe4RZg6klTBdsPpOLlI3O.LWL 0hTHqYyGVQen1d3JqwQT17HXbnVy_L3CCQyj9CVIijNsGzRuGh6Ol9iZXyZn xObvZrDSJ44XnpyfV2ooqAg8s61qYqiWIJqTjvzMk65Emk7IXWs8OxhgOnNK CwqDBRL9bOXjuSeETeZfUsgPk_Rdco1y1BR9IvlWXMJdBVtFjtg517ZymL86 oSCFfjUsrog3hXla3yH7F8UtkoCJSCQZah_ybGfWqNkFCjL6aJbeuEhsB0xR GCKbu9JkR8zBFCWvxZNCYdAou4csKZwQ- Received: from [70.197.9.23] by web142806.mail.bf1.yahoo.com via HTTP; Fri, 07 Mar 2014 07:40:33 PST X-Rocket-MIMEInfo: 002.001, U28gQWxleGV5LCAKCkRvZXMgdGhpcyBtcmFuIHRoYXQgaWYgd2Ugc3BlY2lmeSAidXNyciIgYXMgdGhlIGF1dGhuIGlkIGluIFNBU0wgdGhhdCBpdCBtdXN0IGJlIHVzZWQgaW4gcHJvdG9jb2wgYXMgdGhlIGlkZW50aXR5P8KgwqAgSSBkb24ndCByZWFsbHkgd2FudCB0byBkbyB0aGF0LgoKLWJpbGwKClNlbnQgZnJvbSBZYWhvbyBNYWlsIG9uIEFuZHJvaWQKCgEwAQEBAQ-- X-Mailer: YahooMailAndroidMobile/3.0.5 YahooMailWebService/0.8.177.636 Message-ID: <1394206833.67567.YahooMailAndroidMobile@web142806.mail.bf1.yahoo.com> Date: Fri, 7 Mar 2014 07:40:33 -0800 (PST) From: Bill Mills To: Nico Williams , Alexey Melnikov In-Reply-To: <4E333EB6-3D42-4DD1-A7CF-15F82922CFE9@isode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="515012262-336477564-1394206833=:67567" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/5XccM31dxTV0flEtRygE4SB2Mc0 Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 15:40:40 -0000 --515012262-336477564-1394206833=:67567 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So Alexey, =0A=0ADoes this mran that if we specify "usrr" as the authn id i= n SASL that it must be used in protocol as the identity?=A0=A0 I don't real= ly want to do that.=0A=0A-bill=0A=0ASent from Yahoo Mail on Android=0A=0A --515012262-336477564-1394206833=:67567 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

So Alexey,

=0A

Does this mran that if = we specify "usrr" as the authn id in SASL that it must be used in protocol = as the identity? I don't really want to do that.

=0A

-bi= ll

=0A

Sent from Yahoo Mail on Android

=0A
=
=0A
=0A =
=0A
=0A
=0A
=0A = =0A From:=0A =0A = Alexey Melnikov <alexey.melnikov@isode.com>;=
=0A =0A = To:=0A = =0A Bill Mills <= wmills_92105@yahoo.com>; Nico Williams <nico@cryptonector.com>; =
=0A = =0A Cc:=0A =0A = kitten@ietf.org <kitten@ietf.org>; =
=0A = =0A Subject:=0A =0A = Re: [kitten] On SASL's authzid
= =0A =0A Sent:=0A = =0A Fri, Mar 7, 2014 2:41:48 PM =
=0A
=0A =
=0A =0A =0A = =0A
Maybe this is nitpicking, but:

On Thu= rsday, March 6, 2014 6:05 PM, Nico Williams <nico@cryptonector.com> wrote:
Q: What is it?=A0 It is:

My answer, as I understand it the authzid is= :

- an advisory,

This is not quite correct. Authentication = engine needs to obey the specified value and can't just ignore it. Spec= ific algorithm how an authenticated user is =A0authorised to act as an authzid is implementation and protocol specific.

application-s= pecific value sent by the client=0A inside
the SASL mecha= nism's messages (i.e., protected by the mechanism, if
the mechanism can do it)

This part is correct.


and

- = notionally it's the name of a resource (user account, mailbox, ...)
that the client wants to access or access things as.
=0A =0A = =0A
= =0A
=0A
=0A
= =0A --515012262-336477564-1394206833=:67567-- From nobody Fri Mar 7 07:57:36 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BAE1A0108 for ; Fri, 7 Mar 2014 07:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzibTj2SOptJ for ; Fri, 7 Mar 2014 07:57:33 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAF01A00FD for ; Fri, 7 Mar 2014 07:57:32 -0800 (PST) Received: from mail52-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.22; Fri, 7 Mar 2014 15:57:28 +0000 Received: from mail52-va3 (localhost [127.0.0.1]) by mail52-va3-R.bigfish.com (Postfix) with ESMTP id 3DFEC400B0; Fri, 7 Mar 2014 15:57:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.218; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf04; RD:none; EFVD:NLI X-SpamScore: 4 X-BigFish: VPS4(zzbb2dI98dI9371Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24d7h2516h2545h255eh25cch25f6h2605h1b1cn1b1bi1155h) Received-SPF: pass (mail52-va3: domain of osu.edu designates 164.107.81.218 as permitted sender) client-ip=164.107.81.218; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf04 ; cio-tnc-pf04 ; Received: from mail52-va3 (localhost.localdomain [127.0.0.1]) by mail52-va3 (MessageSwitch) id 1394207846743778_10987; Fri, 7 Mar 2014 15:57:26 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.237]) by mail52-va3.bigfish.com (Postfix) with ESMTP id A7E4916005C; Fri, 7 Mar 2014 15:57:26 +0000 (UTC) Received: from cio-tnc-pf04 (164.107.81.218) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 7 Mar 2014 15:57:24 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-tnc-pf04 (Postfix) with ESMTPS id 789D338005E; Fri, 7 Mar 2014 10:57:23 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.03.0174.001; Fri, 7 Mar 2014 10:57:22 -0500 From: "Cantor, Scott" To: Bill Mills , Nico Williams , Alexey Melnikov Thread-Topic: [kitten] On SASL's authzid Thread-Index: AQHPOanJU7MgJYkHMUqid6fG1ztCiJrVisiAgAB8cgCAABBrgP//sOMA Date: Fri, 7 Mar 2014 15:57:22 +0000 Message-ID: References: <4E333EB6-3D42-4DD1-A7CF-15F82922CFE9@isode.com> <1394206833.67567.YahooMailAndroidMobile@web142806.mail.bf1.yahoo.com> In-Reply-To: <1394206833.67567.YahooMailAndroidMobile@web142806.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [140.254.217.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/XYoABJvhZDRQrySEx-xV-Kw8Pck Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 15:57:35 -0000 On 3/7/14, 10:40 AM, "Bill Mills" wrote: >So Alexey,=20 >Does this mran that if we specify "usrr" as the authn id in SASL that it >must be used in protocol as the identity? I don't really want to do that. I think it would save time if somebody would just say what they *do* want to do. Not in vague terms, and not using the word "hint", but an explicit use case end to end, and then see if that is exactly what SASL authzid is or isn't. In the context of a mail client, I would guess the purpose of authzid is to identify a mailbox to log into. Nothing more or less. If that's what you want, it's authzid. If not, it's not, but then it also shouldn't be something the client GUI has to supply based on user input, or an IMAP server independent of SASL has to understand. -- Scott From nobody Fri Mar 7 08:32:53 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F64A1A023F for ; Fri, 7 Mar 2014 08:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6n4EJLzHM36o for ; Fri, 7 Mar 2014 08:32:50 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (unknown [69.163.253.176]) by ietfa.amsl.com (Postfix) with ESMTP id AC1EF1A023E for ; Fri, 7 Mar 2014 08:32:50 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 682436B007B for ; Fri, 7 Mar 2014 08:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Pjk7IAW5TVoqNf3J8aBR T7/AbB0=; b=mfvSGFu4mryXRcpPpaXiAKifVFyH9rBgX7VoKUanS7C6MW04vuUC 6LRmviR1awJLVEOvJHKBfAmgBNd4PpPfAft0FUmnMfBefm5EQW94F180Td6mSJtA dds9AejlGQjLlcLzy16NyNueDqMt1ioXTrKZsBzDF1MsNgNyEiZXh4w= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 188D46B0059 for ; Fri, 7 Mar 2014 08:32:45 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id a1so924330wgh.20 for ; Fri, 07 Mar 2014 08:32:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ANks1bIhoRMIm7eGTd8g43FoeY6sL+khZtSxpTcmZMQ=; b=If6Uu+dGVYj3M3F+Uu9aSLZmk0cAGwC1k1u1z5JDdecS8Dt8jjLQgqqodKdEjd9rcQ 2ZB0+x/AGmrBvBvAHLAUgdUQ8sq8HOU+haIZDi9TSAe3B+FRDejt85zQU1GM7VsJsYXT UqwwY+hd3GfSckIXj+B8dul8dam3+mvYbSvjWpfBtY9ONfVxB7MDIZodY+ifaTlkohOc gg5ql4oGd584GQ4hvzhS2qHZDzyfjgBQchXXpSATzO2edFBHIt77C4HaVMh+IV4AtMeP xNSsNn38P5VkolGPzJ1ieJ9oVKHgmrXa+jT0NZHIn7qUPzTWTblOOLVe7RTQO6ZHEfMy Vt2g== MIME-Version: 1.0 X-Received: by 10.194.84.240 with SMTP id c16mr3212020wjz.95.1394209964842; Fri, 07 Mar 2014 08:32:44 -0800 (PST) Received: by 10.216.199.6 with HTTP; Fri, 7 Mar 2014 08:32:44 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Mar 2014 10:32:44 -0600 Message-ID: From: Nico Williams To: Chris Newman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/gZr--n-uhJG7Qw5DINZRALsP03c Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 16:32:51 -0000 On Fri, Mar 7, 2014 at 6:52 AM, Chris Newman wrote: > --On March 6, 2014 20:05:39 -0600 Nico Williams > wrote: > Two common scenarios for authorization identity are: using administrative > credentials to login as another user, or a secretary using her credentials > to login as her boss. But there's a third one: name the IMAP mailbox you want to access. In the OAuth case, isn't that a "routing hint"? >> Q: Why do we care about fitting things into the authzid? >> >> My answer: because we don't want mechanisms to force new _required_ >> input elements on existing SASL APIs. > > I do not consider this an important design consideration, although it may be > desirable to improve deployability of a mechanism. SASL's important function > is a protocol design abstraction -- allowing an authentication mechanism > suitable for multiple protocols to be encapsulated in multiple protocols > without having to write how to do it separately for each one. Using a SASL > API is completely optional and I've seen several cases where I consider SASL > API usage harmful. Fair enough. What about application UIs then? If an IMAP application uses SASL and has a field in a GUI for authzid, is it OK for it to have to add a new field for a new mechanism? Nico -- From nobody Fri Mar 7 08:37:22 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5E01A01E3 for ; Fri, 7 Mar 2014 08:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdxcY3fpnP6b for ; Fri, 7 Mar 2014 08:37:19 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (agjbgdcfdbea.dreamhost.com [69.163.253.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6020D1A0104 for ; Fri, 7 Mar 2014 08:37:19 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 3D0C62005D109 for ; Fri, 7 Mar 2014 08:37:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ztjQuI4FBlo32iSHjHBZ VAeQN3A=; b=JX+00ZnjSSuXU1KP2UmFAJ0LDwvTlwsG3QCuacwWIi+SIv6Y6UYU 43UC1vLtJehFezcQ0ottrde5URV5IbIJrr1G1yXFHW3kV2fW+zL9Y8wcmwQlPWxQ USVx51DE+VmwC9Xm35FKshX9ONiBqSo5sqakaPW5slg7SYJ9eiOxxZg= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id E4D652005D106 for ; Fri, 7 Mar 2014 08:37:14 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id t61so5290230wes.31 for ; Fri, 07 Mar 2014 08:37:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RlqJRkMZ+2WoxCx7Di8By+61AOAK+eW+4C5d6H2u6kI=; b=GJqYRacrPHVL76TnBF9xOU1QqoCfBRSAwBxS5C2hdVUZTYn5aT2UkHkiQ9aAQInkmQ u8FlJ0/E2ZmYe8CnhY3JA6HOST9Y/bMnuaEyiZQx2XEkbsb39RA4AGMqJX9U1im0yzXw j4+Cklc66Y2F6XL0+O+q2pzSGWX2KlitE0gtrMuU64+VU92F8lA74Iskvj09+tVMRlK+ cTONUedoAJEaPH7N1JAQzTOakGX99RQnAuagR7BdXhoGZe8SwKbRS4L4x1LP5M8MqzvB 3UbS0gQuV4LBY2gkcuTDh3Xw56cvAIcU1HMXEXKHvhy7DM7p1sgc8XsHlZFvpAZFJ+xg Bu2A== MIME-Version: 1.0 X-Received: by 10.195.13.103 with SMTP id ex7mr20446175wjd.3.1394210233884; Fri, 07 Mar 2014 08:37:13 -0800 (PST) Received: by 10.216.199.6 with HTTP; Fri, 7 Mar 2014 08:37:13 -0800 (PST) In-Reply-To: <4E333EB6-3D42-4DD1-A7CF-15F82922CFE9@isode.com> References: <1394176583.51714.YahooMailNeo@web142802.mail.bf1.yahoo.com> <4E333EB6-3D42-4DD1-A7CF-15F82922CFE9@isode.com> Date: Fri, 7 Mar 2014 10:37:13 -0600 Message-ID: From: Nico Williams To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/scijrSaMPKM02EjLr1djyd0WXcE Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 16:37:20 -0000 On Fri, Mar 7, 2014 at 8:41 AM, Alexey Melnikov wrote: > > Q: What is it? It is: >> > > My answer, as I understand it the authzid is: > > > > - an advisory, > > This is not quite correct. Authentication engine needs to obey the specified > value and can't just ignore it. Specific algorithm how an authenticated user > is authorised to act as an authzid is implementation and protocol specific. The authorization check could be synthetic though. The authzid value is only transported by the mechanism. The app decides if the authcid is permitted, and this decision can be very synthetic: use the authzid to find something, then decide if the user has access. For example, in LDAP the authzid might be a DN, but as you know the rules for matching some object by DN are not trivial, so the user may not provide a canonical DN and everything might still work. Indeed, the server is free to decide that the access the user would have had w/o an authzid is the same with any authzid -- nothing in RFC4422 forces it to never so decide. But maybe this isin't important. The question I just asked Chris is more important: is it OK for new mechanisms to impose new UIs/user interactions on existing applications? Nico -- From nobody Fri Mar 7 11:51:56 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4202C1A0105 for ; Fri, 7 Mar 2014 11:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ged34QpjInbH for ; Fri, 7 Mar 2014 11:51:53 -0800 (PST) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0A71A00C2 for ; Fri, 7 Mar 2014 11:51:53 -0800 (PST) Received: from [98.139.212.151] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 19:51:49 -0000 Received: from [98.139.212.203] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 19:51:49 -0000 Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 19:51:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 58666.11048.bm@omp1012.mail.bf1.yahoo.com Received: (qmail 80733 invoked by uid 60001); 7 Mar 2014 19:51:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394221908; bh=zhx1xIQ8MfqDfEGZfC/Q0CWTyCysDUjxZd9oI93UcG0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IGgjZ05CCwg3xtbIXz2JfLVL6t9b0XW+LRDWyLpZIDztkp2OX9ini029zns8jBZ6uFjgtyY31gXwAct+MWoscyhJTVsYFzAM6gAtmi41YncvAc8MLmz2JcBr/jC5P0E2v9eFA+wFlxQP2gAnejFBZ+nVOvNPTNXpofZ+DoEcas8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gN4KflinBODuO0RUCi5LhCTe6kqEPq+ZjZjJQcCQfBbBKjJxovrHO6NrP/A1ugmzTiR/Y/tqbScEWXWehL9xdsa0/eikWOwWbmw3ktlVjQggza4Vztt6b+cslN+5atk4Nec8s8d1aDssA0dUfRIHrpv9uY7DWxqfqkq4YZPWPos=; X-YMail-OSG: EI5_YfAVM1miJmlfBDGJs09AM6DHxRAFPjI8MEGEtpCVXD9 0clCQ.N.2D373PRpLYzfOTpdJYp7LjSs5AhVYy3mDMF81n_xe6xNp65b1Y1c mvbbUjQLZYDYvJqaBbuBUDMxzvUrUvdAvYa3EMXYZ0n6zpoyThWm7Ig.Id0c LcrRjscZxyXIyDczHy_2Cro7GtRyQTOY0UJoEJwlbCTUPxvRdpYmLcGLoFH1 34m0.LcTg5uFiEZQ85sWfjw1oE6wLz.ETm0hm3f0fUkU.wFYKtspmV42K8nL K6cKdiaFnr.c1jHyX_c6PD9fZsrkyvo8WbHfIFOVtfR0vbPV4Fxk2m8alKnu hBIYNqIM0Kp1OhMEg.YHUGFYKKeqgsDUsTJoaMF5DJQtmjUwCItamJPRQBQT R.kcRl.hrCiLNvdKI6P47iS79ZkyYxxSjxhJkoJrURXRrbQiELworUn6ar6s suR6P3yuN8quzp9CT2PZjg3M7HgOSXS374BiD6s1ZtIKVvswM3wUwEQYA6UD FZamC4zVqpuiQ5OZKU_eGyEsOEFM4mwYL0W14Ry1025oKf9iLqlbIJqAoiSP E5PjWdhiBPOnmiA5PGorTvQp94Q5q8jX9H0FZ2m1UtcqM0tEnsp3CtfwCMYY BVHdrtFl9QFQg93wiOYmgOJx_emXwqOmQv4T4tFdeJodDFq.8et1SHtLrkqi TV4CQfljW2d70xe4rz4uGjLNF7CsWHg-- Received: from [70.197.9.23] by web142805.mail.bf1.yahoo.com via HTTP; Fri, 07 Mar 2014 11:51:48 PST X-Rocket-MIMEInfo: 002.001, WWVzLCB0aGUgbWFpbGJveCB5b3Ugd2FudCB0byBhY2Nlc3MgaXMgYSBnb29kIGRlc2NyaXB0aW9uLgoKU2VudCBmcm9tIFlhaG9vIE1haWwgb24gQW5kcm9pZAoKATABAQEB X-Mailer: YahooMailAndroidMobile/3.0.5 YahooMailWebService/0.8.177.636 Message-ID: <1394221908.72933.YahooMailAndroidMobile@web142805.mail.bf1.yahoo.com> Date: Fri, 7 Mar 2014 11:51:48 -0800 (PST) From: Bill Mills To: Chris Newman , Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1583497461-1484429353-1394221908=:72933" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/7-6q86sAIZ80sfzJBAJPwDdGzgY Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 19:51:55 -0000 --1583497461-1484429353-1394221908=:72933 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yes, the mailbox you want to access is a good description.=0A=0ASent from Y= ahoo Mail on Android=0A=0A --1583497461-1484429353-1394221908=:72933 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Yes, the mailbox you want to access is a good descriptio= n.

=0A

Sent from Yahoo Mail on Android

=0A
=
=0A
=0A =
=0A
=0A
=0A
=0A = =0A From:=0A =0A = Nico Williams <nico@cryptonector.com>; =
=0A =0A = To:=0A = =0A Chris Newman <chri= s.newman@oracle.com>; =
=0A =0A = Cc:=0A <= /b>=0A kitten@ietf.org <kitten@ietf.org>; = =
=0A =0A <= span style=3D"font-weight:bold">Subject:=0A = =0A Re: [kitten] On SASL's authzid =
=0A =0A = Sent:=0A = =0A Fri, Mar 7, 2014 4:3= 2:44 PM
=0A
=0A=
=0A =0A = =0A =0A = =0A = =0A =0A =
On Fri, Mar 7, 2014 at 6:52 AM, Ch= ris Newman <chris.newman@oracle.com> wrote:
> --On March 6, 2014 20:05:39 -0600 Nico Williams <nico@cryptonector.com>
> wrote:
> Two common scenarios for authorization identity are: using admin= istrative
> credentials to login as another user, or a= secretary using her credentials
> to login as her bos= s.

But there's a third one: name t= he IMAP mailbox you want to access.=A0 In
the OAuth case,= isn't that a "routing hint"?

>> Q: Why do we care about fitting things into the authzid?
>>
>> My answer: because we d= on't want mechanisms to force new _required_
>>= input elements on existing SASL APIs.
>
> I do not consider this an important design consideration, althoug= h it may be
> desirable to improve deployability of a = mechanism. SASL's important function
> is a protoc= ol design abstraction -- allowing an authentication mechanism
> suitable for multiple protocols to be encapsulated in multiple pr= otocols
> without having to write how to do it separat= ely for each one. Using a SASL
> API is completely opt= ional and I've seen several cases where I consider SASL
> API usage harmful.

Fair enough= .=A0 What about application UIs then?=A0 If an IMAP application
uses SASL and has a field in a GUI for authzid, is it OK for it to
hav= e to add a new field for a new mechanism?


Nico
-= -

____________________________________= ___________
Kitten mailing list
Ki= tten@ietf.org
https://www.ietf.org/mai= lman/listinfo/kitten
=0A
=0A =
=0A
=0A --1583497461-1484429353-1394221908=:72933-- From nobody Fri Mar 7 12:14:39 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB3A1A0270 for ; Fri, 7 Mar 2014 12:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voNU3hb9bgbw for ; Fri, 7 Mar 2014 12:14:34 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 874531A0255 for ; Fri, 7 Mar 2014 12:14:34 -0800 (PST) Received: from mail143-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Fri, 7 Mar 2014 20:14:29 +0000 Received: from mail143-va3 (localhost [127.0.0.1]) by mail143-va3-R.bigfish.com (Postfix) with ESMTP id 498B71A02DB; Fri, 7 Mar 2014 20:14:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:199.135.140.20; KIP:(null); UIP:(null); IPV:NLI; H:mail.usda.gov; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzzz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1f96jzzz2fh109h2a8h839h8e2h8e3h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h21a6h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605hbe9i1155h) Received-SPF: pass (mail143-va3: domain of fs.fed.us designates 199.135.140.20 as permitted sender) client-ip=199.135.140.20; envelope-from=bnordgren@fs.fed.us; helo=mail.usda.gov ; ail.usda.gov ; Received: from mail143-va3 (localhost.localdomain [127.0.0.1]) by mail143-va3 (MessageSwitch) id 1394223267881884_3578; Fri, 7 Mar 2014 20:14:27 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.253]) by mail143-va3.bigfish.com (Postfix) with ESMTP id CF56D1C0130; Fri, 7 Mar 2014 20:14:27 +0000 (UTC) Received: from mail.usda.gov (199.135.140.20) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 7 Mar 2014 20:14:26 +0000 Received: from 001FSN2MPN1-045.001f.mgd2.msft.net ([169.254.5.242]) by 001FSN2MMR1-010.001f.mgd2.msft.net ([199.135.140.20]) with mapi id 14.03.0174.002; Fri, 7 Mar 2014 20:13:59 +0000 From: "Nordgren, Bryce L -FS" To: Nico Williams , Alexey Melnikov Thread-Topic: [kitten] On SASL's authzid Thread-Index: AQHPOanCTnHj2reoA0u0F82UWvAfjZrVNvaAgAB8cwCAACA/gIAAO88A Date: Fri, 7 Mar 2014 20:13:58 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E692618@001FSN2MPN1-045.001f.mgd2.msft.net> References: <1394176583.51714.YahooMailNeo@web142802.mail.bf1.yahoo.com> <4E333EB6-3D42-4DD1-A7CF-15F82922CFE9@isode.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.26.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fs.fed.us X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/2P02uXl_XouYY2SiitMDRLKREY8 Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 20:14:37 -0000 > But maybe this isin't important. The question I just asked Chris is more > important: is it OK for new mechanisms to impose new UIs/user interaction= s > on existing applications? If this was software, you'd keep the API stable during minor revisions and = rearrange things for major revisions. The UI would supply whatever it had t= o in order to use the version of SASL it wants to use. Bryce This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you= have received this message in error, please notify the sender and delete t= he email immediately. From nobody Fri Mar 7 12:25:59 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA7E1A01AD for ; Fri, 7 Mar 2014 12:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msnDnMewgSdJ for ; Fri, 7 Mar 2014 12:25:56 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (agjbgdcfdbfd.dreamhost.com [69.163.253.153]) by ietfa.amsl.com (Postfix) with ESMTP id 616721A0136 for ; Fri, 7 Mar 2014 12:25:56 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 2B1D050808E for ; Fri, 7 Mar 2014 12:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=PuL8f+R3k/kotn4kiF7W pVsnbd4=; b=eDGPL13IeYHHYw9SBwvgQ6xFMD/8qIUmxgTQ5iofRJyjv2o6pnTp s4ldbaUkUxJ1hyqN3o3V3n8Fl9RCtthkA2YNUYpHlK2oshEf/e2WmLRLRXCpqEg1 6YE1Idp7+QnnaORdPPFRQI+n84xCnf+i5zntQbwfk8gVvt8XFkCLWxc= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id D151B508064 for ; Fri, 7 Mar 2014 12:25:51 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id x48so5725801wes.10 for ; Fri, 07 Mar 2014 12:25:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CLmHYEpapc9Ba42jyyCuJC4iNaSs8cTPhKieuYnVrIg=; b=JoGGcuKYgGl4dGtvFoBFhD1BCWsoCbmECsmjhpsbj8R2vMxVVsN74PzwS6easzItaS +yzrUJecHZs3dQ7qPNrKxWMBFOzNs+o7leXT1vb4EwPLy/sYFEPuQ3dXOXKQiaYuZpdv sCnWkI452hceGSP2pDVBDqPG7t5Y6TSckomn8nn8wuVMIoqMeEzswYFSreiM/2UVMAt8 +kPJCsN4Mn0XD8yFod6NXBoruP98iNSw1Hp0DSQeJhvNjDEV9pdNw+oRNDYBtV0ox3AJ iBf+tbsVYnwE/EtRwDJbyDJwdp78iKQcnxdMyaawssyiLbAAqQGCzE6d9L0bpNvbELAg wSPQ== MIME-Version: 1.0 X-Received: by 10.194.84.240 with SMTP id c16mr33324wjz.95.1394223950723; Fri, 07 Mar 2014 12:25:50 -0800 (PST) Received: by 10.216.199.6 with HTTP; Fri, 7 Mar 2014 12:25:50 -0800 (PST) In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E692618@001FSN2MPN1-045.001f.mgd2.msft.net> References: <1394176583.51714.YahooMailNeo@web142802.mail.bf1.yahoo.com> <4E333EB6-3D42-4DD1-A7CF-15F82922CFE9@isode.com> <82E7C9A01FD0764CACDD35D10F5DFB6E692618@001FSN2MPN1-045.001f.mgd2.msft.net> Date: Fri, 7 Mar 2014 14:25:50 -0600 Message-ID: From: Nico Williams To: "Nordgren, Bryce L -FS" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Pe2Xyf1vmvWmBqnUSv0ArkTqZLE Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 20:25:57 -0000 On Fri, Mar 7, 2014 at 2:13 PM, Nordgren, Bryce L -FS wrote: >> But maybe this isin't important. The question I just asked Chris is more >> important: is it OK for new mechanisms to impose new UIs/user interactions >> on existing applications? > > If this was software, you'd keep the API stable during minor revisions and rearrange things for major revisions. The UI would supply whatever it had to in order to use the version of SASL it wants to use. But SASL doesn't define an API (unlike GSS). So we need to identify what is to be kept stable, if anything, and it's not as simple as "the API". Nico -- From nobody Fri Mar 7 12:27:00 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B291A02C8 for ; Fri, 7 Mar 2014 12:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTBavvDv5p_Z for ; Fri, 7 Mar 2014 12:26:58 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (agjbgdcfdbhb.dreamhost.com [69.163.253.171]) by ietfa.amsl.com (Postfix) with ESMTP id D032C1A02C2 for ; Fri, 7 Mar 2014 12:26:55 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 92B2F43806C for ; Fri, 7 Mar 2014 12:26:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=/t8orYJGbbF1f1/zX+Lf robKEgQ=; b=GyG5dmQ+UilP+3IMqU6pqAnk8Zh63V++O88cfmW4RbWKzyGjmQLT rqIUjVggRHHn9oQIrL0H2zK7k5dai2Zg8RCeg0Wmed3Qp6iZtgr7WqJfsxrP8MTP sq/mwmlmkwLoYHYY82geiS/j5gsYmLcVbDuI/bPPBWSYhckVLegv+4U= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 2BE7543807E for ; Fri, 7 Mar 2014 12:26:51 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id x48so5727134wes.10 for ; Fri, 07 Mar 2014 12:26:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z6LUiqnPWwzq2b3QujKg786UdLMH1zz6+8MoenIUcrE=; b=RMmhfN11hoeWlEwzCo9B6dywYVMR81TGJt6plOkFNViLALuwYANHVa0itQKh1Eaxfl FFQrtvyvwPBXgh9dnokSBR/q43D2PVSRU6wcONaX+5zkoezd8cJxU3cQ1zFV9X1zXsgE HcHE2CQMMwa37Hc1U4VpCiq55poIj9F/SLzTMtQhL1EV95RDk5Ss2csLqi5DQ6yQRm8B lyffbD4jsj1tGYJmXFRk3jqp4T2HikbJ/SYIpnT65x1bNO8kMf7+A2ybGXEiSAz6quOA E0PeQio8awBU6FXivwfmkj0FDYaOmtunpZZJfiQ+ToPRokaZET04H7d4xn7YPHJXIXyZ MNRw== MIME-Version: 1.0 X-Received: by 10.180.36.8 with SMTP id m8mr248643wij.42.1394224010151; Fri, 07 Mar 2014 12:26:50 -0800 (PST) Received: by 10.216.199.6 with HTTP; Fri, 7 Mar 2014 12:26:50 -0800 (PST) In-Reply-To: <1394221908.72933.YahooMailAndroidMobile@web142805.mail.bf1.yahoo.com> References: <1394221908.72933.YahooMailAndroidMobile@web142805.mail.bf1.yahoo.com> Date: Fri, 7 Mar 2014 14:26:50 -0600 Message-ID: From: Nico Williams To: Bill Mills Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/iydCFLTdcClKp9pAOtLpFKt59Ic Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 20:26:58 -0000 On Fri, Mar 7, 2014 at 1:51 PM, Bill Mills wrote: > Yes, the mailbox you want to access is a good description. Then it's an authzid, no doubt in my mind. Anyone disagree? Nico -- From nobody Fri Mar 7 12:52:12 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2151A0103 for ; Fri, 7 Mar 2014 12:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sl5Mm51tkxcL for ; Fri, 7 Mar 2014 12:52:09 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 656731A00E9 for ; Fri, 7 Mar 2014 12:52:09 -0800 (PST) Received: from mail72-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Fri, 7 Mar 2014 20:52:04 +0000 Received: from mail72-tx2 (localhost [127.0.0.1]) by mail72-tx2-R.bigfish.com (Postfix) with ESMTP id 67003E01D0; Fri, 7 Mar 2014 20:52:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:199.135.140.14; KIP:(null); UIP:(null); IPV:NLI; H:mail.usda.gov; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zz1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1f96jzzz2fh109h2a8h839h8e2h8e3h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h21a6h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605hbe9i1155h) Received-SPF: pass (mail72-tx2: domain of fs.fed.us designates 199.135.140.14 as permitted sender) client-ip=199.135.140.14; envelope-from=bnordgren@fs.fed.us; helo=mail.usda.gov ; ail.usda.gov ; Received: from mail72-tx2 (localhost.localdomain [127.0.0.1]) by mail72-tx2 (MessageSwitch) id 139422552227668_12517; Fri, 7 Mar 2014 20:52:02 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.243]) by mail72-tx2.bigfish.com (Postfix) with ESMTP id EA4F6A00E8; Fri, 7 Mar 2014 20:52:01 +0000 (UTC) Received: from mail.usda.gov (199.135.140.14) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 7 Mar 2014 20:52:01 +0000 Received: from 001FSN2MPN1-045.001f.mgd2.msft.net ([169.254.5.242]) by 001FSN2MMR1-004.001f.mgd2.msft.net ([199.135.140.14]) with mapi id 14.03.0174.002; Fri, 7 Mar 2014 20:52:00 +0000 From: "Nordgren, Bryce L -FS" To: Nico Williams Thread-Topic: [kitten] On SASL's authzid Thread-Index: AQHPOanCTnHj2reoA0u0F82UWvAfjZrVNvaAgAB8cwCAACA/gIAAO88AgAAEEQCAAAQJQA== Date: Fri, 7 Mar 2014 20:52:00 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E69271C@001FSN2MPN1-045.001f.mgd2.msft.net> References: <1394176583.51714.YahooMailNeo@web142802.mail.bf1.yahoo.com> <4E333EB6-3D42-4DD1-A7CF-15F82922CFE9@isode.com> <82E7C9A01FD0764CACDD35D10F5DFB6E692618@001FSN2MPN1-045.001f.mgd2.msft.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.26.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fs.fed.us X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/AWfKgGiVZLDec0jAczneXYRxrsc Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 20:52:11 -0000 DQo+ID4gSWYgdGhpcyB3YXMgc29mdHdhcmUsIHlvdSdkIGtlZXAgdGhlIEFQSSBzdGFibGUgZHVy aW5nIG1pbm9yIHJldmlzaW9ucyBhbmQNCj4gcmVhcnJhbmdlIHRoaW5ncyBmb3IgbWFqb3IgcmV2 aXNpb25zLiBUaGUgVUkgd291bGQgc3VwcGx5IHdoYXRldmVyIGl0IGhhZCB0bw0KPiBpbiBvcmRl ciB0byB1c2UgdGhlIHZlcnNpb24gb2YgU0FTTCBpdCB3YW50cyB0byB1c2UuDQo+DQo+IEJ1dCBT QVNMIGRvZXNuJ3QgZGVmaW5lIGFuIEFQSSAodW5saWtlIEdTUykuICBTbyB3ZSBuZWVkIHRvIGlk ZW50aWZ5IHdoYXQgaXMNCj4gdG8gYmUga2VwdCBzdGFibGUsIGlmIGFueXRoaW5nLCBhbmQgaXQn cyBub3QgYXMgc2ltcGxlIGFzICJ0aGUgQVBJIi4NCg0KSW4gZ2VuZXJhbCwgSSB3b3VsZCBzdWdn ZXN0IHRoYXQgaWYgYSBwcm9wb3NlZCBjaGFuZ2UgaW5zcGlyZXMgY29tcGF0aWJpbGl0eSBjb25j ZXJucywgaXQgd291bGQgc2VlbSB0byBiZWxvbmcgdG8gdGhlIHNldCBvZiB0aGluZ3MgeW91J2Qg cHJlZmVyIHRvIGtlZXAgc3RhYmxlLg0KDQpCcnljZQ0KDQoNCg0KDQpUaGlzIGVsZWN0cm9uaWMg bWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiBnZW5lcmF0ZWQgYnkgdGhlIFVTREEgc29sZWx5 IGZvciB0aGUgaW50ZW5kZWQgcmVjaXBpZW50cy4gQW55IHVuYXV0aG9yaXplZCBpbnRlcmNlcHRp b24gb2YgdGhpcyBtZXNzYWdlIG9yIHRoZSB1c2Ugb3IgZGlzY2xvc3VyZSBvZiB0aGUgaW5mb3Jt YXRpb24gaXQgY29udGFpbnMgbWF5IHZpb2xhdGUgdGhlIGxhdyBhbmQgc3ViamVjdCB0aGUgdmlv bGF0b3IgdG8gY2l2aWwgb3IgY3JpbWluYWwgcGVuYWx0aWVzLiBJZiB5b3UgYmVsaWV2ZSB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoZSBlbWFpbCBpbW1lZGlhdGVseS4NCg== From nobody Fri Mar 7 13:58:38 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1188F1A02C5 for ; Fri, 7 Mar 2014 13:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BX16By1bKyN for ; Fri, 7 Mar 2014 13:58:37 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (agjbgdcfdbfd.dreamhost.com [69.163.253.153]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1EC1A01EE for ; Fri, 7 Mar 2014 13:58:37 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id DC0D350808E for ; Fri, 7 Mar 2014 13:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=bBwVvsg2PcKWp3SS3Ui2 ciJe5OU=; b=lcI+y3XTdxUIe0A0XX2jleGTeGV+h3i+rdkxBGEfZiFT4Uz4k5pe H15ETDRCvK6a0Q+/xGgNblWyc247OMFBcA9+bqomRNAXqqVilXkfWVyA5NrqjuZa 0yP/aChmxAqXndn5mYrD5RU+DD7vxLBQ6kxX8Uv73tY7cVZ2kKgEzEg= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 8D7C9508084 for ; Fri, 7 Mar 2014 13:58:32 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id w62so5860448wes.14 for ; Fri, 07 Mar 2014 13:58:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dVJduIDuLdOu+XJTvPQRXDVbC/RmQyFZaPGqpxvrb4A=; b=GyHWXrf3/4f0T30eefMthzcEtcWNLpG2F3FrHd7c0m6LRZ20nTM3CtN3rnrDXEevxu gdO3Pc31Sei2TO2Wis0z7bmFs5qgNe57mJEfcqmQiOYgHVooIYJdzbHXGLjqRw2zg3+L jk55IWAJ5d4C0Q1D5AyRXuWSb6U4Ctpj5TZuaUyGFT/+Ly+4i5kVFkFot6hQ3OI4+wUi WeO4jrX4lWGh9DvwmyWRPaaD5ld4mkgwEPP4yeu+8X+3WohztFXlcIMPUtV+l2Dn04C0 nL5NmnbjmCwVPpdRXqMlBSCCPIjOemPmwv1oqjobNPHqhq9bXsnQCzTaB94lcRI78s6k sHxQ== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr479667wib.5.1394229511461; Fri, 07 Mar 2014 13:58:31 -0800 (PST) Received: by 10.216.199.6 with HTTP; Fri, 7 Mar 2014 13:58:31 -0800 (PST) In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E69271C@001FSN2MPN1-045.001f.mgd2.msft.net> References: <1394176583.51714.YahooMailNeo@web142802.mail.bf1.yahoo.com> <4E333EB6-3D42-4DD1-A7CF-15F82922CFE9@isode.com> <82E7C9A01FD0764CACDD35D10F5DFB6E692618@001FSN2MPN1-045.001f.mgd2.msft.net> <82E7C9A01FD0764CACDD35D10F5DFB6E69271C@001FSN2MPN1-045.001f.mgd2.msft.net> Date: Fri, 7 Mar 2014 15:58:31 -0600 Message-ID: From: Nico Williams To: "Nordgren, Bryce L -FS" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/TTHiIzf1dGlaeFGIRMJd0WKpOSk Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 21:58:38 -0000 On Fri, Mar 7, 2014 at 2:52 PM, Nordgren, Bryce L -FS wrote: >> > If this was software, you'd keep the API stable during minor revisions and >> rearrange things for major revisions. The UI would supply whatever it had to >> in order to use the version of SASL it wants to use. >> >> But SASL doesn't define an API (unlike GSS). So we need to identify what is >> to be kept stable, if anything, and it's not as simple as "the API". > > In general, I would suggest that if a proposed change inspires compatibility concerns, it would seem to belong to the set of things you'd prefer to keep stable. I don't diagree. However, since SASL doesn't have an "API" or anything quite so well defined, so we don't quite know what the intention was/is, if any, as to this sort of change. We should state what a mechanism can and cannot do. I'm of the opinion that adding a required authzid-like item (like in that the item is to be transported by the mechanism, but provided and interpreted by the application) is a change to SASL, therefore not a change that a mechanism may introduce. Adding an _optional_ authzid-like item would be OK, but then we get to split hairs as to what makes something optional or required: if not providing the "optional" item means the mechanism won't work, then it sounds like "required" to me, but if it's only the one mechanism that breaks, then maybe we shouldn't care. In any case, it does seem clear now that user= _is_ the same as authzid. So we don't have to spend any more effort thinking about the above (though arguably we should). Nico -- From nobody Fri Mar 7 14:07:12 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9F21A0270 for ; Fri, 7 Mar 2014 14:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH9EuV-GQiL1 for ; Fri, 7 Mar 2014 14:07:04 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id BDB051A017E for ; Fri, 7 Mar 2014 14:07:04 -0800 (PST) Received: from mail142-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.22; Fri, 7 Mar 2014 22:07:00 +0000 Received: from mail142-ch1 (localhost [127.0.0.1]) by mail142-ch1-R.bigfish.com (Postfix) with ESMTP id D70034C023A; Fri, 7 Mar 2014 22:06:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.216; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf02; RD:none; EFVD:NLI X-SpamScore: 4 X-BigFish: VPS4(zzbb2dI98dI9371Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h1b1cn1b1bi1155h) Received-SPF: pass (mail142-ch1: domain of osu.edu designates 164.107.81.216 as permitted sender) client-ip=164.107.81.216; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf02 ; cio-tnc-pf02 ; Received: from mail142-ch1 (localhost.localdomain [127.0.0.1]) by mail142-ch1 (MessageSwitch) id 139423001882472_7189; Fri, 7 Mar 2014 22:06:58 +0000 (UTC) Received: from CH1EHSMHS036.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.233]) by mail142-ch1.bigfish.com (Postfix) with ESMTP id 0F30E40096; Fri, 7 Mar 2014 22:06:58 +0000 (UTC) Received: from cio-tnc-pf02 (164.107.81.216) by CH1EHSMHS036.bigfish.com (10.43.69.245) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 7 Mar 2014 22:06:56 +0000 Received: from CIO-KRC-HT03.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-tnc-pf02 (Postfix) with ESMTPS id 7B28A20056; Fri, 7 Mar 2014 17:06:56 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT03.osuad.osu.edu ([fe80::2572:c08d:8186:46a4%12]) with mapi id 14.03.0174.001; Fri, 7 Mar 2014 17:06:56 -0500 From: "Cantor, Scott" To: Nico Williams , "Nordgren, Bryce L -FS" Thread-Topic: [kitten] On SASL's authzid Thread-Index: AQHPOanJU7MgJYkHMUqid6fG1ztCiJrVisiAgAB8cgCAACBAgIAAPI8AgAADUQCAAAdPAIAAEpaA//+uhgA= Date: Fri, 7 Mar 2014 22:06:55 +0000 Message-ID: References: <1394176583.51714.YahooMailNeo@web142802.mail.bf1.yahoo.com> <4E333EB6-3D42-4DD1-A7CF-15F82922CFE9@isode.com> <82E7C9A01FD0764CACDD35D10F5DFB6E692618@001FSN2MPN1-045.001f.mgd2.msft.net> <82E7C9A01FD0764CACDD35D10F5DFB6E69271C@001FSN2MPN1-045.001f.mgd2.msft.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.251] Content-Type: text/plain; charset="us-ascii" Content-ID: <167BF6CFDD8B3A438D0436B29CC1CA99@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ARx9LOG3G4hEfwTdYpdXKCBdf8U Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 22:07:07 -0000 On 3/7/14, 4:58 PM, "Nico Williams" wrote: >In any case, it does seem clear now that user=3D _is_ the same as >authzid. So we don't have to spend any more effort thinking about the >above (though arguably we should). It's been clear to some people at times, but I have yet to hear real confirmation from the people with the use case as to whether that's true as a whole, or as to whether *some* of the use cases for the user hint align but others don't. I'm only saying this because I'm on the list and I fear another long round of hashing and thrashing to get back to the same unclear endpoint. If I'm tired of it, I can't imagine how the principals are. -- Scott From nobody Fri Mar 7 14:13:46 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522AF1A017E for ; Fri, 7 Mar 2014 14:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuimsRqIEPSF for ; Fri, 7 Mar 2014 14:13:42 -0800 (PST) Received: from nm49-vm10.bullet.mail.bf1.yahoo.com (nm49-vm10.bullet.mail.bf1.yahoo.com [216.109.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id DB0691A012A for ; Fri, 7 Mar 2014 14:13:41 -0800 (PST) Received: from [98.139.215.142] by nm49.bullet.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 22:13:37 -0000 Received: from [98.139.212.220] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 22:13:37 -0000 Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 22:13:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 190018.46511.bm@omp1029.mail.bf1.yahoo.com Received: (qmail 69324 invoked by uid 60001); 7 Mar 2014 22:13:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394230417; bh=C8nHmXrmTpxObQ+vAEM5de+t6RHZZF134lELSt4LZ6M=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vn1xjRkuul/arqEyNPfq51eoGpolFFz3iEvvdgktCujsHPkNQZbZ4TjdU0a4KmIoD/Tnn1T7Eo5UyWmeUilQTj2rA5JTmnhJTNYiu8oVCbofHCN9uGhNjBNuhxodRCNsp+A3Y5mqbdUqi4O8G24z0mBfdoZ3j12rJfnLMeK+hoQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dFfMH0cHRJfMe99cpmneLTu+SabrTvhQBjpO5iwXFCmieT0U/j3QSPzXxeL57Rxt35EnKlIiMXIeh0GjQthax6KoE7nlGB2SwaMC/0WXyZgnXaCeYIuhmaNse8UvPBEkSTNzt76l071RfYP72eDt/syT1Wh0GQ8dkw58gTdLSVE=; X-YMail-OSG: rW3c_QsVM1lATomZ64QXnGfdK_.9GiX0WJRZOcS6ix7aDpP .QWsIs5lqcwqMVYoZf.oKVjIym5T0ILbWBvY0B3NqquL7Si8aAk3RNRNSeMc Pn76omi8tAwCSp1T4Xg453Ls41Vpci0Ife1IWIP5fJra7U3Ue6Xp42x_3DTx aPv8Xtm2w0CeZG7rUAQ1X2UPUcLXEnn.JJKFO34W0a3ckgyf1iqlZKX2VrL3 BMJ9hGhIVL7WuIOi4e.68oSAVQ8D04PqhYLlDmdTVPYnJXkiOSM9s1lNLj6y eFMdlVNC7ItAD64ndO9cYJ4xqBu1lG34DP_W7zUeFoeBcsiVpxOl1a8QfdKu R0Y38aa4grr7t7Mkrmy5ZNThFvt6Xn_c7bzdKrEL1759nJgnO05UQx9O1Dyc dvMfE5elcm8KKeSX6dUg9LLErRa4uljTmn9iMNlHMuWpgqrrcmgCbnRLSNtY AD2czNI6mib1kadeo3Q_vMB8DeBkXJt1qtDrekEVk.SIc5Jq4ceOdKFQj01a xW2iIuG65YofuUNpgGInGHbUTE0ULA1z8.FPU27yQrkdyrvNPKulgJ96fycG CMISP1h90S72hUHsUMm7WRrKZSYo8f.dH3SkkqmttIpy6c55h5moDa8OLpjv r3.WJTSHjWuT4mQ0GOOyqLzsw.LWARFSSPbZla2UD9hY2GQrijl7P.m6RahS YWmTw9POvqq_tSqTPXWbvFqaDL3EChk7NhVLjty_4sryB.g-- Received: from [77.108.153.219] by web142805.mail.bf1.yahoo.com via HTTP; Fri, 07 Mar 2014 14:13:36 PST X-Rocket-MIMEInfo: 002.001, U28gY2FuIHdlIHNheSB0aGF0IHRoZSB2YWx1ZSBpbiAidXNlciIgbXVzdCBhZ3JlZSB3aXRoIHRoZSB1c2VyIGFzc2VydGVkIGJ5IHRoZSB0b2tlbj8KClNlbnQgZnJvbSBZYWhvbyBNYWlsIG9uIEFuZHJvaWQKCgEwAQEBAQ-- X-Mailer: YahooMailAndroidMobile/3.0.5 YahooMailWebService/0.8.177.636 Message-ID: <1394230416.68245.YahooMailAndroidMobile@web142805.mail.bf1.yahoo.com> Date: Fri, 7 Mar 2014 14:13:36 -0800 (PST) From: Bill Mills To: Nico Williams , "Nordgren, Bryce L -FS" , "Cantor, Scott" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1583497461-805048539-1394230416=:68245" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/IzAakIOOqGJ8QEo722s2D0uOapI Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 22:13:44 -0000 --1583497461-805048539-1394230416=:68245 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So can we say that the value in "user" must agree with the user asserted by= the token?=0A=0ASent from Yahoo Mail on Android=0A=0A --1583497461-805048539-1394230416=:68245 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

So can we say that the value in "user" must agree with t= he user asserted by the token?

=0A

Sent from Yahoo Mail on Android<= /a>

=0A
=0A =
=0A
=0A
=0A =
=0A =
=0A =0A = From:=0A = =0A Cantor, Scott <canto= r.2@osu.edu>;
=0A = =0A = To:=0A =0A = Nico Williams <nico@cryptonector.com>; Nordgren, Bryce L -FS <bno= rdgren@fs.fed.us>; <= br>=0A =0A Cc:=0A = =0A kitten@ietf.org <kitten@ietf.org>; = =0A =0A Subject:=0A = =0A Re: [kitten] On SASL's authzid =
=0A =0A = Sent:=0A = =0A Fri, Mar 7, 2014 10:06:= 55 PM
=0A
=0A =
=0A =0A = =0A =0A = =0A = =0A =0A
On 3/7/14, 4:58 PM, "Nico Willi= ams" <nico@cryptonector.com> wrote:

>In any case, it does seem clear now that user= =3D _is_ the same as
>authzid.=A0 So we don't have= to spend any more effort thinking about the
>above (t= hough arguably we should).

It's be= en clear to some people at times, but I have yet to hear real
confirmation from the people with the use case as to whether that'= s true
as a whole, or as to whether *some* of the use cas= es for the user hint
align but others don't.

I'm only saying this because I'm on th= e list and I fear another long round
of hashing and thras= hing to get back to the same unclear endpoint. If I'm
tired = of it, I can't imagine how the principals are.

-- Scott



_________________________= ______________________
Kitten mailing list
Kitten@ietf.org
https://www.i= etf.org/mailman/listinfo/kitten
=0A
=0A =
=0A
=0A --1583497461-805048539-1394230416=:68245-- From nobody Fri Mar 7 14:19:24 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B467C1A0128 for ; Fri, 7 Mar 2014 14:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldFwecPrgJO7 for ; Fri, 7 Mar 2014 14:19:20 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id CB6E51A011C for ; Fri, 7 Mar 2014 14:19:19 -0800 (PST) Received: from mail56-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Fri, 7 Mar 2014 22:19:15 +0000 Received: from mail56-tx2 (localhost [127.0.0.1]) by mail56-tx2-R.bigfish.com (Postfix) with ESMTP id D728312023A; Fri, 7 Mar 2014 22:19:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.208; KIP:(null); UIP:(null); IPV:NLI; H:cio-krc-pf01; RD:none; EFVD:NLI X-SpamScore: 4 X-BigFish: VPS4(zzbb2dI98dI9371Id799hzz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24d7h2516h2545h255eh25cch25f6h2605h1b1cn1b1bi1155h) Received-SPF: pass (mail56-tx2: domain of osu.edu designates 164.107.81.208 as permitted sender) client-ip=164.107.81.208; envelope-from=cantor.2@osu.edu; helo=cio-krc-pf01 ; cio-krc-pf01 ; Received: from mail56-tx2 (localhost.localdomain [127.0.0.1]) by mail56-tx2 (MessageSwitch) id 1394230752873184_11326; Fri, 7 Mar 2014 22:19:12 +0000 (UTC) Received: from TX2EHSMHS011.bigfish.com (unknown [10.9.14.242]) by mail56-tx2.bigfish.com (Postfix) with ESMTP id C6DA520007E; Fri, 7 Mar 2014 22:19:12 +0000 (UTC) Received: from cio-krc-pf01 (164.107.81.208) by TX2EHSMHS011.bigfish.com (10.9.99.111) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 7 Mar 2014 22:19:12 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-krc-pf01 (Postfix) with ESMTPS id 90407A0060; Fri, 7 Mar 2014 17:19:11 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.03.0174.001; Fri, 7 Mar 2014 17:19:11 -0500 From: "Cantor, Scott" To: Bill Mills , Nico Williams , "Nordgren, Bryce L -FS" Thread-Topic: [kitten] On SASL's authzid Thread-Index: AQHPOanJU7MgJYkHMUqid6fG1ztCiJrVisiAgAB8cgCAACBAgIAAPI8AgAADUQCAAAdPAIAAEpaA//+uhgCAAFWxAP//rbuA Date: Fri, 7 Mar 2014 22:19:10 +0000 Message-ID: References: <1394230416.68245.YahooMailAndroidMobile@web142805.mail.bf1.yahoo.com> In-Reply-To: <1394230416.68245.YahooMailAndroidMobile@web142805.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.251] Content-Type: text/plain; charset="us-ascii" Content-ID: <9156689AC2B7E44C83E16D428A93DFFF@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/5Zg_bGvMgMn8KXWfH1K6Z82A_ic Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 22:19:21 -0000 On 3/7/14, 5:13 PM, "Bill Mills" wrote: >So can we say that the value in "user" must agree with the user asserted >by the token? That depends on what "agree" means. It's a policy issue. The athzid is the *asserted* identity to login as, which is NOT always what's in the token. The token is who's logging in, the authzid is who you're logging in *as* for that transaction. If by agree you mean "is authorized to act as", then yes. But that's entirely application layer business, nothing to do with the mechanism. -- Scott From nobody Fri Mar 7 14:22:13 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFE91A0128 for ; Fri, 7 Mar 2014 14:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APkWlJN-a4-B for ; Fri, 7 Mar 2014 14:22:07 -0800 (PST) Received: from nm25-vm0.bullet.mail.bf1.yahoo.com (nm25-vm0.bullet.mail.bf1.yahoo.com [98.139.213.156]) by ietfa.amsl.com (Postfix) with ESMTP id 984E71A011C for ; Fri, 7 Mar 2014 14:22:07 -0800 (PST) Received: from [98.139.212.151] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 22:22:03 -0000 Received: from [98.139.212.245] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 22:22:03 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 07 Mar 2014 22:22:03 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 78962.97097.bm@omp1054.mail.bf1.yahoo.com Received: (qmail 1871 invoked by uid 60001); 7 Mar 2014 22:22:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394230922; bh=FefowAIczxX7LTeRQML7pJHa9X8KNj7ozLp3Aqigz7Y=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YZ/XOx/mHD2M/koHhflckE6lOh4EKv5V57B0M9RKvKGMFeV3YKKyJYRUUZFnf419UQl5+YdncBMQDIjv8W1nhpIq/Kd1PzKiRaUHozYUVrxKI+APHwQ6WbIdYPCSS1o6RMo1dfOtdou8BdUrJvQic7FoCmUQRfmvJBMIReVZjjw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=o3cNBqX0y2jc/CCoJOLVaxZ8HcMo5p9eAiBoJY863D6m5dg5FhTlFwlc8k3hRfDs51l0O8JIMaALEviJ/7HQGUMiBZGtvMZMk4C8ykbKINRgT74GpqHKm+n3k365igCUcCmN47kdc/AN7jr0b+FVX+HVhEODjrEOBXIWMQU31FQ=; X-YMail-OSG: 2eHfhVgVM1mVPBdXSgD.5g8IeXKvkH9qpdaSYuQbX4qczZw smZxTVosF952eWMfcUUFK1TvIWI3q5QevUNJST9ZtaXm4WYDPySSJLwpAQY6 6aPc8Pki73E1ucI_AahFCE0uW7JaGi8YAMI6P4XPbG7af9vU70Z1Z_Ov6OAx vLEZPjgsvHDh.szphoBon4H.t55GYc2SDXCAp9QykYAvj_yG_6c.dHkWxSJ3 o6S585u2Kq2BMy3pEe_gfPoMcA6byH6bhBdf6qbGAX_0Cm6HmDne7IckVCoS 9oLR9qC10Z_uTGY5vAvwkI_6JubvXZF0JoChkqgjKANKf4ykEVmDsJuqbGqt VpOMfelTgapAdab3G1PiXCc8RxUXMavn7.nSNFBfb3Dc1GIbARefkuIPfDAj Px8OXF8s0kWt_oajvFoEi4tPlVbRrkz6IEC8_tg1PltWaGEWULnuaI97bbsT rNe5j_yNb8mDYnVnjdfMxiBbMWgL.1BkR8CRjYEdsuxSEQQOMVjvsjuUesgj wnK2ixhMrHDf42Gk2BBvZbMYfA7xF7Tajn1we74JLixClGP0JZnTm_SEaRqS _D6zG8AZPvY21IgydkMiixB4ahJtihvuR91emdN5EK50DHba3eMxzWx3Cjae 1VgkMJBZrZmsrVHMMwnbq.MvG4Tfi2rhQ5HKs.q3ZlP5iheLGvGdBQxcHHfM TqI0moW30SNcWadoeMq5r63Opxa6py_FedgH94HNgxig- Received: from [217.36.79.41] by web142803.mail.bf1.yahoo.com via HTTP; Fri, 07 Mar 2014 14:22:02 PST X-Rocket-MIMEInfo: 002.001, VGhlbiB1c2VyIGlzbid0IGF1dHppZCBpdCdzIGF1dGhjaWQuCgpTZW50IGZyb20gWWFob28gTWFpbCBvbiBBbmRyb2lkCgoBMAEBAQE- X-Mailer: YahooMailAndroidMobile/3.0.5 YahooMailWebService/0.8.177.636 Message-ID: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> Date: Fri, 7 Mar 2014 14:22:02 -0800 (PST) From: Bill Mills To: Nico Williams , "Nordgren, Bryce L -FS" , "Cantor, Scott" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="905790552-645019489-1394230922=:9009" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mL3Msj9b4PEVvtLgWdboqPUxSj0 Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 22:22:11 -0000 --905790552-645019489-1394230922=:9009 Content-Type: text/plain; charset=us-ascii Then user isn't autzid it's authcid. Sent from Yahoo Mail on Android --905790552-645019489-1394230922=:9009 Content-Type: text/html; charset=us-ascii

Then user isn't autzid it's authcid.

Sent from Yahoo Mail on Android


From: Cantor, Scott <cantor.2@osu.edu>;
To: Bill Mills <wmills_92105@yahoo.com>; Nico Williams <nico@cryptonector.com>; Nordgren, Bryce L -FS <bnordgren@fs.fed.us>;
Cc: kitten@ietf.org <kitten@ietf.org>;
Subject: Re: [kitten] On SASL's authzid
Sent: Fri, Mar 7, 2014 10:19:10 PM

On 3/7/14, 5:13 PM, "Bill Mills" <wmills_92105@yahoo.com> wrote:

>So can we say that the value in "user" must agree with the user asserted
>by the token?

That depends on what "agree" means. It's a policy issue.

The athzid is the *asserted* identity to login as, which is NOT always
what's in the token. The token is who's logging in, the authzid is who
you're logging in *as* for that transaction.

If by agree you mean "is authorized to act as", then yes. But that's
entirely application layer business, nothing to do with the mechanism.


-- Scott
--905790552-645019489-1394230922=:9009-- From nobody Mon Mar 10 10:21:43 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED9F1A0694 for ; Mon, 10 Mar 2014 10:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTOehHUn0Z_o for ; Mon, 10 Mar 2014 10:21:40 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id D2EE01A066C for ; Mon, 10 Mar 2014 10:21:39 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id w8so7365390qac.27 for ; Mon, 10 Mar 2014 10:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fu/k8HNEuRuAmFDgwT7TCavog3GrlMzPj2L2O51yMRY=; b=RxL+e2I0dijqjJUrMAZJjGOK6d3htsDdLI5eG3bpJxR5LkUUeZQ9jsIsEjnPKaBWiL 84igt4foJftrzMeEKU8uOsH2RBKhgXPH15wE8q1UjVNYJG9LO3iZq4sJlSgBr6zRoABt is2J2Nei688sst4H9xdfJzCKZiWhBkRfYhB94= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fu/k8HNEuRuAmFDgwT7TCavog3GrlMzPj2L2O51yMRY=; b=kAQ5fejlEoV15VJVY9Q76Gpwhdh6yJ5YSTECDYPbCaR64Gs8YK+9aKuzKOIJ2Z5iLE eY3E3AFoy0iwwAlWc6es1XDDaOSGt/fS/6RyHvFs0T7ppakaHFazonel/RP6CL1lawWn Zh4RCvqJSICx/Q8asVxf8ope7jX3D8n0Am4D5FWxr+WU3LluRvZRlkF5HFrR2/OC20sk 460TyQb+E06C1QEaypkaLptFzRA6+Jz1UOnzfm0oWF7n+wm/Fk8/qZUmbrkfGtJF4vnx 6YQ2qp0m4+oxuOaaHrO567Gq3Bd+2wzDp5R6UUjAzLuHKGMza+/NMZ7dbrl/+LD5a0W2 Z12w== X-Gm-Message-State: ALoCoQmUz2a/kyWkW6M7EaVDVDzrUncvTbnqS/1rad4Mj1yzZtz7s/TwwpHMulepHB6SsNYKp1/6x9LSZnsOo5i2orubMXMBawF0zn8nKKmUzYelIU/Ie88bgqrv5YwM7dl9z4Pr2R9c7aHP7pk9aF2fIFpRDXKz6tczmT1Eqqaw7ITUlABCSzSFFidsTiadbdi9t4BXV+yl MIME-Version: 1.0 X-Received: by 10.140.90.80 with SMTP id w74mr3828828qgd.96.1394472094216; Mon, 10 Mar 2014 10:21:34 -0700 (PDT) Received: by 10.229.205.197 with HTTP; Mon, 10 Mar 2014 10:21:34 -0700 (PDT) Received: by 10.229.205.197 with HTTP; Mon, 10 Mar 2014 10:21:34 -0700 (PDT) In-Reply-To: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> Date: Mon, 10 Mar 2014 10:21:34 -0700 Message-ID: From: Ryan Troll To: William Mills Content-Type: multipart/alternative; boundary=001a11c137e4d3490a04f443d50e Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/gPdzooZfzcuMfcHuNkn8f6ehwZ8 Cc: kitten@ietf.org Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 17:21:42 -0000 --001a11c137e4d3490a04f443d50e Content-Type: text/plain; charset=UTF-8 Google uses the user= field as an authzid. It identifies the mailbox being accessed, and the session terminates at the server responsible for that mailbox. In the future, if a client provided users with the ability to log in as user A and read mailbox B, we would want to know identity B. Which certainly appears to be the authzid. Scott - does this help? -R On Mar 7, 2014 2:22 PM, "Bill Mills" wrote: > Then user isn't autzid it's authcid. > > Sent from Yahoo Mail on Android > > ------------------------------ > * From: * Cantor, Scott ; > * To: * Bill Mills ; Nico Williams < > nico@cryptonector.com>; Nordgren, Bryce L -FS ; > * Cc: * kitten@ietf.org ; > * Subject: * Re: [kitten] On SASL's authzid > * Sent: * Fri, Mar 7, 2014 10:19:10 PM > > On 3/7/14, 5:13 PM, "Bill Mills" wrote: > > >So can we say that the value in "user" must agree with the user asserted > >by the token? > > That depends on what "agree" means. It's a policy issue. > > The athzid is the *asserted* identity to login as, which is NOT always > what's in the token. The token is who's logging in, the authzid is who > you're logging in *as* for that transaction. > > If by agree you mean "is authorized to act as", then yes. But that's > entirely application layer business, nothing to do with the mechanism. > > > -- Scott > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > --001a11c137e4d3490a04f443d50e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Google uses the user=3D field as an authzid.=C2=A0 It identi= fies the mailbox being accessed, and the session terminates at the server r= esponsible for that mailbox.

In the future, if a client provided users with the ability t= o log in as user A and read mailbox B, we would want to know identity B.=C2= =A0 Which certainly appears to be the authzid.

Scott - does this help?

-R

On Mar 7, 2014 2:22 PM, "Bill Mills" &= lt;wmills_92105@yahoo.com>= wrote:

Then user isn't autzid it's authcid.

Sent from Yahoo Mail on Android


From: Cantor, Scott <cantor.2@osu.edu>; =
To: Bill Mills <wmills_92105@yahoo.com>; Nico Williams &= lt;nico@cryptone= ctor.com>; Nordgren, Bryce L -FS <bnordgren@fs.fed.us>; =
Cc: kitten@ietf.org <kitten@ietf.org>; =
Subject: Re: [kitten] On SASL's authzid =
Sent: Fri, Mar 7, 2014 10:19:10 PM =

On 3/7/14, 5:13 = PM, "Bill Mills" <wmills_92105@yahoo.com= > wrote:

>So can we say that the= value in "user" must agree with the user asserted
>by the token?

That depends on what= "agree" means. It's a policy issue.

The athzid is the *asserted* identity to login as, which is NO= T always
what's in the token. The token is who's logging in, the authzid is = who
you're logging in *as* for that transaction.

If by agree you mean "is authorized t= o act as", then yes. But that's
entirely application layer business, nothing to do with the mechanism.
=

-- Scott

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

--001a11c137e4d3490a04f443d50e-- From nobody Mon Mar 10 10:27:08 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDA01A06B8 for ; Mon, 10 Mar 2014 10:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcrfDMctr0ZK for ; Mon, 10 Mar 2014 10:27:03 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id A82601A06B2 for ; Mon, 10 Mar 2014 10:27:02 -0700 (PDT) Received: from mail161-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE022.bigfish.com (10.43.70.79) with Microsoft SMTP Server id 14.1.225.22; Mon, 10 Mar 2014 17:26:57 +0000 Received: from mail161-ch1 (localhost [127.0.0.1]) by mail161-ch1-R.bigfish.com (Postfix) with ESMTP id E06372000FA; Mon, 10 Mar 2014 17:26:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.208; KIP:(null); UIP:(null); IPV:NLI; H:cio-krc-pf01; RD:none; EFVD:NLI X-SpamScore: 4 X-BigFish: VPS4(zzbb2dI98dI9371Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24d7h2516h2545h255eh25cch25f6h2605h1b1cn1b1bi1155h) Received-SPF: pass (mail161-ch1: domain of osu.edu designates 164.107.81.208 as permitted sender) client-ip=164.107.81.208; envelope-from=cantor.2@osu.edu; helo=cio-krc-pf01 ; cio-krc-pf01 ; Received: from mail161-ch1 (localhost.localdomain [127.0.0.1]) by mail161-ch1 (MessageSwitch) id 1394472407715695_21668; Mon, 10 Mar 2014 17:26:47 +0000 (UTC) Received: from CH1EHSMHS032.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail161-ch1.bigfish.com (Postfix) with ESMTP id A9AC42602FC; Mon, 10 Mar 2014 17:26:47 +0000 (UTC) Received: from cio-krc-pf01 (164.107.81.208) by CH1EHSMHS032.bigfish.com (10.43.70.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 10 Mar 2014 17:26:46 +0000 Received: from CIO-KRC-HT02.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-krc-pf01 (Postfix) with ESMTPS id 90421A0069; Mon, 10 Mar 2014 13:26:45 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.03.0174.001; Mon, 10 Mar 2014 13:26:45 -0400 From: "Cantor, Scott" To: Ryan Troll , William Mills Thread-Topic: [kitten] On SASL's authzid Thread-Index: AQHPOanJU7MgJYkHMUqid6fG1ztCiJrVisiAgAB8cgCAACBAgIAAPI8AgAADUQCAAAdPAIAAEpaA//+uhgCAAFWxAP//rbuAgABUoACABFJIAP//zyiA Date: Mon, 10 Mar 2014 17:26:44 +0000 Message-ID: References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.26] Content-Type: text/plain; charset="us-ascii" Content-ID: <8012A40E7C4CAD458D5A594AE537A2CE@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/947SWpzn_Xer5HUW7LOstpQsxpw Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 17:27:06 -0000 On 3/10/14, 1:21 PM, "Ryan Troll" wrote: >Google uses the user=3D field as an authzid. It identifies the mailbox >being accessed, and the session terminates at the server responsible for >that mailbox. >In the future, if a client provided users with the ability to log in as >user A and read mailbox B, we would want to know identity B. Which >certainly appears to be the authzid. >Scott - does this help? It helps me, in the sense that both those use cases seem pretty clearly exactly what authzid is. They have literally nothing to do with OAuth or this mechanism, and would apply to any mechanism Google supported. -- Scott From nobody Mon Mar 10 10:48:45 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70D01A04B9 for ; Mon, 10 Mar 2014 10:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff_fC-qVWohS for ; Mon, 10 Mar 2014 10:48:41 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (unknown [69.163.253.179]) by ietfa.amsl.com (Postfix) with ESMTP id BC52A1A0365 for ; Mon, 10 Mar 2014 10:48:41 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 6FBAB1DE083 for ; Mon, 10 Mar 2014 10:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=D96V0elJ2YrEOTx6z5ZI rDQX2N8=; b=P9Z3rCfVooKwYx069WLVZ614i/DkrPIQMneFio8hqfiswsDGXjv2 QO12OhWjvvjToytpD4SeDOTBYuxuA2K+liac4V+wFjjkukN0yppBGZ5K2z02qbEf Dg41yQv3z9/n0Z/ovXlPRWuF6M8c7UEGPjtLE0mqrll9i/UBpEYYyjU= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 1F92C1DE081 for ; Mon, 10 Mar 2014 10:48:35 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so9069745wgg.6 for ; Mon, 10 Mar 2014 10:48:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i50aIvyfU3N7iKoEr+iCd1SbjbXBZbGmfRfNXwSJsd8=; b=UN/5VKS/o1b/zlA/kVV58y/FuSZFmnlgi9D2VjSd+70fm5Ay9vU2eS90/Z8viBINBW W1/Sa4cKBRF/yiFsS3dgT9GqciwkKHw9PYsm9zc4/KUQ24E4m7S1zSQ5utvllb4pqKOz RqeElz4Bg5LELgXghBaZZwVP04QOyB0nDneoGIGNKoQQGi/Vi0wnDr4x1o3cBIzGF0c2 9W+TOJlE/r4r1zomVAanagsUqbcgQtnlCcOpgeTLDwUwfsSpLqqX3RYDon/8ESw5lOAC 2WJC9WGmBXZdDxIsE4PNvZfBnmHpFqZieHOyrozuSK8oqF4Gev2S/Y77BjqRudIwGXyZ 2NIQ== MIME-Version: 1.0 X-Received: by 10.194.57.77 with SMTP id g13mr9640111wjq.42.1394473714731; Mon, 10 Mar 2014 10:48:34 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Mon, 10 Mar 2014 10:48:34 -0700 (PDT) In-Reply-To: References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> Date: Mon, 10 Mar 2014 12:48:34 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/_MV52l4oMHuIznqfVttyDkRwQAg Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 17:48:43 -0000 On Mon, Mar 10, 2014 at 12:26 PM, Cantor, Scott wrote: > On 3/10/14, 1:21 PM, "Ryan Troll" wrote: > >>Google uses the user= field as an authzid. It identifies the mailbox >>being accessed, and the session terminates at the server responsible for >>that mailbox. >>In the future, if a client provided users with the ability to log in as >>user A and read mailbox B, we would want to know identity B. Which >>certainly appears to be the authzid. >>Scott - does this help? > > It helps me, in the sense that both those use cases seem pretty clearly > exactly what authzid is. They have literally nothing to do with OAuth or > this mechanism, and would apply to any mechanism Google supported. Agreed. I think it's settled: user= is an authzid. Nico -- From nobody Mon Mar 10 10:57:10 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93E91A0262 for ; Mon, 10 Mar 2014 10:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.92 X-Spam-Level: X-Spam-Status: No, score=-16.92 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_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXsd9WHRCMho for ; Mon, 10 Mar 2014 10:56:57 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by ietfa.amsl.com (Postfix) with ESMTP id DBD761A04AB for ; Mon, 10 Mar 2014 10:56:57 -0700 (PDT) Received: from GQ1-EX10-CAHT14.y.corp.yahoo.com (gq1-ex10-caht14.corp.gq1.yahoo.com [10.73.119.195]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s2AHuJf5042213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Mar 2014 10:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1394474180; bh=wOBih7u+ekbq4xwWAMqJZD6ZU0/CZ/XCPz4F7kDojLE=; h=References:Date:From:Reply-To:Subject:To:CC:In-Reply-To; b=lNrQV9o0AvcTppIqlrH9N18DFolWFAoJS24nYW4p0jr11FgI25kwDDEvx5+JD4UCI NvocwRoJuyOXrlyKORrAOPXbbvNldxX4rEQlXtz4TRvGF4x4cwGxCAtBnPLpnXuFMn L8QfQXVGlVHcEN/TqmBeixXTbCyFN6FHd8BGEwTE= Received: from omp1041.mail.ne1.yahoo.com (98.138.89.249) by GQ1-EX10-CAHT14.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 10 Mar 2014 10:56:18 -0700 Received: (qmail 52218 invoked by uid 1000); 10 Mar 2014 17:56:18 -0000 Received: (qmail 21667 invoked by uid 60001); 10 Mar 2014 17:56:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1394474177; bh=miSbb2g1yl42rbHFzF9Fs2S51FSdqIWM4sheDrWQx6A=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aRDRHzNEDEjugEIzfut2ZiibrfhcNXI3i4XoyBI1Ypi75BJmrn14cWd+x7+dNO+sn3olAgLtzU7lIQFqqQBtiuBaWNOte73W/lprarTkvkNirhf88zwGOE4gFjYCvUvOOaHhCJIXpjCZ1xQWlhRlBmFP1Dwdo4IF7qqsExiT4Xc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VsymPrX2V/xV03cIsCJ4sVIfV7k3e/2tI6/rLSNT8iOnnMWvN7KR4YWkDELAcT6QWkXTdhrfytjDYvZd1des+xgQAoGUklWsMv50vKhEH1y+DzV06V3oV+EfUPgF/YpFkMMX0fvLsVCYTuzEcBFPkdyfnMU+EWuWBGMsJ0llFSw=; X-YMail-OSG: bL3A0roVM1lgUgtGNbQShAiZYDCfYTmynK6goxkwE7.blNS Jyz.ywfY2E98A9XWOGJ_a5T6OtWNVeoar54GXIwGWDg7.6QWh6pMg7BZEPdB k9DFyW2TfKQLMFSD_DGWrbT1RHdiT5NxTryyQHIO3AOQI51sZWlWj5cjN.Xo 11DUWS.TBCCjkgAlBzfq0goHOJtSpTjuCLAEKkoz7mMMVMHLmfVPiw9gWtEF 3PlHC1mwmJhfGg06mSPXMrJdPYbp9IzN.Gqr_k.VRq4tF4i7718LJ3SVbbG4 bm3hJ4cSZT6Ga6vsHnfA- Received: from [209.131.62.115] by web125601.mail.ne1.yahoo.com via HTTP; Mon, 10 Mar 2014 10:56:17 PDT X-Rocket-MIMEInfo: 002.001, QW5kIHNvIGl0IGdvZXMgaW4gYT0gaW4gdGhlIEdTMiBoZWFkZXI_CgrCoAotYmlsbAoKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpXaWxsaWFtIEouIE1pbGxzCiJQYXJhbm9pZCIgTVVYIFlhaG9vIQoKCgoKCk9uIE1vbmRheSwgTWFyY2ggMTAsIDIwMTQgMTA6NDkgQU0sIE5pY28gV2lsbGlhbXMgPG5pY29AY3J5cHRvbmVjdG9yLmNvbT4gd3JvdGU6CiAKT24gTW9uLCBNYXIgMTAsIDIwMTQgYXQgMTI6MjYgUE0sIENhbnRvciwgU2NvdHQgPGNhbnRvci4yQG9zdS5lZHU.IHdyb3RlOgo.IE8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> Message-ID: <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> Date: Mon, 10 Mar 2014 10:56:17 -0700 From: Bill Mills To: Nico Williams , "Cantor, Scott" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1981468715-491122973-1394474177=:99427" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 474180002 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/fxN_2jj5eCIwAHIbGZRr4suVpsM Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 17:57:00 -0000 ---1981468715-491122973-1394474177=:99427 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And so it goes in a=3D in the GS2 header?=0A=0A=A0=0A-bill=0A=0A=0A=0A-----= ---------------------------=0AWilliam J. Mills=0A"Paranoid" MUX Yahoo!=0A= =0A=0A=0A=0A=0AOn Monday, March 10, 2014 10:49 AM, Nico Williams wrote:=0A =0AOn Mon, Mar 10, 2014 at 12:26 PM, Cantor, Scott = wrote:=0A> On 3/10/14, 1:21 PM, "Ryan Troll" wrote:=0A>=0A>>Google uses the user=3D field as an authzid.=A0 I= t identifies the mailbox=0A>>being accessed, and the session terminates at = the server responsible for=0A>>that mailbox.=0A>>In the future, if a client= provided users with the ability to log in as=0A>>user A and read mailbox B= , we would want to know identity B.=A0 Which=0A>>certainly appears to be th= e authzid.=0A>>Scott - does this help?=0A>=0A> It helps me, in the sense th= at both those use cases seem pretty clearly=0A> exactly what authzid is. Th= ey have literally nothing to do with OAuth or=0A> this mechanism, and would= apply to any mechanism Google supported.=0A=0AAgreed.=A0 I think it's sett= led: user=3D is an authzid.=0A=0ANico=0A=0A--=0A=0A________________________= _______________________=0AKitten mailing list=0AKitten@ietf.org=0Ahttps://w= ww.ietf.org/mailman/listinfo/kitten ---1981468715-491122973-1394474177=:99427 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
And so it= goes in a=3D in the GS2 header?
 
-bill


=
--------------------------------
William J. Mills
"Paranoid" MUX Yah= oo!



On Monday,= March 10, 2014 10:49 AM, Nico Williams <nico@cryptonector.com> wrote= :
On Mon, Mar 10, 2014 a= t 12:26 PM, Cantor, Scott <cantor.2@osu.edu> wrote:
> On 3/10/14, 1:21 PM, "Ryan Troll" <rtroll@= googlers.com> wrote:
>
>&g= t;Google uses the user=3D field as an authzid.  It identifies the mail= box
>>being accessed, and the session terminates at= the server responsible for
>>that mailbox.
>>In the future, if a client provided users with the abili= ty to log in as
>>user A and read mailbox B, we wou= ld want to know identity B.  Which
>>certainly= appears to be the authzid.
>>Scott - does this hel= p?
>
> It helps me, in the sense = that both those use cases seem pretty clearly
> exactly what authzid is. They have l= iterally nothing to do with OAuth or
> this mechanism,= and would apply to any mechanism Google supported.

Agreed.  I think it's settled: user=3D is an authzid.
Nico

--

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


---1981468715-491122973-1394474177=:99427-- From nobody Mon Mar 10 11:03:53 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654031A0685 for ; Mon, 10 Mar 2014 11:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igCkEH9yS8S1 for ; Mon, 10 Mar 2014 11:03:47 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABFF1A0670 for ; Mon, 10 Mar 2014 11:03:47 -0700 (PDT) Received: from mail191-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.22; Mon, 10 Mar 2014 18:03:41 +0000 Received: from mail191-va3 (localhost [127.0.0.1]) by mail191-va3-R.bigfish.com (Postfix) with ESMTP id 80842440085; Mon, 10 Mar 2014 18:03:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.220; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf06; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h1b1cn1b1bi1155h) Received-SPF: pass (mail191-va3: domain of osu.edu designates 164.107.81.220 as permitted sender) client-ip=164.107.81.220; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf06 ; cio-tnc-pf06 ; Received: from mail191-va3 (localhost.localdomain [127.0.0.1]) by mail191-va3 (MessageSwitch) id 1394474620222106_11413; Mon, 10 Mar 2014 18:03:40 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.236]) by mail191-va3.bigfish.com (Postfix) with ESMTP id 2D1372C024A; Mon, 10 Mar 2014 18:03:40 +0000 (UTC) Received: from cio-tnc-pf06 (164.107.81.220) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 10 Mar 2014 18:03:40 +0000 Received: from CIO-TNC-HT07.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-tnc-pf06 (Postfix) with ESMTPS id 88D7A3C007B; Mon, 10 Mar 2014 14:00:12 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.03.0174.001; Mon, 10 Mar 2014 14:03:38 -0400 From: "Cantor, Scott" To: Bill Mills , Nico Williams Thread-Topic: [kitten] On SASL's authzid Thread-Index: AQHPOanJU7MgJYkHMUqid6fG1ztCiJrVisiAgAB8cgCAACBAgIAAPI8AgAADUQCAAAdPAIAAEpaA//+uhgCAAFWxAP//rbuAgABUoACABFJIAP//zyiAAAcMbwAAAET+gP//z8SA Date: Mon, 10 Mar 2014 18:03:37 +0000 Message-ID: References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> In-Reply-To: <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.26] Content-Type: text/plain; charset="us-ascii" Content-ID: <56C06A078BC09E43A654681BED4BFC64@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/EXNFh52TyOCh6Hp94eW2ldLiTY4 Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 18:03:49 -0000 On 3/10/14, 1:56 PM, "Bill Mills" wrote: > >And so it goes in a=3D in the GS2 header? If the plan is to maintain the GS2 framing (I lost track of that), then it's not clear anything has to be said at all, since that's basically defined by GS2 and is independent of whatever mechanism is using GS2. If it's a SASL concept, it's a SASL concept, it doesn't have to be noted in every mechanism unless there's something special to say about it, and I don't think there is. Less is more. That's just my take. But yeah, if you want to say something about it... -- Scott From nobody Mon Mar 10 11:15:07 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4095A1A04E7 for ; Mon, 10 Mar 2014 11:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.22 X-Spam-Level: X-Spam-Status: No, score=-16.22 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, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-GceMiti9Iu for ; Mon, 10 Mar 2014 11:15:03 -0700 (PDT) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id B39681A0675 for ; Mon, 10 Mar 2014 11:15:02 -0700 (PDT) Received: from GQ1-EX10-CAHT04.y.corp.yahoo.com (gq1-ex10-caht04.corp.gq1.yahoo.com [10.73.118.83]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s2AIETNX083834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Mar 2014 11:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1394475271; bh=q5ga4b/s9aL+hvTRCZ1T7A44eJ1A7vsXdq+jfyq2d1s=; h=References:Date:From:Reply-To:Subject:To:CC:In-Reply-To; b=wVQQlaUhZmTU5GJHfmVMyQ+Q0sGOPDytf5UDnOBZGGjHozyCX3P9nyt/pD3XsttVg utNdeEIV6gaH0AfJaC4f3QmuRCWKf7rrFw0nIygco/X/7dtWX5i6Os8Ob4e2+17yvm LIjyjyVjqhwOwTb6jqLiaUkvJTM1cO1p92wPgqAA= Received: from omp1050.mail.ne1.yahoo.com (98.138.89.192) by GQ1-EX10-CAHT04.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 10 Mar 2014 11:14:29 -0700 Received: (qmail 79365 invoked by uid 1000); 10 Mar 2014 18:14:28 -0000 Received: (qmail 1777 invoked by uid 60001); 10 Mar 2014 18:14:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1394475268; bh=51RWsK7bA5k5h6RCIqxzrq2H2EiU/yNlnIiSL8N0g0Q=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iJkDvYMYyquWXoMbLyJmNc3mB11JZxdInN+YM3vT1O3NZ6vw0Y8oVj38G3Qo9WqJ9qHKGVYALrIRBKhh1AnQPZPJJWpQRItV4eXUkVYdVZux5WC8xouNpa7//HiE7PdQazhL+7PyYfux38kPdxryr8sQhLHrezqIpftW1jbuXbc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QSgqzNpWOQFClE4sTHWj5js1KqGsGkpgvez2aMneOmgv0Hu2SCPXc/rIsKkvDCs7qixVn+GHkG/o3It3y+Xxcf6CpTgVpLEDRi6B03DSTmtSPPDHkNxDQr8/CO52L1HQa7ib6aaX/vkbBDuE1eJiO59zbRRZ+vclwV2CNmytjjo=; X-YMail-OSG: I3ZWnkgVM1lvTfWHfKWeRnpEZvPqizQq2HabIOh2Z7kEknF n4EOONVTdPY_xtCjI1vr3H7GX6NDNoDJ.vk6SyO4A4OAEyDu.Ub3kVYpg8at 5UwkoCOdLTdqYrMNl7L9md7PIDGcJYL1pYP5VoGiUYVEsJ6W0OslFNizbPiO pp6DBXpe9Sn1SNyV5ROzoqrJmeaNjRXN4qbDzs4lzZu_lItC5zdJUGMTwstj rzjNwhZH0VCocBnXe.MuAg7evoPPkJrkVWtgvR0ZFZ9GhNeIPPaXZrQiauyV Ct5uKFAcfB34iRQRBrJgDpADu Received: from [209.131.62.115] by web125603.mail.ne1.yahoo.com via HTTP; Mon, 10 Mar 2014 11:14:28 PDT X-Rocket-MIMEInfo: 002.001, U28gd2UgY2FuIGxlYXZlIGl0IGluIHVzZXI9IGFuZCBub3QgZGVmaW5lIGFueSBHUzIgaGVhZGVyIHN0dWZmIGJleW9uZCBtYWtpbmcgc3VyZSB0aGUgcGFyc2VycyBoYW5kbGUgaXQgaW4gdGhlIFNBU0wgc2lkZT8gCgpJIGdvdCB0aGUgaW1wcmVzc2lvbiBmcm9tIFNhbSB0aGF0IHRoZXJlJ3MgYSBjYXNlIHdoZXJlIGEgU0FTTCBtZWNoYW5pc20gdGFsa3MgdG8gYSBHUzIgc2VydmVyIGFuZCBpdCBqdXN0IHdvcmtzLsKgIFRoaXMgc291bmRlZCBsaWtlIGl0IG1lYW5zIHRoYXQgdGhlIGF1dGh6aWQgc2hvdWwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> Message-ID: <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> Date: Mon, 10 Mar 2014 11:14:28 -0700 From: Bill Mills To: "Cantor, Scott" , Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="933233344-1320578246-1394475268=:88821" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 475270004 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/meo9qJ4dSdyxJZFEznl9D-E6PGA Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 18:15:04 -0000 --933233344-1320578246-1394475268=:88821 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So we can leave it in user=3D and not define any GS2 header stuff beyond ma= king sure the parsers handle it in the SASL side? =0A=0AI got the impressio= n from Sam that there's a case where a SASL mechanism talks to a GS2 server= and it just works.=A0 This sounded like it means that the authzid should b= e populated into the S2 header.=0A=0A=0A-bill=0A=0A=0A=0A------------------= --------------=0AWilliam J. Mills=0A"Paranoid" MUX Yahoo!=0A=0A=0A=0A=0A=0A= On Monday, March 10, 2014 11:04 AM, "Cantor, Scott" wrot= e:=0A =0AOn 3/10/14, 1:56 PM, "Bill Mills" wrote:=0A= >=0A>And so it goes in a=3D in the GS2 header?=0A=0AIf the plan is to maint= ain the GS2 framing (I lost track of that), then=0Ait's not clear anything = has to be said at all, since that's basically=0Adefined by GS2 and is indep= endent of whatever mechanism is using GS2. If=0Ait's a SASL concept, it's a= SASL concept, it doesn't have to be noted in=0Aevery mechanism unless ther= e's something special to say about it, and I=0Adon't think there is. Less i= s more. That's just my take.=0A=0ABut yeah, if you want to say something ab= out it...=0A=0A=0A-- Scott --933233344-1320578246-1394475268=:88821 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So we can= leave it in user=3D and not define any GS2 header stuff beyond making sure= the parsers handle it in the SASL side?

I got the impression from = Sam that there's a case where a SASL mechanism talks to a GS2 server and it= just works.  This sounded like it means that the authzid should be po= pulated into the S2 header.

-bill


---------------= -----------------
William J. Mills
"Paranoid" MUX Yahoo!


On Monday, March 10, 2014 11:04 = AM, "Cantor, Scott" <cantor.2@osu.edu> wrote:
On 3/10/14, 1:56 PM, "Bill Mills" <wmills@yahoo-inc.com> wrote:
>
>And so it goes in a=3D in the GS2 header?

If the plan is to maintain the GS2 framing (I lost tr= ack of that), then
it's not clear anything has to be said= at all, since that's basically
defined by GS2 and is ind= ependent of whatever mechanism is using GS2. If
it's a SA= SL concept, it's a SASL concept, it doesn't have to be noted in
every mechanism unless there's something special to say about it, an= d I
don't think there is. Less is more. That's just my take.

But yeah, if you want to say something about it...


= -- Scott



=
--933233344-1320578246-1394475268=:88821-- From nobody Mon Mar 10 11:22:31 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC53C1A04E7 for ; Mon, 10 Mar 2014 11:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6Ocq29jakNS for ; Mon, 10 Mar 2014 11:22:28 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3EF1A06B8 for ; Mon, 10 Mar 2014 11:22:26 -0700 (PDT) Received: from mail209-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Mon, 10 Mar 2014 18:22:20 +0000 Received: from mail209-tx2 (localhost [127.0.0.1]) by mail209-tx2-R.bigfish.com (Postfix) with ESMTP id 62435C8015E; Mon, 10 Mar 2014 18:22:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.214; KIP:(null); UIP:(null); IPV:NLI; H:cio-krc-pf07; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24ach24d7h2516h2545h255eh259ch25cch25f6h2605h1b1cn1b1bi1155h) Received-SPF: pass (mail209-tx2: domain of osu.edu designates 164.107.81.214 as permitted sender) client-ip=164.107.81.214; envelope-from=cantor.2@osu.edu; helo=cio-krc-pf07 ; cio-krc-pf07 ; Received: from mail209-tx2 (localhost.localdomain [127.0.0.1]) by mail209-tx2 (MessageSwitch) id 1394475738769638_18938; Mon, 10 Mar 2014 18:22:18 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.249]) by mail209-tx2.bigfish.com (Postfix) with ESMTP id B7E88A400A3; Mon, 10 Mar 2014 18:22:18 +0000 (UTC) Received: from cio-krc-pf07 (164.107.81.214) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 10 Mar 2014 18:22:16 +0000 Received: from CIO-TNC-HT07.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-krc-pf07 (Postfix) with ESMTPS id 6FA76500072; Mon, 10 Mar 2014 14:22:12 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.03.0174.001; Mon, 10 Mar 2014 14:22:08 -0400 From: "Cantor, Scott" To: Bill Mills , Nico Williams Thread-Topic: [kitten] On SASL's authzid Thread-Index: AQHPOanJU7MgJYkHMUqid6fG1ztCiJrVisiAgAB8cgCAACBAgIAAPI8AgAADUQCAAAdPAIAAEpaA//+uhgCAAFWxAP//rbuAgABUoACABFJIAP//zyiAAAcMbwAAAET+gP//z8SAgAA1UAD//8/aAA== Date: Mon, 10 Mar 2014 18:22:07 +0000 Message-ID: References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> In-Reply-To: <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.26] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/GCX61fx_bWhbRdC120igVkM7TcI Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 18:22:29 -0000 On 3/10/14, 2:14 PM, "Bill Mills" wrote: > >So we can leave it in user=3D and not define any GS2 header stuff beyond >making sure the parsers handle it in the SASL side? No, I'm saying you leave it out and let GS2 handle it, because it already is. >I got the impression from Sam that there's a case where a SASL mechanism >talks to a GS2 server and it just works. This sounded like it means that >the authzid should be populated into the S2 header. Yes. But that means you need to say nothing about it, unless I'm missing something. You simply define in terms of GS2, so anything GS2 allows or requires is there by definition. That all assumes there's still a refernce to GS2 planned here. If that's being tabled due to the lack of mutual-auth, and you're defining essentially a GS2-like header that is compatible with it but not formally GS2, then you would have to define it in this spec. -- Scott From nobody Mon Mar 10 11:26:36 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AE31A03FC for ; Mon, 10 Mar 2014 11:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.92 X-Spam-Level: X-Spam-Status: No, score=-16.92 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_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqCc61qhHmqs for ; Mon, 10 Mar 2014 11:26:34 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id 116591A048A for ; Mon, 10 Mar 2014 11:26:34 -0700 (PDT) Received: from GQ1-EX10-CAHT09.y.corp.yahoo.com (gq1-ex10-caht09.corp.gq1.yahoo.com [10.87.93.108]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s2AIQ9bh010840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Mar 2014 11:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1394475969; bh=Y+BOYnlVijTrYVw3A3id8QSBIJR5f/WMY5Ri0P2+ErA=; h=References:Date:From:Reply-To:Subject:To:CC:In-Reply-To; b=u4yMHqy6AhUEthlyTkDJHz6MpeuDP8K8tDlJ/liJPrzQU5OF0lqYZCUnU6CKG4omX 0NO95+z6kbpzW0x5n+VpzM4cggfcHQEMHKrjzUddrRuLqsZH8a4IBLUN6UWbxC/rVF q96PddfLZ8JTEKc8JvAivUWV01TiDnBSCSZRjeEc= Received: from omp1028.mail.ne1.yahoo.com (98.138.89.172) by GQ1-EX10-CAHT09.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 10 Mar 2014 11:26:07 -0700 Received: (qmail 12803 invoked by uid 1000); 10 Mar 2014 18:26:07 -0000 Received: (qmail 80846 invoked by uid 60001); 10 Mar 2014 18:26:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1394475967; bh=41b7VKOfwqaQv1DcXFjvd+9EkYkIGXGWCz9SEMAHs1E=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EBiPXKw03CELFqJ9E39/pdifgXQzqEQnkH6Kza5O8HQco5iBvsE7WnB9YT0dZsr3zl7vrdLCjaXPJ3R/dYNETgW1+EGH/wNKH2rec2RKSmtbwSNyjFsy45+jQaC/uJKxC2Jej6P3zM1QwvCXX6kBKo7QgbGSLPjx94tKgdfKNLE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GEfUmfqJ4XbatxLJ+xYThOC6uIHEOWB2TrGf37OPaEli32hIm9yUddtaeMXGP8obqWqIyfDREM2QvXlp2ANO2A2RO2osUdDiMn6Bevx7504adbSJb0Nshl/1nSGEuaZ72FdHFrbTUgyQSdNox+/RsLtNzrkeu0rp+c82CRVC2bc=; X-YMail-OSG: V3kpCn8VM1ncww3pXJ9pFmnRztkSz6pWFV6rhdew94Bk8V9 sTDMBP7.Q7WBtrW8HiCQFezgaPHKeUyD1YBGtVdEueczPH9WsgwQZ5aeF8ok pSS1IUCb9.bgEE9_h4pQyfjvtV6BGqhdt5ZCMaucIn2T1YCERop6s6LGbzgd Pt_unxBL.enI1dh5UGJVMdb1hKfgTKwsNWmERjXnub.t7ePtWqSM8oHe43QR Uu..SXX5pjF5yQp3VoYjPEdu_JqECnIhxnkQee_.bU9hyT6eOM4JI4YSa8o3 6rZcS.rVmG.t5vnGah6ZdaulY Received: from [209.131.62.115] by web125604.mail.ne1.yahoo.com via HTTP; Mon, 10 Mar 2014 11:26:07 PDT X-Rocket-MIMEInfo: 002.001, TXkgaW50ZW50IGlzIHRvIG9ubHkgZG8gZW5vdWdoIGhlcmUgdG8gbWFrZSBzdXJlIHRoYXQgR1MyIGludGVyb3AgY2FuIHdvcmsgaW4gdGhlIGZ1dHVyZSBzaW5jZSB0aGVyZSBhcmUgZm9sa3MgdGhhdCBjYXJlLgoKCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGxpYW0gSi4gTWlsbHMKIlBhcmFub2lkIiBNVVggWWFob28hCgoKCgoKT24gTW9uZGF5LCBNYXJjaCAxMCwgMjAxNCAxMToyMyBBTSwgIkNhbnRvciwgU2NvdHQiIDxjYW50b3IuMkBvc3UuZWR1PiB3cm90ZToBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> Message-ID: <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Mon, 10 Mar 2014 11:26:07 -0700 From: Bill Mills To: "Cantor, Scott" , Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-417484256-1394475967=:98405" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 475969001 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/90Tntu6k1u_9Th7ji-3TjZRTS4k Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 18:26:35 -0000 ---685807438-417484256-1394475967=:98405 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My intent is to only do enough here to make sure that GS2 interop can work = in the future since there are folks that care.=0A=0A=0A=A0=0A-bill=0A=0A=0A= =0A--------------------------------=0AWilliam J. Mills=0A"Paranoid" MUX Yah= oo!=0A=0A=0A=0A=0A=0AOn Monday, March 10, 2014 11:23 AM, "Cantor, Scott" wrote:=0A =0AOn 3/10/14, 2:14 PM, "Bill Mills" wrote:=0A>=0A>So we can leave it in user=3D and not define any = GS2 header stuff beyond=0A>making sure the parsers handle it in the SASL si= de?=0A=0ANo, I'm saying you leave it out and let GS2 handle it, because it = already=0Ais.=0A=0A>I got the impression from Sam that there's a case where= a SASL mechanism=0A>talks to a GS2 server and it just works.=A0 This sound= ed like it means that=0A>the authzid should be populated into the S2 header= .=0A=0AYes. But that means you need to say nothing about it, unless I'm mis= sing=0Asomething. You simply define in terms of GS2, so anything GS2 allows= or=0Arequires is there by definition.=0A=0AThat all assumes there's still = a refernce to GS2 planned here. If that's=0Abeing tabled due to the lack of= mutual-auth, and you're defining=0Aessentially a GS2-like header that is c= ompatible with it but not formally=0AGS2, then you would have to define it = in this spec.=0A=0A=0A-- Scott ---685807438-417484256-1394475967=:98405 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
My intent= is to only do enough here to make sure that GS2 interop can work in the fu= ture since there are folks that care.

&= nbsp;
-bill


--------------------------------
Willi= am J. Mills
"Paranoid" MUX Yahoo!



=
On Monday, March 10, 2014 11:23 AM, "Cantor, Scott" <cantor.2@osu.edu> wrote:
On 3/10/14, 2:14 PM, "Bill Mills" <wmills@y= ahoo-inc.com> wrote:
>
>So= we can leave it in user=3D and not define any GS2 header stuff beyond
>making sure the parsers handle it in the SASL side?

No, I'm saying you leave it out and let GS2= handle it, because it already
is.

>I got the impression from Sam that there's a case where = a SASL mechanism
>talks to a GS2 server and it just wo= rks.  This sounded like it means that
>the authzi= d should be populated into the S2 header.

Yes. But that means you need to say nothing about it, unless I'm missin= g
something. You simply define in terms of GS2, so anything G= S2 allows or
requires is there by definition.

That all assumes there's still a refernce to GS2 = planned here. If that's
being tabled due to the lack of m= utual-auth, and you're defining
essentially a GS2-like he= ader that is compatible with it but not formally
GS2, the= n you would have to define it in this spec.


-- Scott



= ---685807438-417484256-1394475967=:98405-- From nobody Mon Mar 10 11:49:56 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C5B1A0564 for ; Mon, 10 Mar 2014 11:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10F1y_zMRZPA for ; Mon, 10 Mar 2014 11:49:53 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0C80A1A050E for ; Mon, 10 Mar 2014 11:49:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 4AA91206B1 for ; Mon, 10 Mar 2014 14:45:07 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0IgZkSc_wNA for ; Mon, 10 Mar 2014 14:45:06 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Mon, 10 Mar 2014 14:45:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3398383F8E; Mon, 10 Mar 2014 14:49:46 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org Date: Mon, 10 Mar 2014 14:49:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/H2JPCN9eE_H3X0nncvrhvOdTnPI Subject: [kitten] comments on draft-ietf-kitten-sasl-saml-ec X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 18:49:55 -0000 I've reviewed the SAML EC draft. It was easy to read, and I appreciate the work that has gone into it. I would prefer to wait for responses to these comments prior to issuing a WG LC. I request review of these comments from the Kerberos community as well as the SAML EC community. I have not closely read the SAML and SAML ECP specifications, and as a result I cannot provide sufficient review of the overall security and interoperability of this mechanism. We will need review of that from folks other than the authors prior to progressing the specification. I cannot promise doing that additional review in a timely manner. Section 1: A reference to the discovery/WAYF problem would be desirable but is not required. Section 3: In this mechanism, the client does not send the response to the RP at a location of the IDP's choosing but instead sends to a location of the client's choosing through SASL. What are the implications of this? I guess one is the attack Jim brought up and we discussed in ABFAB. In the section on interactions with the IDP, there is no mandatory-to-implement mechanism specified for finding an IDP. I'd appreciate comments from the WG on whether this lack is a problem in terms of guaranteeing that two implementations of this mechanism will be interoperable. Should we require something like support for static configuration of an IDP? Section 5: SASL has an idea of mutual authentication. It seems like the same checks that apply to GSS-API should apply to SASL mutual auth too. The checks in section 5 seem inadequate. In particular, it seems like it should matter what identity is used to digitally sign the request, and the validity of the signature should matter. > If the mutual_state flag is not requested, or is not set, then the > security layer managed by the application outside of the GSS-API > mechanism is responsible for authenticating the acceptor. In this > case, applications MUST match the server identity from the existing > security layer with the target name. For TLS, this matching MUST be > performed as discussed in [RFC6125]. For SSH, this matching MUST be > performed as discussed in [RFC4462]. This text places normative requirements on applications using this mechanism. That's not reasonable because applications may have no knowledge of this mechanism. What happens if these checks are not performed? Section 5.1 seems applicable to SASL as well. It doesn't sound like section 5.1 provides enough guidance to provide interoperability between multiple implementations of delegation to me. Section 5.3 is inconsistent with the claim in the introduction that no integrity and confidentiality layer is provided. Section 5.3. I note that this is the first time I'm aware of where RFC 3961 enctypes' names are used in a protocol. I'd like explicit review of this from the Kerberos community. Everything we have so far uses numbers. Section 5.3.1: I think encryption needs to be a MUST here. Even if CB is used there's no confidence that the channel provides confidentiality. Consider for example a TLS cipher without confidentiality, an IPsec channel for ESP-null, etc. Section 5.4: RFc 4121 has multiple keys it can use: the session key, the subsession key, and the acceptor subsession key. The text in 5.4 is insufficiently detailed for interoperability. Section 5.6.2: 1) I am not sure that the guidance here is sufficient for interoperability and security. 2) This section appears to place normative requirements on the IDP even though the specification claims not to place normative requirements on the IDP. 3) This section seems to apply to SASL. From nobody Mon Mar 10 13:27:30 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D634E1A024B for ; Mon, 10 Mar 2014 13:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnB0yHHqmaQE for ; Mon, 10 Mar 2014 13:27:25 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2431A04BC for ; Mon, 10 Mar 2014 13:27:24 -0700 (PDT) Received: from mail229-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Mon, 10 Mar 2014 20:27:19 +0000 Received: from mail229-va3 (localhost [127.0.0.1]) by mail229-va3-R.bigfish.com (Postfix) with ESMTP id 79FD2B6012B; Mon, 10 Mar 2014 20:27:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.222; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf08; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzd9hz1de098h1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24d7h2516h2545h255eh25cch25f6h2605h1b1cn1b1bi1155h) Received-SPF: pass (mail229-va3: domain of osu.edu designates 164.107.81.222 as permitted sender) client-ip=164.107.81.222; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf08 ; cio-tnc-pf08 ; Received: from mail229-va3 (localhost.localdomain [127.0.0.1]) by mail229-va3 (MessageSwitch) id 1394483236169057_10101; Mon, 10 Mar 2014 20:27:16 +0000 (UTC) Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.232]) by mail229-va3.bigfish.com (Postfix) with ESMTP id 245DF340051; Mon, 10 Mar 2014 20:27:16 +0000 (UTC) Received: from cio-tnc-pf08 (164.107.81.222) by VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 10 Mar 2014 20:27:13 +0000 Received: from CIO-KRC-HT02.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-tnc-pf08 (Postfix) with ESMTPS id 6E0462E0079; Mon, 10 Mar 2014 16:27:11 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.03.0174.001; Mon, 10 Mar 2014 16:27:11 -0400 From: "Cantor, Scott" To: Sam Hartman , "kitten@ietf.org" Thread-Topic: [kitten] comments on draft-ietf-kitten-sasl-saml-ec Thread-Index: AQHPPJGI5mV+TEdtgEiWvASeMKVPmZra1dwA Date: Mon, 10 Mar 2014 20:27:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.26] Content-Type: text/plain; charset="us-ascii" Content-ID: <89CD4B6338700D418C65FE277500B290@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/57gf9xbAZR2Df_3wUx6Xv_5SgoI Subject: Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 20:27:29 -0000 On 3/10/14, 2:49 PM, "Sam Hartman" wrote: >I've reviewed the SAML EC draft. >It was easy to read, and I appreciate the work that has gone into it. >I would prefer to wait for responses to these comments prior to issuing >a WG LC. Thank you for the review. Given the extensive comments, it's likely to take me a little time to make changes since I'm not formally allocated any time to work on this at the moment by my project. Some responses at least.... >Section 1: > >A reference to the discovery/WAYF problem would be desirable but is not >required. I'm not sure any formal reference exists, other than perhaps to the actual SAML profiles that (poorly) address it in the case of a browser. >Section 3: >In this mechanism, the client does not send the response to the RP at a >location of the IDP's choosing but instead sends to a location of the >client's choosing through SASL. >What are the implications of this? > >I guess one is the attack Jim brought up and we discussed in ABFAB. Yes, there is essentially a MITM issue if channel binding isn't done or a session key isn't established and used. >In the section on interactions with the IDP, there is no >mandatory-to-implement mechanism specified for finding an IDP. I'd >appreciate comments from the WG on whether this lack is a problem in >terms of guaranteeing that two implementations of this mechanism will be >interoperable. >Should we require something like support for static configuration of an >IDP? What does ABFAB require? I don't see that asking for a domain in and of itself makes discovery happen without more infrastructure that's presumably out of scope there. >Section 5: > >SASL has an idea of mutual authentication. >It seems like the same checks that apply to GSS-API should apply to SASL >mutual auth too. I didn't think SASL had an actual indicator of mutual-auth, but if it does, it seems like the same text is probably needed there. Otherwise I'm not sure how to work in the text. In contrast to many of the recent discussions, I'm very SASL illiterate and much more GSS "aware" I guess, if not expert. >The checks in section 5 seem inadequate. In particular, it seems like >it should matter what identity is used to digitally sign the request, >and the validity of the signature should matter. Yes, I was leaving trust out of this, but something could be said if it's helpful. [snip of TLS text] >This text places normative requirements on applications using this >mechanism. >That's not reasonable because applications may have no knowledge of this >mechanism. >What happens if these checks are not performed? That text came from some iteration of the original wording borrowed from the SAML/OpenID mechanisms, and was basically adapted. Isn't that same text, or a variant, essentially what Simon is adding to GS2? All this is saying is that if the mechanism doesn't signal mutual authentication to the initiator, then obviously it's up to the application. What else can you do? >Section 5.1 seems applicable to SASL as well. Similar question as above; is there normative machinery that can be used in SASL to regulate and signal it? I didn't think so. >It doesn't sound like section 5.1 provides enough guidance to provide >interoperability between multiple implementations of delegation to me. I could make a crack about OAuth interop here (I'll leave WS-Trust out of it, but OAuth is IETF's responsibility), but let me just say that it's sufficient to implement *a* SAML profile of delegation, and that's intended to be an extenstion point in the draft that doesn't preclude delegation while leaving the gory details out. If I were to formally specify this, it wouldn't be here because it doesn't impact the GSS work, it's purely a SAML spec. >Section 5.3 is inconsistent with the claim in the introduction that no >integrity and confidentiality layer is provided. Will fix, the intro predates all that work being added. >Section 5.3. I note that this is the first time I'm aware of where >RFC 3961 enctypes' names are used in a protocol. I'd like explicit >review of this from the Kerberos community. Everything we have so far >uses numbers. Ok, will await decision. I don't care for numbers in a text-based protocol, but if the strings aren't formalized, that's appropriate. I think I did look at the registry though and came to the conclusion they were. >Section 5.3.1: > >I think encryption needs to be a MUST here. >Even if CB is used there's no confidence that the channel provides >confidentiality. >Consider for example a TLS cipher without confidentiality, an IPsec >channel for ESP-null, etc. That's true. I can make it a MUST. >Section 5.4: RFc 4121 has multiple keys it can use: the session key, the >subsession key, and the acceptor subsession key. >The text in 5.4 is insufficiently detailed for interoperability. I'd need feedback on that, I don't have the background (and it was more or less copied, again, from some other work). >Section 5.6.2: > >1) I am not sure that the guidance here is sufficient for >interoperability and security. Possibly not security, but I'm not sure why it's not interoperable. In particular, I didn't go and require any kind of remapping of service names into URLs; that would definitely not be. As far as what it *does* for security, it binds the eventual key(s) used by the acceptor to specific service identities that the IdP can authorize a signed request on, and allows many such services to be associated with one entityID (but also allows each service to have its own, as desired). That's not perfect (the MITM thing) but it is not nothing given that a client is at least nominally connecting with specific protocols that may well be expressed as part of the service name (e.g. you at least couldn't spoof an SSH server with an HTTP/host identity) since presumably the service name is something the client isn't totally oblivious to. >2) This section appears to place normative requirements on the IDP even >though the specification claims not to place normative requirements on >the IDP. No new requirements. This is standard comparison logic all IdPs do for ECP and Web SSO. >3) This section seems to apply to SASL. Yeah, that one does. -- Scott From nobody Mon Mar 10 14:03:15 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CA81A04A6 for ; Mon, 10 Mar 2014 14:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvkHN0FsbiUL for ; Mon, 10 Mar 2014 14:03:05 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6451A04C5 for ; Mon, 10 Mar 2014 14:03:05 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2AL2wjF004015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Mar 2014 17:02:58 -0400 Received: from [10.3.113.6] ([10.3.113.6]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2AL2uvt022712; Mon, 10 Mar 2014 17:02:57 -0400 From: Simo Sorce To: Sam Hartman In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Mon, 10 Mar 2014 17:02:56 -0400 Message-ID: <1394485376.32465.28.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/nJNpshUx4KtIYpIPkD2UpFFrAC0 Cc: kitten@ietf.org Subject: Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 21:03:07 -0000 On Mon, 2014-03-10 at 14:49 -0400, Sam Hartman wrote: > Section 5: > > SASL has an idea of mutual authentication. > It seems like the same checks that apply to GSS-API should apply to SASL > mutual auth too. > > The checks in section 5 seem inadequate. In particular, it seems like > it should matter what identity is used to digitally sign the request, > and the validity of the signature should matter. > > > If the mutual_state flag is not requested, or is not set, then the > > security layer managed by the application outside of the GSS-API > > mechanism is responsible for authenticating the acceptor. In this > > case, applications MUST match the server identity from the existing > > security layer with the target name. For TLS, this matching MUST be > > performed as discussed in [RFC6125]. For SSH, this matching MUST be > > performed as discussed in [RFC4462]. > > > This text places normative requirements on applications using this mechanism. > That's not reasonable because applications may have no knowledge of this mechanism. > What happens if these checks are not performed? This text seem to echo Section 4 of RFC 6595 however I see no reference to 6595 in this draft, maybe I am missing something, this is the first time I am looking as SASL/SAML drfats, sorry. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Mon Mar 10 14:08:36 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70911A050E for ; Mon, 10 Mar 2014 14:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9s6DxnSM2NQ for ; Mon, 10 Mar 2014 14:08:22 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 356571A04C5 for ; Mon, 10 Mar 2014 14:08:22 -0700 (PDT) Received: from mail201-tx2-R.bigfish.com (10.9.14.229) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Mon, 10 Mar 2014 21:08:16 +0000 Received: from mail201-tx2 (localhost [127.0.0.1]) by mail201-tx2-R.bigfish.com (Postfix) with ESMTP id 896987401E1; Mon, 10 Mar 2014 21:08:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.218; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf04; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzd9hz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24d7h2516h2545h255eh25cch25f6h2605h1b1cn1b1bi1155h) Received-SPF: pass (mail201-tx2: domain of osu.edu designates 164.107.81.218 as permitted sender) client-ip=164.107.81.218; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf04 ; cio-tnc-pf04 ; Received: from mail201-tx2 (localhost.localdomain [127.0.0.1]) by mail201-tx2 (MessageSwitch) id 1394485694404809_19841; Mon, 10 Mar 2014 21:08:14 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.226]) by mail201-tx2.bigfish.com (Postfix) with ESMTP id 5D6B6940080; Mon, 10 Mar 2014 21:08:14 +0000 (UTC) Received: from cio-tnc-pf04 (164.107.81.218) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 10 Mar 2014 21:08:13 +0000 Received: from CIO-KRC-HT02.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-tnc-pf04 (Postfix) with ESMTPS id 43B4D38005D; Mon, 10 Mar 2014 17:08:12 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.03.0174.001; Mon, 10 Mar 2014 17:08:12 -0400 From: "Cantor, Scott" To: Simo Sorce , Sam Hartman Thread-Topic: [kitten] comments on draft-ietf-kitten-sasl-saml-ec Thread-Index: AQHPPJGI5mV+TEdtgEiWvASeMKVPmZrbEiMA///PLgA= Date: Mon, 10 Mar 2014 21:08:11 +0000 Message-ID: References: <1394485376.32465.28.camel@willson.li.ssimo.org> In-Reply-To: <1394485376.32465.28.camel@willson.li.ssimo.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.26] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/12byh_PfIz89mmd1XMgIgPoeMdw Cc: "kitten@ietf.org" Subject: Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 21:08:27 -0000 On 3/10/14, 5:02 PM, "Simo Sorce" wrote: > >This text seem to echo Section 4 of RFC 6595 however I see no reference >to 6595 in this draft, maybe I am missing something, this is the first >time I am looking as SASL/SAML drfats, sorry. It does copy that exact text, yes, but this has nothing to do with that mechanism, so there's no reference to it. The text was copied to address the cross-mechanism case of not having mutual authentication. The difference here is that you can have it at times, whereas using the browser to login will never give it to you. I am not at all wedded to that specific text, but presume something is needed, but maybe it's just a security consideration. -- Scott From nobody Mon Mar 10 14:48:24 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E521A0495 for ; Mon, 10 Mar 2014 14:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyCZjA7eBOgj for ; Mon, 10 Mar 2014 14:48:21 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE521A024B for ; Mon, 10 Mar 2014 14:48:20 -0700 (PDT) Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2ALmD80022024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Mar 2014 17:48:14 -0400 Received: from [10.3.113.6] ([10.3.113.6]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s2ALmCri004167; Mon, 10 Mar 2014 17:48:13 -0400 From: Simo Sorce To: "Cantor, Scott" In-Reply-To: References: <1394485376.32465.28.camel@willson.li.ssimo.org> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Mon, 10 Mar 2014 17:48:12 -0400 Message-ID: <1394488092.32465.30.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/juAsXTQV9gKAQQgNZYoXxDuDCPA Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 21:48:23 -0000 On Mon, 2014-03-10 at 21:08 +0000, Cantor, Scott wrote: > On 3/10/14, 5:02 PM, "Simo Sorce" wrote: > > > >This text seem to echo Section 4 of RFC 6595 however I see no reference > >to 6595 in this draft, maybe I am missing something, this is the first > >time I am looking as SASL/SAML drfats, sorry. > > It does copy that exact text, yes, but this has nothing to do with that > mechanism, so there's no reference to it. Is there a document somewhere that explains the differences ? They look pretty similar from a 30k miles view. > The text was copied to address the cross-mechanism case of not having > mutual authentication. The difference here is that you can have it at > times, whereas using the browser to login will never give it to you. I would rather not support mutual then, given you cannot guarantee it from within the mechanism. > I am not at all wedded to that specific text, but presume something is > needed, but maybe it's just a security consideration. Yes it probably should be. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Mon Mar 10 17:53:09 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764151A0671 for ; Mon, 10 Mar 2014 17:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ngXVYnhtkk2 for ; Mon, 10 Mar 2014 17:53:06 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (agjbgdcfdbhe.dreamhost.com [69.163.253.174]) by ietfa.amsl.com (Postfix) with ESMTP id E4E8B1A0670 for ; Mon, 10 Mar 2014 17:53:06 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 8869176805C for ; Mon, 10 Mar 2014 17:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=xRxSpBYz5WXkMqbf60cd xEWcF9c=; b=VBxAvLoiz2KLqIAGQ8nf4tmlFrgLNjaGcT+PgRqa51MW0PoDp7TE jyu1DCiGUYipxjreRXKwTvJULy4SDozTZFv5FJYgpE0dadfaBQAQkaVtHXHl8LPZ 3E2BytzkXULPXPgfkuipRYt3N+WS2ENGtk5G04pEU0K7QGmEUCwGD5w= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 37C18768057 for ; Mon, 10 Mar 2014 17:53:01 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t61so9430650wes.16 for ; Mon, 10 Mar 2014 17:53:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ov3/YRhUQJU9+rDdO/xHml3Q0kfocBeg+ot5X5+AaGQ=; b=bsv2tpWhuyRwS5uBybdNuQxiNeBat4Pb/8QFqWojCu0bkKzAd/qU0hofAUACwj6Z/I +2c0J0w+9qNQGOYH1y96EtFKebisngZ+nCXGwKhHbPURXRrqq8pfHnM5il/uH3QeAm34 /XI6A1DfRVrfklvim5puExVumJrr4B9iMmljtDKGOl72z8BU4Tp0aw7qGoGCLnx2+sn5 AMVu+8WbLkZSXtXzNMY9WcBpxgie8+Bfwjo1BhHVh8Isn4QSkwQ/9ThEJdMabB398YB8 bbo6CCoAsbK76eq/zU4vM+GqaG+HmikHnHy4MqjeTEziJP51Rx8z32uNyj4AlfuGcdil JMiw== MIME-Version: 1.0 X-Received: by 10.194.185.148 with SMTP id fc20mr34278414wjc.27.1394499180064; Mon, 10 Mar 2014 17:53:00 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Mon, 10 Mar 2014 17:52:59 -0700 (PDT) In-Reply-To: <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Mon, 10 Mar 2014 19:52:59 -0500 Message-ID: From: Nico Williams To: Bill Mills Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/vwTSBwP8JHqRPznqoOqpQ6ogsaw Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 00:53:07 -0000 We now agree that user= is just the authzid. Good. The only question is whether to describe user= at all. Assuming that you need it for interop with Google you have two choices: - don't use GS2 - use GS2 and shoe-horn in the user= as a name attribute at the GSS layer (or leave it for GSS implementors to figure that out?) Either works. I submitted an I-D last week for adding a GSS name attribute for conveying authzids, so it just so happens that it should be easy enough to do what you want. Let's see if we can. What does a fully formed SASL OAuth token's "header" with user= look like? Nico -- From nobody Mon Mar 10 17:59:07 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FF61A067A for ; Mon, 10 Mar 2014 17:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XB1t_TTBEcom for ; Mon, 10 Mar 2014 17:59:03 -0700 (PDT) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA941A0671 for ; Mon, 10 Mar 2014 17:59:03 -0700 (PDT) Received: from [98.139.212.151] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 00:58:57 -0000 Received: from [98.139.212.246] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 00:58:57 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 00:58:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 689905.64240.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 96597 invoked by uid 60001); 11 Mar 2014 00:58:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394499537; bh=st4nj1BDcDhjLnsft3SxA93S/rl+cW6i6Feu68HhmYw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1JkncaLEwIBs7rQCpJv69TDyPql1+RPQrZp285h3rr5rSbJedgR8aI1z7BkkSknTBpfZ0bqzXlqQiTBvIsyYgKCw+UWEcfnjEy5NtOQhUKkij/YKsksfD9pJwKPSNGJEL39glbhVnf6uGqo2V9NWLTZf7W6fFeYhUdOd0UiWGf0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Yzd+yUuvXSEQgg+FHF1WZHWCYKFxBHOgyP1jeCz3K6jYfaGF7NNlT2PEDdWm9c3Wq7Ylh4C9SdO+Kgz4IlBz7i7mJ+KEe0SmoN8IgrOfmVGYcUle/qh/1xPvu6xiEjxtDUX9+w1UmE0hBC+UTGpRbFp3hR9jiUCE7dzCzwayem0=; X-YMail-OSG: 1t1s7GUVM1kn2BYkmD.VfAQLkSg0jaafK.xxTEbAfR7IUdh 3c2iUX6ebs818ik1sPuWoWvThxWuWkv01gNm1PODrnf8coGcZRz4lLdqTi8h 5BaDXyQIAdYJwhbCT8W3vFelV8FlGWhbcyqj1dmxoW0f3ZrCye1IjUJ.FtCV 3QIzZh7ed4Ea2IMxLvBCfoGILrK36z7fBnmv1iOXVW3VHljrUQMH5nj.yJek zX8BUUmnuccbNA4bYbag.Lsp5blUyMOvAoKlkbp7YgTrdKEcPYzqI0l1mT1Q jovwcw42cUJOU7vK.jH7dclPlP0uJDd76lA7cY5cBiEB3ud7UrnJGD5VnGGL hfl65FRHYcZHXRJ1YYYMn3WDuZQA3euq26M8oij6Hikk.7LPeJFrH3PA_ZgE wyxnHsNslsoyzZcM3UNt4cnwXGClDI.HHUyr923veoV9Y2.Tj1zdc2BGyJks VbKa8NNJz532VxKBvCyWgKq.VoWd1iYa9cdcYkl3P4ufzzItghhekv4rydap P0k0wobvYt2q5gpfzxqK7MsA5rl7t86dLqgkhwpLJgQ49.tuiLwFP5KPFsUW dCmS4CDkDjnfWq7Px32cxE6sjpX2dnXo- Received: from [209.131.62.115] by web142802.mail.bf1.yahoo.com via HTTP; Mon, 10 Mar 2014 17:58:57 PDT X-Rocket-MIMEInfo: 002.001, RXhhbXBsZXMgaW7CoGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYta2l0dGVuLXNhc2wtb2F1dGgtMTQjc2VjdGlvbi00CgpEb2VzIHRoYXQgYW5zd2VyIHlvdXIgcXVlc3Rpb24_CgoKCgpPbiBNb25kYXksIE1hcmNoIDEwLCAyMDE0IDU6NTMgUE0sIE5pY28gV2lsbGlhbXMgPG5pY29AY3J5cHRvbmVjdG9yLmNvbT4gd3JvdGU6CiAKV2Ugbm93IGFncmVlIHRoYXQgdXNlcj0gaXMganVzdCB0aGUgYXV0aHppZC7CoCBHb29kLgoKVGhlIG9ubHkgcXVlc3Rpb24gaXMgd2hldGhlciB0byBkZXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> Message-ID: <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Mon, 10 Mar 2014 17:58:57 -0700 (PDT) From: Bill Mills To: Nico Williams , Bill Mills In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-537766711-1394499537=:96053" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/PyzIG5NO0haYBg7S2nqihVSeszE Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 00:59:05 -0000 --1397251415-537766711-1394499537=:96053 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Examples in=A0http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-14#se= ction-4=0A=0ADoes that answer your question?=0A=0A=0A=0A=0AOn Monday, March= 10, 2014 5:53 PM, Nico Williams wrote:=0A =0AWe no= w agree that user=3D is just the authzid.=A0 Good.=0A=0AThe only question i= s whether to describe user=3D at all.=A0 Assuming that=0Ayou need it for in= terop with Google you have two choices:=0A=0A- don't use GS2=0A=0A- use GS2= and shoe-horn in the user=3D as a name attribute at the GSS=0Alayer (or le= ave it for GSS implementors to figure that out?)=0A=0AEither works.=A0 I su= bmitted an I-D last week for adding a GSS name=0Aattribute for conveying au= thzids, so it just so happens that it should=0Abe easy enough to do what yo= u want.=A0 Let's see if we can.=A0 What does a=0Afully formed SASL OAuth to= ken's "header" with user=3D look like?=0A=0ANico=0A=0A--=0A=0A_____________= __________________________________=0AKitten mailing list=0AKitten@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/kitten --1397251415-537766711-1394499537=:96053 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Examples in http://tools.ietf.org/html/draft-= ietf-kitten-sasl-oauth-14#section-4

Does that answer your question?



On Monday, March 10, 2014 5:53 P= M, Nico Williams <nico@cryptonector.com> wrote:
<= div class=3D"y_msg_container">We now agree that user=3D is just the authzid= .  Good.

The only question is whe= ther to describe user=3D at all.  Assuming that
you = need it for interop with Google you have two choices:
- don't use GS2

- us= e GS2 and shoe-horn in the user=3D as a name attribute at the GSS
layer (or leave it for GSS implementors to figure that out?)

Either works.  I submitted an I-D last week for adding= a GSS name
attribute for conveying authzids, so it just = so happens that it should
be easy enough to do what you w= ant.  Let's see if we can.  What does a
fully f= ormed SASL OAuth token's "header" with user=3D look like?

Nico

--

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

=
--1397251415-537766711-1394499537=:96053-- From nobody Mon Mar 10 18:14:22 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A871A0675 for ; Mon, 10 Mar 2014 18:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuP-_79TwAS5 for ; Mon, 10 Mar 2014 18:14:20 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (unknown [69.163.253.172]) by ietfa.amsl.com (Postfix) with ESMTP id 03C7F1A0666 for ; Mon, 10 Mar 2014 18:14:20 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 9DB31350078 for ; Mon, 10 Mar 2014 18:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=svO22XBUd7fFiILllBJ0 clNKV2k=; b=yY0T+h9xKL2NGDy3rglWTVSN1lMGDlwCNVN+P2dqeS4gnHCl0lAI 12G4WPC6fDPLS2qdDa2QRhchZ/eGnmTVJW7IjrhU0+Yp8LHTeqrRvN2t6BvuNKVS piuUXTVbsZHKIQ0IYXWYdkL2fQTqMsWvBru1t3rRjWPWwJZHx9ejQRk= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 50042350058 for ; Mon, 10 Mar 2014 18:14:14 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so3383947wgh.5 for ; Mon, 10 Mar 2014 18:14:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IhpwtDt6z2IJI8eSyNAUUHZUs8CM1KC61djrc1fy2zI=; b=U8opxP4uBjD4FYDi61Hp8SL7poJTDn6tmAJsVvWkDxw46AhXNWbqnDZRd2Vc4BtWhX APl0INq3UWpJevspaqyCvEZwzrGTTXOjCEqD65RSX0/n4vm340iTQ/DzA0lv3B3dQtJs 1W9s4ADwcI+CdK56G6JgBXhFojetP9mxPXllOR5f78rXEAJi1RO+Dd/dj0GHH3ATXEkl iXmfo4M0R/r+xEQsYKHStbO2qectF999pKgKm8rIstrOeTfrDnLxYW83U8nap9fTQ7KU 6IIYElM1rygDuUwt10Pq/+nRlsked0D9uBo7Kd7Vxxq+yCsEsjY1T6ZizG8gZM3aMy80 XBjw== MIME-Version: 1.0 X-Received: by 10.194.6.8 with SMTP id w8mr34864600wjw.16.1394500453263; Mon, 10 Mar 2014 18:14:13 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Mon, 10 Mar 2014 18:14:13 -0700 (PDT) In-Reply-To: <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Mon, 10 Mar 2014 20:14:13 -0500 Message-ID: From: Nico Williams To: Bill Mills Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/zBKNVHHNykrmszrkPMeA8gEbzkQ Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 01:14:21 -0000 On Mon, Mar 10, 2014 at 7:58 PM, Bill Mills wrote: > Examples in > http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-14#section-4 > > Does that answer your question? Yes! You have two options that are equivalent, and you need only choose whether you want to describe a GSS mechanism that can be used as a GS2 mechanism, or a SASL mechanism from which one could derive a GSS mechanism that interops with the SASL one when used in a GS2 framework. In the first case all you have to say is that the tokens start with the GS2 header, and that if there's an authzid it will appear twice, once in the a= attribute in the GS2 header, and once in a user= attribute past the GS2 header. In the second case you'd say that the OAuth GSS mechanism's GSS_Init_sec_context() outputs a token as it would look without the GS2 header, and that if the initiator name had an authzid set then this is sent as user=. Then automatically when this mechanism is used in SASL via GS2 SASL will add the a=, and if the GS2 implementation knows to set the GSS authzid attribute then it will also appear as user=. If you do the latter you'll need to reference: http://tools.ietf.org/html/draft-williams-kitten-impersonation-naming-attr-00 The obvious choice is the first: it's easier on you. It's pretty much what we did with SCRAM, with just a smidgen of text saying GSS-related things for anyone who wanted to implement SCRAM as a GSS mechanism used in a SASL GS2 framework. Nico -- From nobody Mon Mar 10 18:18:52 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BF51A0675 for ; Mon, 10 Mar 2014 18:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrVNyxRi_Piy for ; Mon, 10 Mar 2014 18:18:49 -0700 (PDT) Received: from n8-vm0.bullet.mail.bf1.yahoo.com (n8-vm0.bullet.mail.bf1.yahoo.com [72.30.234.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBAA1A0666 for ; Mon, 10 Mar 2014 18:18:49 -0700 (PDT) Received: from [66.196.81.177] by n8.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 01:18:43 -0000 Received: from [98.139.212.230] by t7.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 01:18:43 -0000 Received: from [127.0.0.1] by omp1039.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 01:18:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 600657.39612.bm@omp1039.mail.bf1.yahoo.com Received: (qmail 92926 invoked by uid 60001); 11 Mar 2014 01:18:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394500723; bh=NuUz1R2bf4HeQMJa+Y1NRNV4w0KFo3Cyk4O+1WAGdJg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=3KKdBfPIg1J3Av3rK5FoJQbFbAZPN21w5QXw9j0VZyXHtJrC4FTBdf4JPq/jDBaimIia91OzCb+89lc2FfXx2WMUO9XGlN39N1uSTITdfHKiUT9bde7fXW+BoP8/WqxG27arFedxWTH4DO2YkiOM55vl/bCO8JdBJ53fZ3PH1Zo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IvfKSpCW4dHhl6IzimqQ6O/6Cjwp/Lcc+oIS26ZNTZgZ6JbHnwuljgC/hIey8dUQs6OodO0QvLE2yqI3zX2KVlNvuhEvktgoskLjbAdTARmHkRTUcsMbsty5qdtQoqWEnvMgwJkdd35LL8UZTrCsRHXinwnk9JUshNim5KQnEus=; X-YMail-OSG: .PNyYjcVM1l2Vhr5mpqcBmEUNOMtIBb._Lt6zlVtMwgdG92 yQyY2XC3zQ2Li0dIqj.D83JQpBnuwNQ1xVud8D_Rs3Qyv3gqjHKWhjCg9hUq AHGYpqPBatOoMzQpwVLaaEyplvG.rEME3BpN.PxotYV1pszrRQ1bzkRMGwOc o0Qg79DIp9e0jxuEEMd8sJAdErXE5.FXFM5Fo7agjD8c2bVg6.LfVoJ7s8xp 1TCgYmGIW.swIrmNoL_SViVV4_L8GygndOTW43.4MGPPoDOXRGl.OSklYoRG ikEcTIiMjSkkCkMosEQxWwyGPdvFwcb4rgv0_tCdRzjLKHMVbsu46YuZR07Q fb2fC711d5BrQHH7esEJvTEmIw6Xsuu3VJfK9W.vKxpbQJeEz8TW4KeFfU.L xhbK8BaKmH1W8KvvlEyqkbWRooq4BCYaCpXosJF6GqQLwd12lOv3BXrpOpEQ jBtzg_LMuOhuJR6dUAhWjtCUFUbi3wFG7S1fWdZSeSLZVgdb1r9Z.R.1dKxd We4T0VGc4ac6qC9C0X7h0bbb18l_FOPtWIGa52DjMr1wxezU93wlocdVAHgJ Tw4kw9ZGIYxjKJoBUTwjFIi5S10uylw8wVdpNXZh_WJDdrvZu1OB7GdGj71w jgHcdFCH1yBzBG70rvlP.8MI2pT9FCdpzQ8UuXvl3BmQhNHV0716LTF.ryDS xE9NVEoITv9s- Received: from [209.131.62.115] by web142803.mail.bf1.yahoo.com via HTTP; Mon, 10 Mar 2014 18:18:43 PDT X-Rocket-MIMEInfo: 002.001, T3B0aW9uICMxIGlzIGFsbW9zdCB3aGVyZSB3ZSBhcmUgbm93LiDCoEp1c3QgbmVlZCB0byBzdGVhbCB5b3VyIHNlY29uZCBwYXJhZ3JhcGggYWJvdmUgYW5kIGV4cGxhaW4gdGhlIHBvdGVudGlhbCBkdXBsaWNhdGUgYXV0aHppZCBpZiBhIEdTMiBtZWNoYW5pc20gaXMgZGVmaW5lZC4KCgoKT24gTW9uZGF5LCBNYXJjaCAxMCwgMjAxNCA2OjE0IFBNLCBOaWNvIFdpbGxpYW1zIDxuaWNvQGNyeXB0b25lY3Rvci5jb20.IHdyb3RlOgogCk9uIE1vbiwgTWFyIDEwLCAyMDE0IGF0IDc6NTggUE0sIEJpbGwgTWlsbHMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> Message-ID: <1394500723.9375.YahooMailNeo@web142803.mail.bf1.yahoo.com> Date: Mon, 10 Mar 2014 18:18:43 -0700 (PDT) From: Bill Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="905790552-84423020-1394500723=:9375" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/uTnrUvGSFkELJMqgk7ST7Uz5Zyg Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 01:18:51 -0000 --905790552-84423020-1394500723=:9375 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Option #1 is almost where we are now. =A0Just need to steal your second par= agraph above and explain the potential duplicate authzid if a GS2 mechanism= is defined.=0A=0A=0A=0AOn Monday, March 10, 2014 6:14 PM, Nico Williams wrote:=0A =0AOn Mon, Mar 10, 2014 at 7:58 PM, Bill Mi= lls wrote:=0A> Examples in=0A> http://tools.ietf.o= rg/html/draft-ietf-kitten-sasl-oauth-14#section-4=0A>=0A> Does that answer = your question?=0A=0AYes!=0A=0AYou have two options that are equivalent, and= you need only choose=0Awhether you want to describe a GSS mechanism that c= an be used as a GS2=0Amechanism, or a SASL mechanism from which one could d= erive a GSS=0Amechanism that interops with the SASL one when used in a GS2= =0Aframework.=0A=0AIn the first case all you have to say is that the tokens= start with=0Athe GS2 header, and that if there's an authzid it will appear= twice,=0Aonce in the a=3D attribute in the GS2 header, and once in a user= =3D=0Aattribute past the GS2 header.=0A=0AIn the second case you'd say that= the OAuth GSS mechanism's=0AGSS_Init_sec_context() outputs a token as it w= ould look without the=0AGS2 header, and that if the initiator name had an a= uthzid set then=0Athis is sent as user=3D.=A0 Then automatically w= hen this=0Amechanism is used in SASL via GS2 SASL will add the a=3D, and=0Aif the GS2 implementation knows to set the GSS authzid attribute t= hen=0Ait will also appear as user=3D.=0A=0AIf you do the latter yo= u'll need to reference:=0A=0Ahttp://tools.ietf.org/html/draft-williams-kitt= en-impersonation-naming-attr-00=0A=0AThe obvious choice is the first: it's = easier on you.=A0 It's pretty much=0Awhat we did with SCRAM, with just a sm= idgen of text saying GSS-related=0Athings for anyone who wanted to implemen= t SCRAM as a GSS mechanism=0Aused in a SASL GS2 framework.=0A=0A=0ANico=0A-= - --905790552-84423020-1394500723=:9375 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Option #1 is almost where we are now.  Just n= eed to steal your second paragraph above and explain the potential duplicat= e authzid if a GS2 mechanism is defined.


On Monday, March 10, 2014 6:1= 4 PM, Nico Williams <nico@cryptonector.com> wrote:
=
On Mon, Mar 10, 2014 at 7:58 PM, Bill Mill= s <wmills_92105@yahoo.com> wrot= e:
> Examples in
> http://tools.ietf.org/html/draft-ietf-kitten-sasl-= oauth-14#section-4
>
> Does t= hat answer your question?

Yes!

You have two options that are equivalent, and= you need only choose
whether you want to describe a GSS = mechanism that can be used as a GS2
mechanism, or a SASL = mechanism from which one could derive a GSS
mechanism tha= t interops with the SASL one when used in a GS2
framework= .

In the first case all you have to sa= y is that the tokens start with
the GS2 header, and that = if there's an authzid it will appear twice,
once in the a=3D attribute in the GS2 head= er, and once in a user=3D
attribute past the GS2 header.<= br clear=3D"none">
In the second case you'd say that the = OAuth GSS mechanism's
GSS_Init_sec_context() outputs a to= ken as it would look without the
GS2 header, and that if = the initiator name had an authzid set then
this is sent a= s user=3D<authzid>.  Then automatically when this
mechanism is used in SASL via GS2 SASL will add the a=3D<authzid>= , and
if the GS2 implementation knows to set the GSS auth= zid attribute then
it will also appear as user=3D<auth= zid>.

If you do the latter you'll n= eed to reference:

http://tools.ietf.org/html/draft-williams-kitten-imperso= nation-naming-attr-00

The obvious = choice is the first: it's easier on you.  It's pretty much
what we did with SCRAM, with just a smidgen of text saying GSS-relat= ed
things for anyone who wanted to implement SCRAM as a G= SS mechanism
used in a SASL GS2 framework.


Nico<= br clear=3D"none">--


=
--905790552-84423020-1394500723=:9375-- From nobody Mon Mar 10 18:36:57 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4966E1A06C8 for ; Mon, 10 Mar 2014 18:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZrxbOkC24xy for ; Mon, 10 Mar 2014 18:36:54 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (unknown [69.163.253.166]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEB91A06A3 for ; Mon, 10 Mar 2014 18:36:54 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id CF0C2778070 for ; Mon, 10 Mar 2014 18:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=KLx5up/DpapZZoelvzYi EUJvQQg=; b=wTuB0CmwUXBp4DcUdGllI/d9+E9DP59HDLaXrhwzWxd+6Nxt4wgy J/fI0aiRIr9Wvg5Onjhu0NPmc4jIeTSZNPT01AESZrIB2wfjxHkffRq7IY3ccLfm TJupB/cF0qk1C9wBokSrJGxATeEXh0+dG4zyLmcT+9gzSaT/HQ+t3hc= Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 7C4C977806E for ; Mon, 10 Mar 2014 18:36:47 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so9508387wes.18 for ; Mon, 10 Mar 2014 18:36:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WQHtwYIeIXYZRME7VL0y1PZdhPD9fLrB1xUyFsaxZH8=; b=kguWTkX0kGssIk2NU488c88VRoUnSo6ZwKC5jKOiT8wyq5pjB6ddseWP4UBkv8sqB7 dUcAc0FZo+VNW0nPPnJ9Sjk2bsWeNqVAvUPrHIXxF9VulMJTPPLL+4Ybmk3+EKKm47de t0w88IxYPAGcPMDDuDsUsrQIsRUu0nRMOXFiJyOf5/ZX4mo/hVWBR40XkrWVynHWY0ja Tmc/krnhhNYL5Mmogi3lbE9jFtBC9NqDOpzoK2FvCs6NqodG/dWJQHqxpkq6mA6uGm2r ymmYhpGSQVe70FbxXwyjKXQ0JFtz758XIEbUdYw6TD+jyCVx7N0V/VQ2Ds/JvTbejISL DykA== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr801840wib.5.1394501806443; Mon, 10 Mar 2014 18:36:46 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Mon, 10 Mar 2014 18:36:46 -0700 (PDT) In-Reply-To: <1394500723.9375.YahooMailNeo@web142803.mail.bf1.yahoo.com> References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> <1394500723.9375.YahooMailNeo@web142803.mail.bf1.yahoo.com> Date: Mon, 10 Mar 2014 20:36:46 -0500 Message-ID: From: Nico Williams To: Bill Mills Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/cm7J5kNs48Ni-okz9dXHlQuX1EM Cc: "kitten@ietf.org" , Bill Mills Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 01:36:55 -0000 On Mon, Mar 10, 2014 at 8:18 PM, Bill Mills wrote: > Option #1 is almost where we are now. Just need to steal your second > paragraph above and explain the potential duplicate authzid if a GS2 > mechanism is defined. You want to say that if an authzid is set then it's sent in both, a= and user=. That's because otherwise you'd not have a mechanism that could be conceived as a GS2 mechanism or you'd not interop with Google. A little duplication will have to be accepted if you want both, a GS2-interoperable and Google-interoperable mechanism. It's the consequence of not having noticed and fixed this at Google long ago. I think that's fine. Nico -- From nobody Mon Mar 10 18:52:46 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1351A06CA for ; Mon, 10 Mar 2014 18:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rE2fLNxaC92 for ; Mon, 10 Mar 2014 18:52:42 -0700 (PDT) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) by ietfa.amsl.com (Postfix) with ESMTP id E57BE1A04A1 for ; Mon, 10 Mar 2014 18:52:41 -0700 (PDT) Received: from [98.139.212.151] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 01:52:36 -0000 Received: from [98.139.212.246] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 01:52:36 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 01:52:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 236540.86727.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 13480 invoked by uid 60001); 11 Mar 2014 01:52:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394502756; bh=HtnZ3n2O8oe5iMJ7A7qZj+SmDFGi+CR/lCaCMAM4waY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZFLbUWawX83MgpBfX0LeL2kotS5gi1hJ+9lfzbcEzvPqTXnYnhku/71vJf0Mfm8L92abEMmhBAzUwAdQyuOReK0nymnISvAewSYzxmSl/KQU2YlgIgXOnwiZd1tweVWexFjGMKZa3o3Z+rlR8ZZsz3Oj3nBeA0aEkmfqvYeF+8U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dvSH3LVMZFurVQZ38D/J7HlFrP/YRgkK2lGr4il/tHpYXQi7ODQsfLtbwb0tz8ixwE5q6bd1/eIj72h8OWtZEXWlTV6GCr+5iaZ6airdDLEJNGUx41KK3mWrXqoTx5+PDMZcFhUK1V+jnkFHuC9T/wYpiLzz/3z1AN1bYi0eKIU=; X-YMail-OSG: mLkqOpsVM1nncyRHTWKeuPlGGD7BX5oJ1jvr4e5t8q_qB5F 0_hXi7leNhNvEXepElEfM0C0dzacxmCImz6ZjkuI.kvJ8vW0Vh1Y_VkOdzk8 SpIuo7eyXhmVTaBbHCSZFXWzwZsjUhDcIMlkbsUwY2cHYnUOpmya8k1PSpLp UvWiYA5OSqpyFmj_UwBbQNt3snT8w6kD3sgGy2iCIV7eRxLWPpGA_Pfw.mmc Db7z1vmdJdTuVq73ALjE.C_iuPKruU5F5JINba0d.xNX_Jr4TJjhgwEmZrtX u_J4UORDM1Yu9b70QQmvXfaTwpWyMuYj9YNLY9Ek_d9yD_fY3DHLMmi86DVN oQUKJx4AxkxIQo9COy7XA2CNhzNLw0JU71ymfV3QUZGa7NOCnmIXNPTSGXsi 7yGr6aNifiUtafK9mWrlkhrRRTIl6IWdbaVeuWZCmnSLaeBkII19ki45QyFO eydN4lxQVJuYspUrJaOD6mZHNqBe873h.QEHjokNf.5Medt.z.t9GIbWELIl UiLWeP310pgGlDRjVKH3Nv4VqWPAZSZsnRTLkLbYuoz.RumklMgEQ4U4ijDw B2uN3LpivSPZau.Q0Dh2g3w2_9q9ynss- Received: from [209.131.62.115] by web142803.mail.bf1.yahoo.com via HTTP; Mon, 10 Mar 2014 18:52:36 PDT X-Rocket-MIMEInfo: 002.001, T0ssIHNvIGhlcmUncyBwcm9wb3NlZCBuZXcgdGV4dCBmb3IgZGVmaW5pbmcgdXNlcj0KCiJDb250YWlucyB0aGUgdXNlciBuYW1lIGJlaW5nIGFzb2NpYXRlZCB3aXRoIHRoZQpyZXNvdXJjZSBiZWluZyBhY2Nlc3NlZCwgdGhlIFNBU0wgImF1dGh6aWQiLsKgwqBJZiBhIEdTMgptZWNoYW5pc20gaXMgZGVmaW5lZCB0aGlzIHZhbHVlIHdpbGwgYmUgZHVwbGljYXRlZCB1bmxlc3MKdGhlIEdTMiBtZWNoYW5pc20gaXMgZGVmaW5lZCBzbyB0aGlzIHZhbHVlIGNhbiBiZSByZS11c2VkLiIKCgoKT24gTW9uZGF5LCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> <1394500723.9375.YahooMailNeo@web142803.mail.bf1.yahoo.com> Message-ID: <1394502756.57259.YahooMailNeo@web142803.mail.bf1.yahoo.com> Date: Mon, 10 Mar 2014 18:52:36 -0700 (PDT) From: Bill Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="905790552-936490265-1394502756=:57259" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/d2SxSyl4jr3zVwj5AcUylrHZkaA Cc: "kitten@ietf.org" , Bill Mills Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 01:52:43 -0000 --905790552-936490265-1394502756=:57259 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OK, so here's proposed new text for defining user=3D=0A=0A"Contains the use= r name being asociated with the=0Aresource being accessed, the SASL "authzi= d".=A0=A0If a GS2=0Amechanism is defined this value will be duplicated unle= ss=0Athe GS2 mechanism is defined so this value can be re-used."=0A=0A=0A= =0AOn Monday, March 10, 2014 6:36 PM, Nico Williams = wrote:=0A =0AOn Mon, Mar 10, 2014 at 8:18 PM, Bill Mills wrote:=0A> Option #1 is almost where we are now.=A0 Just need to st= eal your second=0A> paragraph above and explain the potential duplicate aut= hzid if a GS2=0A> mechanism is defined.=0A=0AYou want to say that if an aut= hzid is set then it's sent in both, a=3D=0Aand user=3D.=A0 That's because o= therwise you'd not have a mechanism that=0Acould be conceived as a GS2 mech= anism or you'd not interop with=0AGoogle.=0A=0AA little duplication will ha= ve to be accepted if you want both, a=0AGS2-interoperable and Google-intero= perable mechanism.=A0 It's the=0Aconsequence of not having noticed and fixe= d this at Google long ago.=0AI think that's fine.=0A=0A=0ANico=0A-- --905790552-936490265-1394502756=:57259 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OK, so here's proposed new text for defining user= =3D

"Contains the user name being asociated with t= he
=0A
= resource being accessed, the SASL "authzid".&nbs= p; If a GS2
=0A
m= echanism is defined this value will be duplicated unless
=0A
t= he GS2 mechanism is defined so this value can be re-used."


On Monday, March = 10, 2014 6:36 PM, Nico Williams <nico@cryptonector.com> wrote:
On Mon, Mar 10, 2014 at 8:18 P= M, Bill Mills <wmills_92105@yahoo.com> wr= ote:
> Option #1 is almost where we are now.  Jus= t need to steal your second
> paragraph above and expl= ain the potential duplicate authzid if a GS2
> mechanism is d= efined.

You want to say that if an aut= hzid is set then it's sent in both, a=3D
and user=3D.&nbs= p; That's because otherwise you'd not have a mechanism that
could be conceived as a GS2 mechanism or you'd not interop with
Google.

A little duplication= will have to be accepted if you want both, a
GS2-interop= erable and Google-interoperable mechanism.  It's the
consequence of not having noticed and fixed this at Google long ago.
I think that's fine.


Nico
--


--905790552-936490265-1394502756=:57259-- From nobody Tue Mar 11 07:28:07 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE141A073C for ; Tue, 11 Mar 2014 07:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ue-iHWTgO0S for ; Tue, 11 Mar 2014 07:28:04 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id D67491A045D for ; Tue, 11 Mar 2014 07:28:03 -0700 (PDT) Received: from mail81-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Tue, 11 Mar 2014 14:27:57 +0000 Received: from mail81-tx2 (localhost [127.0.0.1]) by mail81-tx2-R.bigfish.com (Postfix) with ESMTP id CA31340292; Tue, 11 Mar 2014 14:27:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.208; KIP:(null); UIP:(null); IPV:NLI; H:cio-krc-pf01; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h1b1cn1b1bi1155h) Received-SPF: pass (mail81-tx2: domain of osu.edu designates 164.107.81.208 as permitted sender) client-ip=164.107.81.208; envelope-from=cantor.2@osu.edu; helo=cio-krc-pf01 ; cio-krc-pf01 ; Received: from mail81-tx2 (localhost.localdomain [127.0.0.1]) by mail81-tx2 (MessageSwitch) id 1394548075434550_4660; Tue, 11 Mar 2014 14:27:55 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.227]) by mail81-tx2.bigfish.com (Postfix) with ESMTP id 614884A0062; Tue, 11 Mar 2014 14:27:55 +0000 (UTC) Received: from cio-krc-pf01 (164.107.81.208) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 11 Mar 2014 14:27:52 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-krc-pf01 (Postfix) with ESMTPS id AABE0A0061; Tue, 11 Mar 2014 10:27:51 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.03.0174.001; Tue, 11 Mar 2014 10:27:50 -0400 From: "Cantor, Scott" To: Simo Sorce Thread-Topic: [kitten] comments on draft-ietf-kitten-sasl-saml-ec Thread-Index: AQHPPJGI5mV+TEdtgEiWvASeMKVPmZrbEiMA///PLgCAAD13AIAA5QCA Date: Tue, 11 Mar 2014 14:27:50 +0000 Message-ID: References: <1394485376.32465.28.camel@willson.li.ssimo.org> <1394488092.32465.30.camel@willson.li.ssimo.org> In-Reply-To: <1394488092.32465.30.camel@willson.li.ssimo.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.66] Content-Type: text/plain; charset="us-ascii" Content-ID: <1C17F3F357044F4E8421087647AE73C5@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/toTUmyq1smjdnukbB8JpAzEFF3Q Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 14:28:06 -0000 On 3/10/14, 5:48 PM, "Simo Sorce" wrote: >>=20 >> It does copy that exact text, yes, but this has nothing to do with that >> mechanism, so there's no reference to it. > >Is there a document somewhere that explains the differences ? No, other than I suppose the ECP profile in SAML, which does outline the difference. >They look pretty similar from a 30k miles view. They're not really similar. Simply put, SAML-EC adapts the SAML profile designed for non-browser authentication, and the other mechanism adapts the browser SSO profile. In doing the adaptation, I researched the GSS-API requirements around mutual-auth, channel binding, and session key establishment, and extended ECP to support them. -- Scott From nobody Tue Mar 11 09:23:26 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75881A048C for ; Tue, 11 Mar 2014 09:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOJVYPXJ4ymd for ; Tue, 11 Mar 2014 09:23:22 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C5DCD1A0473 for ; Tue, 11 Mar 2014 09:23:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 930922068C; Tue, 11 Mar 2014 12:18:34 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 140-pewBTcde; Tue, 11 Mar 2014 12:18:34 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 11 Mar 2014 12:18:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1D58383F8D; Tue, 11 Mar 2014 12:23:16 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott" References: <1394485376.32465.28.camel@willson.li.ssimo.org> <1394488092.32465.30.camel@willson.li.ssimo.org> Date: Tue, 11 Mar 2014 12:23:16 -0400 In-Reply-To: (Scott Cantor's message of "Tue, 11 Mar 2014 14:27:50 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/LpYs0_X8SyVihksbcBEVNQsp4r0 Cc: "kitten@ietf.org" , Sam Hartman , Simo Sorce Subject: Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 16:23:24 -0000 It sounds like section 5.6.1 requires that the service and client be able to represent a GSS service name as a URI so that the IDP can verify that the service corresponds to the entity ID and that the client can check the service name against the endpoint in the response. It seems like from an interoperability standpoint we need to make sure that clients and servers will perform the same transformation on a GSS service name and that two different implementations will do the same thing. I'm not seeing where that transformation is specified. How do I go from a service name plus host name into the form that is expected in the SOAP messages? In response to other issues. SASL doesn't have formalized notions of how to signal mutual auth or discuss delegation. However SASL implementations do generally provide that information. So, my recommendation is that we describe the checks both for SASL and GSS, but the signaling to the application is vague for SASL. From nobody Tue Mar 11 09:44:19 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B2B1A077D for ; Tue, 11 Mar 2014 09:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCEcUnIetwaD for ; Tue, 11 Mar 2014 09:44:14 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 9D26D1A0738 for ; Tue, 11 Mar 2014 09:44:00 -0700 (PDT) Received: from mail108-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Tue, 11 Mar 2014 16:43:54 +0000 Received: from mail108-ch1 (localhost [127.0.0.1]) by mail108-ch1-R.bigfish.com (Postfix) with ESMTP id 3D45B240143; Tue, 11 Mar 2014 16:43:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.210; KIP:(null); UIP:(null); IPV:NLI; H:cio-krc-pf03; RD:none; EFVD:NLI X-SpamScore: 4 X-BigFish: VPS4(zzbb2dI98dI9371Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzd9hz1de098h1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h1b1cn1b1bi1155h) Received-SPF: pass (mail108-ch1: domain of osu.edu designates 164.107.81.210 as permitted sender) client-ip=164.107.81.210; envelope-from=cantor.2@osu.edu; helo=cio-krc-pf03 ; cio-krc-pf03 ; Received: from mail108-ch1 (localhost.localdomain [127.0.0.1]) by mail108-ch1 (MessageSwitch) id 1394556232375962_11588; Tue, 11 Mar 2014 16:43:52 +0000 (UTC) Received: from CH1EHSMHS027.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail108-ch1.bigfish.com (Postfix) with ESMTP id 57D641000F1; Tue, 11 Mar 2014 16:43:52 +0000 (UTC) Received: from cio-krc-pf03 (164.107.81.210) by CH1EHSMHS027.bigfish.com (10.43.70.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 11 Mar 2014 16:43:52 +0000 Received: from CIO-KRC-HT03.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-krc-pf03 (Postfix) with ESMTPS id D036FC0055; Tue, 11 Mar 2014 12:43:49 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT03.osuad.osu.edu ([fe80::2572:c08d:8186:46a4%12]) with mapi id 14.03.0174.001; Tue, 11 Mar 2014 12:43:51 -0400 From: "Cantor, Scott" To: Sam Hartman Thread-Topic: [kitten] comments on draft-ietf-kitten-sasl-saml-ec Thread-Index: AQHPPUY05mV+TEdtgEiWvASeMKVPmZrcKF8A Date: Tue, 11 Mar 2014 16:43:51 +0000 Message-ID: References: <1394485376.32465.28.camel@willson.li.ssimo.org> <1394488092.32465.30.camel@willson.li.ssimo.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.66] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/2e9ZD_e-gxQXx_1i03ezwlTDa-k Cc: "kitten@ietf.org" , Simo Sorce Subject: Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 16:44:18 -0000 On 3/11/14, 12:23 PM, "Sam Hartman" wrote: >It sounds like section 5.6.1 requires that the service and client be >able to represent a GSS service name as a URI so that the IDP can verify >that the service corresponds to the entity ID and that the client can >check the service name against the endpoint in the response. No, I explicitly avoided converting it, I'm just using the service names as "relative mailto: URIs" from a syntax point of view, but in practice SAML IdPs don't care, they compare strings, if they do anything at all. >It seems like from an interoperability standpoint we need to make sure >that clients and servers will perform the same transformation on a GSS >service name and that two different implementations will do the same >thing. That's why I avoided doing it. >In response to other issues. >SASL doesn't have formalized notions of how to signal mutual auth or >discuss delegation. However SASL implementations do generally provide >that information. >So, my recommendation is that we describe the checks both for SASL and >GSS, but the signaling to the application is vague for SASL. Ok, I can try and finesse that. Are there other mechs that have done so with language that can be reused? -- Scott From nobody Tue Mar 11 12:30:24 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8601A07BA for ; Tue, 11 Mar 2014 12:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLkT2WUD5wVM for ; Tue, 11 Mar 2014 12:30:22 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 176D61A04AB for ; Tue, 11 Mar 2014 12:30:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id AFAAF206B2; Tue, 11 Mar 2014 15:25:33 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soqWBgnUd8Uu; Tue, 11 Mar 2014 15:25:33 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 11 Mar 2014 15:25:33 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 206F883F8D; Tue, 11 Mar 2014 15:30:15 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott" References: <1394485376.32465.28.camel@willson.li.ssimo.org> <1394488092.32465.30.camel@willson.li.ssimo.org> Date: Tue, 11 Mar 2014 15:30:15 -0400 In-Reply-To: (Scott Cantor's message of "Tue, 11 Mar 2014 16:43:51 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/rHeWHPiUDFR8TzN3v5o1BeFpVcg Cc: "kitten@ietf.org" , Sam Hartman , Simo Sorce Subject: Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 19:30:23 -0000 >>>>> "Cantor," == Cantor, Scott writes: Cantor,> On 3/11/14, 12:23 PM, "Sam Hartman" wrote: >> It sounds like section 5.6.1 requires that the service and client >> be able to represent a GSS service name as a URI so that the IDP >> can verify that the service corresponds to the entity ID and that >> the client can check the service name against the endpoint in the >> response. Cantor,> No, I explicitly avoided converting it, I'm just using the Cantor,> service names as "relative mailto: URIs" from a syntax Cantor,> point of view, but in practice SAML IdPs don't care, they Cantor,> compare strings, if they do anything at all. So do you expect the string to be mailto:host@example.com or host@example.com? Either way this is non-obvious to me having read the document. I assumed you wanted some conversion or some URI encoding. --Sam From nobody Tue Mar 11 13:54:32 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2ECE1A07DB for ; Tue, 11 Mar 2014 13:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6o-b5H0WAsW for ; Tue, 11 Mar 2014 13:54:27 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (smtp03.srv.cs.cmu.edu [128.2.217.202]) by ietfa.amsl.com (Postfix) with ESMTP id 416E01A072C for ; Tue, 11 Mar 2014 13:54:27 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s2BKsJ8Z009823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 11 Mar 2014 16:54:19 -0400 (EDT) Message-ID: <1394571259.25748.22.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: "Cantor, Scott" Date: Tue, 11 Mar 2014 16:54:19 -0400 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.202 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/cZjBJDnMQCuEwbSm0Ioy56SeX6U Cc: "kitten@ietf.org" , Sam Hartman , jhutz@cmu.edu Subject: Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 20:54:30 -0000 On Mon, 2014-03-10 at 20:27 +0000, Cantor, Scott wrote: > [snip of TLS text] > >This text places normative requirements on applications using this > >mechanism. > >That's not reasonable because applications may have no knowledge of this > >mechanism. > >What happens if these checks are not performed? > > That text came from some iteration of the original wording borrowed from > the SAML/OpenID mechanisms, and was basically adapted. Isn't that same > text, or a variant, essentially what Simon is adding to GS2? > > All this is saying is that if the mechanism doesn't signal mutual > authentication to the initiator, then obviously it's up to the > application. What else can you do? That text was used in the SAML and OpenID mechanisms to attempt to handwave around the need for a mechanism that _claims_ to have done mutual authentication to actually _do_ mutual authentication. Basically, what those mechanisms did was say "we're going to assert mutual_state, but we don't actually do anything to verify the acceptor's identity, so the application had better have done that even though we claim to have done it". They did that because GS2 as written fails on mechs that don't assert mutual_state. That's not an acceptable way for a GSS-API mechanism to behave. It's essentially trying to reach up through the abstraction boundary and impose new requirements on the application depending on what mechanism is used, and the API doesn't allow for that. It's not necessary for a mechanism to say "if we didn't assert mutual_state, then we didn't do mutual auth, and if the app cares, then it had better do something about it". That is a property of the abstraction and is true for _every_ mechanism. For the SAML and OpenID mechanisms, if the application does not perform the checks in question, then badness ensues, because the application sees mutual_state and assumes the acceptor has been authenticated, when it really has not. If _this_ mechanism only asserts mutual_state when it has actually authenticated the acceptor (if ever), _and_ it doesn't depend for its security on the application having already verified the server's identity (as, for example, SASL PLAIN does), then there is no problem. > >Section 5.1 seems applicable to SASL as well. > > Similar question as above; is there normative machinery that can be used > in SASL to regulate and signal it? I didn't think so. SASL unfortunately doesn't have a well-defined abstraction. Not all SASL mechanisms provide mutual authentication (for example, PLAIN does not), and the base spec doesn't really talk about it. Over time, I think the community mostly accepted that the usual case was to run a SASL application over TLS, relying on TLS to authenticate the server and using SASL to authenticate the client. However, we have introduced the notion of channel bindings. It's only safe for an application to rely on CB if mutual authentication has happened. This is why GS2 required mutual auth, and why a new version of GS2 which relaxes this requirement must be careful to specify that -PLUS mechanisms must not be advertised unless mutual auth is possible, and must not succeed if mutual auth does not happen. So no, in the abstract, there's not really any machinery in SASL to signal whether mutual auth happened, except for the implied indication when channel bindings are in use. > >Section 5.3. I note that this is the first time I'm aware of where > >RFC 3961 enctypes' names are used in a protocol. I'd like explicit > >review of this from the Kerberos community. Everything we have so far > >uses numbers. > > Ok, will await decision. I don't care for numbers in a text-based > protocol, but if the strings aren't formalized, that's appropriate. I > think I did look at the registry though and came to the conclusion they > were. The names of enctypes have never been protocol constants. There have frequently been inconsistencies in the spelling and punctuation of these names. There has also been confusion at various points as to what particular names meant. There is no formal definition of the syntax of an enctype name, because they are never used in a case where that matters. Also, I think it is unwise to expect libraries which implement RFC3961 to provide interfaces to look up enctypes by name, and impractical and counterproductive for a mechanism implementation to maintain a private table. Please use the numbers; that's the namespace we've actually standardized. > >Section 5.4: RFc 4121 has multiple keys it can use: the session key, the > >subsession key, and the acceptor subsession key. > >The text in 5.4 is insufficiently detailed for interoperability. > > I'd need feedback on that, I don't have the background (and it was more or > less copied, again, from some other work). A typical behavior would be to prefer an acceptor subkey if one was sent, followed by an initiator subkey if one was sent, followed by the Kerberos ticket session key. However, this can get a bit complicated, because an initiator does not know whether the acceptor sent a subkey until it processes the acceptor's AP_REP. That means you either need to avoid the initiator having to choose until it has seen that message, or having some way to know which key to use when. Doing the first is not bad, but can result in extra round trips depending on what you're doing. -- Jeff From nobody Tue Mar 11 14:51:11 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A8E1A0826 for ; Tue, 11 Mar 2014 14:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pyrld85rZu6A for ; Tue, 11 Mar 2014 14:51:07 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (agjbgdcfdbfg.dreamhost.com [69.163.253.156]) by ietfa.amsl.com (Postfix) with ESMTP id 56C061A081D for ; Tue, 11 Mar 2014 14:51:07 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 682E3B8072 for ; Tue, 11 Mar 2014 14:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=yuCepYO4U/dWBHBMW6aG 9S+2TBA=; b=L6GbC2XiOTT11Q9CthOlLiCDKpTmBEYgCtUkQK2pV6Ra/9cYCpST FUBvfBpM476SMzXJBTpc5+oAnfe6v+/zkuUqocwYAl2kP/RWMmsSX9x4shDMPfC7 t/778O+BhiwiSJXNHnCFYXePcfMYjuoYL66s2Q9v6ArEnMWnTtnduEg= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 18323B8057 for ; Tue, 11 Mar 2014 14:51:00 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so1564808wiw.0 for ; Tue, 11 Mar 2014 14:50:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C8SosaVBESPcdCJsadUqfnALOkzJOGDH5FIHizwOxZ4=; b=TYPI6oqhseI+RUf9s3mSPsm8xWtDkME4MWlBmX9J52AV6km92NJ4kL6aDvx8dTHzF8 ihK9MDbmvUZVAQk/PCTCnMceEV4ateIFkvU9vZHd7aBc/3EQHU55yt3WJv60xei7lnjc XB8JAdzr+ALtiMEfaWtNzmTLAyR9EezmGvD7b6s+SFh5PgXoS0yR+X81neHURlsypxP3 lhv5aqiztADBvMZ7ZwgQqFsQxBw0w/KlBefxX2/DI4R2IPTDFNexM5PVMr0D2FRr3CeY wym/Db/MKimYkGHqOI1TQxuiCUuhm6ylJlItyjgE5ZVQRus93Cl1LkkhlaBnTKYHg1xX Movg== MIME-Version: 1.0 X-Received: by 10.180.102.42 with SMTP id fl10mr4955170wib.42.1394574659748; Tue, 11 Mar 2014 14:50:59 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 14:50:59 -0700 (PDT) In-Reply-To: <1394502756.57259.YahooMailNeo@web142803.mail.bf1.yahoo.com> References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> <1394500723.9375.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394502756.57259.YahooMailNeo@web142803.mail.bf1.yahoo.com> Date: Tue, 11 Mar 2014 16:50:59 -0500 Message-ID: From: Nico Williams To: Bill Mills Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/4C18_ZD72Y5psPt975qYNCX8GNY Cc: "kitten@ietf.org" , Bill Mills Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 21:51:09 -0000 On Mon, Mar 10, 2014 at 8:52 PM, Bill Mills wrote: > OK, so here's proposed new text for defining user= > > "Contains the user name being asociated with the > resource being accessed, the SASL "authzid". If a GS2 > mechanism is defined this value will be duplicated unless > the GS2 mechanism is defined so this value can be re-used." How about replacing the last sentence with: "In order to interoperate with GS2 implementations of this same mechanism the user= SHOULD also appear in the GS2 header's authzid attribute (a=)." Nico -- From nobody Tue Mar 11 15:07:23 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48791A0800 for ; Tue, 11 Mar 2014 15:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O54kZFLcs1Vd for ; Tue, 11 Mar 2014 15:07:08 -0700 (PDT) Received: from nm44-vm6.bullet.mail.bf1.yahoo.com (nm44-vm6.bullet.mail.bf1.yahoo.com [216.109.115.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7843F1A0823 for ; Tue, 11 Mar 2014 15:07:03 -0700 (PDT) Received: from [66.196.81.173] by nm44.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 22:06:57 -0000 Received: from [98.139.212.241] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 22:06:57 -0000 Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 22:06:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 549003.43301.bm@omp1050.mail.bf1.yahoo.com Received: (qmail 53663 invoked by uid 60001); 11 Mar 2014 22:06:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394575617; bh=UL2l/MF+RJRDnTLDiqlIid/ERRuSo2vpA/dU0GvC/5M=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=d8YhNPcFkOpDY6G2B+p2a/Wo7WDAiGOxjcNSVOAaFW97KJf61xR0MgSRvSNxTL7Vrb4Ps3P8/18quO40pSFBu+NPHeXP87D07sfBkKwb6Ln1AqzH0iwCeEJZZjp1jOD/nUOGdu6QUakgGxVnuxZZqAVtI6JOeS1w79sEOw+lyhM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KJ08aACQLMbdnMllY/7PqzX5meEWE0gPKizYlvwbFqUQFyDthcphyfDEuyxNTS4NqVvciMxKrGKKYPZCQARn2vYZwxOLwxi1ZqJyRjEyAi5SMqQ6Ab/uomMdiDjKh/vhkfBW1PTVrgndDPtI8X6m2HHRM47KqvUzhqVmGSSl68E=; X-YMail-OSG: a_EaHYAVM1mhjE.qah_5uL0hidwah679UhJPgd5ds3G9Uvr m2PXCw69XAm2bE8Q8Cg6CTDepXK0T7CAzAyUo3Zq.6c9AO0AFHcLbKnCSs05 5fn_3zCJJjZZrS1pprEdq5fJfwmW0dhHCUBxiroQU6e0Of6GhYFRPpTomoYF OL6zrplh24nxOovmyz3E16_kLT.DCGxY5L8VxGCVgYVA4ZRr_wZPTf765GDo VlHB0kGzc8wWnvSmyoy8PQi3_d8HwNt5jgQX5lAFZQ40297nd6518Om0uSVY HCoP2YdlruIn1Hmi80gAuKmiDXMatiDWoe._ywejIaOEK3YkV6LDg0KwzMFu mg.vFXcVoatJ5eFFy399OvGhPpX8ASOGGe0v2Kgbz50U4F2aSQqLae0Pn7tC 99ytftE05kFWuKzF626Ti1wPkZVBXYxTnxIWVcIus_4O62ejnYCkeYY.Wepf Rk7n6xx8UnznY127k_Pzb7Ybn9dySsZ7SKysqaNWTSFLUDMDt2Fb59d_G4dL 3YjZ8RezYXlPF3VTZDISBi7bgXXaPzPQbxCq_yHh1qbM38pt1ak7pn5oSFnN DmuNcyyns3KuFKnq55algN_YVVVI- Received: from [209.131.62.115] by web142805.mail.bf1.yahoo.com via HTTP; Tue, 11 Mar 2014 15:06:57 PDT X-Rocket-MIMEInfo: 002.001, SSB3YXMgYmVpbmcgbW9yZSB2YWd1ZSBiZWNhdXNlIHlvdSAoPykgbWVudGlvbmVkIHRoZSByZW5hbWluZyBzdHVmZi4gwqBJJ20gaGFwcHkgdG8gdXNlIHRoYXQgdGV4dC4KCiJDb250YWlucyB0aGUgdXNlciBuYW1lIGFzb2NpYXRlZCB3aXRoIHRoZcKgcmVzb3VyY2UgYmVpbmcgYWNjZXNzZWQswqB0aGXCoApTQVNMICJhdXRoemlkIi4gwqBJbiBvcmRlciB0byBpbnRlcm9wZXJhdGXCoHdpdGggR1MyIGltcGxlbWVudGF0aW9uc8Kgb2bCoAp0aGlzIHNhbWUgbWVjaGFuaXNtIHRoZSB1c2VyPSBTSE9VTEQgYWwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> <1394500723.9375.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394502756.57259.YahooMailNeo@web142803.mail.bf1.yahoo.com> Message-ID: <1394575617.52449.YahooMailNeo@web142805.mail.bf1.yahoo.com> Date: Tue, 11 Mar 2014 15:06:57 -0700 (PDT) From: Bill Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1583497461-1195175731-1394575617=:52449" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/rrwb9SHSafqZCprfJxsUDHGTt5s Cc: "kitten@ietf.org" , Bill Mills Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 22:07:12 -0000 --1583497461-1195175731-1394575617=:52449 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I was being more vague because you (?) mentioned the renaming stuff. =A0I'm= happy to use that text.=0A=0A"Contains the user name asociated with the=A0= resource being accessed,=A0the=A0=0ASASL "authzid". =A0In order to interope= rate=A0with GS2 implementations=A0of=A0=0Athis same mechanism the user=3D S= HOULD also=A0appear in the GS2 header's=A0=0Aauthzid attribute (a=3D)."=0A= =0A=0AAny objections?=0A=0A=0A=0AOn Tuesday, March 11, 2014 2:51 PM, Nico W= illiams wrote:=0A =0AOn Mon, Mar 10, 2014 at 8:52 P= M, Bill Mills wrote:=0A> OK, so here's proposed ne= w text for defining user=3D=0A>=0A> "Contains the user name being asociated= with the=0A> resource being=0A accessed, the SASL "authzid".=A0 If a GS2= =0A> mechanism is defined this value will be duplicated unless=0A> the GS2 = mechanism is defined so this value can be re-used."=0A=0AHow about replacin= g the last sentence with: "In order to interoperate=0Awith GS2 implementati= ons of this same mechanism the user=3D SHOULD also=0Aappear in the GS2 head= er's authzid attribute (a=3D)."=0A=0A=0ANico=0A-- --1583497461-1195175731-1394575617=:52449 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I was being more vague bec= ause you (?) mentioned the renaming stuff.  I'm happy to use that text= .

"Contains the user name aso= ciated with the resource being accessed, the 
SASL "authzid".  In order to interoperate = with GS2 implementations of 
thi= s same mechanism the user=3D SHOULD also appear in the G= S2 header's 
authzid attribute (a=3D)."

Any objectio= ns?


On Tuesday, March 11, 2014 2:51 PM, Nico Williams <nico@crypton= ector.com> wrote:
On Mon, Mar 10, 2014 at 8:52 PM, Bill Mills <wmills_92105@yahoo= .com> wrote:
> OK, so here's proposed new text = for defining user=3D
>
> "Contain= s the user name being asociated with the
> resource be= ing=0A accessed, the SASL "authzid".  If a GS2
> = mechanism is defined this value will be duplicated unless
> the GS2 mechanism is defined so this value can be re-used."

How about replacing the last sentence with: "<= span style=3D"font-family: monospace; font-size: 13px;">In order to interop= erate
with GS2 im= plementations of this same mechanism the user=3D SHOULD also
appear in the GS2 header's au= thzid attribute (a=3D)."


Nico
--


--1583497461-1195175731-1394575617=:52449-- From nobody Tue Mar 11 15:52:07 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13171A086D for ; Tue, 11 Mar 2014 15:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2100Ry1kZs87 for ; Tue, 11 Mar 2014 15:52:05 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (mysql.benrbradley.com [69.163.253.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4311A088D for ; Tue, 11 Mar 2014 15:52:02 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 942F52005D10B for ; Tue, 11 Mar 2014 15:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=YVLrZaw9M3PCTkuBZczK xMzGCrA=; b=mv4KXCIUL7b6j0eJ4jvgRyFhr3SyVTptTOgSWJxt5WyAU942yqBT HiqiA0HI8q0dHZv0CUyQC94GAyTWFHKzcJAgXyxCl7YR8HIYw4a2/teX8WRU9IOY Y4XC0jm2sC60xBYxhw7OD7emagmUkIAWSem2bdxMzIFj2hJUHlmw2Ow= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPSA id 4840B2005D109 for ; Tue, 11 Mar 2014 15:51:56 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x48so10757485wes.10 for ; Tue, 11 Mar 2014 15:51:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TiBJaCrhXgbyFVpbi23G/U5RVB/SjRM0rGXRVn1wz+Q=; b=e+/Sqzxo4vIsp3/Iwqqa8r5L6h9ncNxxDl9KNYf+nvHPtiz/c1ozuM4WXQoH5BbVr/ WocknS3ItYurR13q6SyDXH7Nh/6e5rf1xRUvVMm785yrhXUHRnIALspbAWKm6FckogXl kAi4ReIs8dvJXmW66a5A1sZKjhPSwkjqmGlwSQBI2apb1prsuGxI8fcssW1v9PTgZxNZ PCw25Er3Lgh3ed8i6Mi8XQekl1142VPgTuSzjklckjwkjLBCXbtEfGP4pX0wRSVaJejo H9Q760MAWMU3oaY5nkCFzTtGXsWUV/slGvURwGdhu+jLxGhJOBH+dkbn8To/WO6brCoK Umug== MIME-Version: 1.0 X-Received: by 10.194.71.47 with SMTP id r15mr38672184wju.19.1394578315278; Tue, 11 Mar 2014 15:51:55 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 15:51:55 -0700 (PDT) In-Reply-To: <1394575617.52449.YahooMailNeo@web142805.mail.bf1.yahoo.com> References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> <1394500723.9375.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394502756.57259.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394575617.52449.YahooMailNeo@web142805.mail.bf1.yahoo.com> Date: Tue, 11 Mar 2014 17:51:55 -0500 Message-ID: From: Nico Williams To: Bill Mills Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ja1Xf3SjQ6mjMriGyoy8hQx-KqI Cc: "kitten@ietf.org" , Bill Mills Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 22:52:05 -0000 On Tue, Mar 11, 2014 at 5:06 PM, Bill Mills wrote: > I was being more vague because you (?) mentioned the renaming stuff. I'm > happy to use that text. Ah, I thought you were being vague because you didn't want to REQUIRE the duplication. I would prefer to REQUIRE that the authzid go in the GS2 a= and in the user=. That gets us both: interop with Google and interop with GS2. (But I can bend on this because I'm intent on adding an authzid option to GSS (as a name attribute) so that in the end a GS2 implementation that supported that option could live with just the user= bit.) Nico -- From nobody Tue Mar 11 16:18:48 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1441A086A for ; Tue, 11 Mar 2014 16:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1dgwbLNO_vd for ; Tue, 11 Mar 2014 16:18:42 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB871A0844 for ; Tue, 11 Mar 2014 16:18:42 -0700 (PDT) Received: from mail100-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.22; Tue, 11 Mar 2014 23:18:36 +0000 Received: from mail100-ch1 (localhost [127.0.0.1]) by mail100-ch1-R.bigfish.com (Postfix) with ESMTP id DCAF620236; Tue, 11 Mar 2014 23:18:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.222; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf08; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzd9hz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h1b1cn1b1bi1155h) Received-SPF: pass (mail100-ch1: domain of osu.edu designates 164.107.81.222 as permitted sender) client-ip=164.107.81.222; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf08 ; cio-tnc-pf08 ; Received: from mail100-ch1 (localhost.localdomain [127.0.0.1]) by mail100-ch1 (MessageSwitch) id 1394579913893347_25834; Tue, 11 Mar 2014 23:18:33 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail100-ch1.bigfish.com (Postfix) with ESMTP id D55242C01A3; Tue, 11 Mar 2014 23:18:33 +0000 (UTC) Received: from cio-tnc-pf08 (164.107.81.222) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 11 Mar 2014 23:18:29 +0000 Received: from CIO-KRC-HT02.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-tnc-pf08 (Postfix) with ESMTPS id 7A0442E0076; Tue, 11 Mar 2014 19:18:28 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.03.0174.001; Tue, 11 Mar 2014 19:18:28 -0400 From: "Cantor, Scott" To: Sam Hartman Thread-Topic: [kitten] comments on draft-ietf-kitten-sasl-saml-ec Thread-Index: AQHPPWBT5mV+TEdtgEiWvASeMKVPmZrclmsA Date: Tue, 11 Mar 2014 23:18:27 +0000 Message-ID: References: <1394485376.32465.28.camel@willson.li.ssimo.org> <1394488092.32465.30.camel@willson.li.ssimo.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [65.31.0.111] Content-Type: text/plain; charset="us-ascii" Content-ID: <75BE0AD3BA2FCF4AA1630281414F2F6D@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/qzhVZxW-SOE1yEKJ64v7Ec3YeSw Cc: "kitten@ietf.org" , Sam Hartman , Simo Sorce Subject: Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 23:18:46 -0000 On 3/11/14, 3:30 PM, "Sam Hartman" wrote: > >So do you expect the string to be >mailto:host@example.com or host@example.com? The latter. Exactly the service name. >Either way this is non-obvious to me having read the document. I >assumed you wanted some conversion or some URI encoding. No problem, easy to fix. -- Scott From nobody Tue Mar 11 16:27:31 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D551A0845 for ; Tue, 11 Mar 2014 16:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yN_Pd60JSB4U for ; Tue, 11 Mar 2014 16:27:27 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4351A0825 for ; Tue, 11 Mar 2014 16:27:23 -0700 (PDT) Received: from mail168-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.22; Tue, 11 Mar 2014 23:27:18 +0000 Received: from mail168-tx2 (localhost [127.0.0.1]) by mail168-tx2-R.bigfish.com (Postfix) with ESMTP id D92AD2A0191; Tue, 11 Mar 2014 23:27:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.222; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf08; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzd9hz1de098h1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24d7h2516h2545h255eh25cch25f6h2605h1b1cn1b1bi1155h) Received-SPF: pass (mail168-tx2: domain of osu.edu designates 164.107.81.222 as permitted sender) client-ip=164.107.81.222; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf08 ; cio-tnc-pf08 ; Received: from mail168-tx2 (localhost.localdomain [127.0.0.1]) by mail168-tx2 (MessageSwitch) id 1394580435738166_15073; Tue, 11 Mar 2014 23:27:15 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.246]) by mail168-tx2.bigfish.com (Postfix) with ESMTP id A4716120098; Tue, 11 Mar 2014 23:27:15 +0000 (UTC) Received: from cio-tnc-pf08 (164.107.81.222) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 11 Mar 2014 23:27:15 +0000 Received: from CIO-KRC-HT01.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-tnc-pf08 (Postfix) with ESMTPS id B827A2E0076; Tue, 11 Mar 2014 19:27:14 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.03.0174.001; Tue, 11 Mar 2014 19:27:14 -0400 From: "Cantor, Scott" To: Jeffrey Hutzelman Thread-Topic: [kitten] comments on draft-ietf-kitten-sasl-saml-ec Thread-Index: AQHPPJGI5mV+TEdtgEiWvASeMKVPmZra1dwAgAHMM4D///hrgA== Date: Tue, 11 Mar 2014 23:27:13 +0000 Message-ID: References: <1394571259.25748.22.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1394571259.25748.22.camel@minbar.fac.cs.cmu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [65.31.0.111] Content-Type: text/plain; charset="us-ascii" Content-ID: <0AFBB8B3DBE4BD428004D6FB12D8B79C@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/LvAixkozJIzExYKqWtBZwLX1gOU Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 23:27:30 -0000 On 3/11/14, 4:54 PM, "Jeffrey Hutzelman" wrote: > >It's not necessary for a mechanism to say "if we didn't assert >mutual_state, then we didn't do mutual auth, and if the app cares, then >it had better do something about it". That is a property of the >abstraction and is true for _every_ mechanism. Ah, ok. Will fix/adjust, thanks. >However, we have introduced the notion of channel bindings. It's only >safe for an application to rely on CB if mutual authentication has >happened. This is why GS2 required mutual auth, and why a new version >of GS2 which relaxes this requirement must be careful to specify that >-PLUS mechanisms must not be advertised unless mutual auth is possible, >and must not succeed if mutual auth does not happen. > >So no, in the abstract, there's not really any machinery in SASL to >signal whether mutual auth happened, except for the implied indication >when channel bindings are in use. Got it. >Please use the numbers; that's the namespace we've actually >standardized. Ok. I don't think there are any implications back on the SAML material I wrote for this at OASIS, but I will review that as part of fixing this. >A typical behavior would be to prefer an acceptor subkey if one was >sent, followed by an initiator subkey if one was sent, followed by the >Kerberos ticket session key. However, this can get a bit complicated, >because an initiator does not know whether the acceptor sent a subkey >until it processes the acceptor's AP_REP. That means you either need to >avoid the initiator having to choose until it has seen that message, or >having some way to know which key to use when. Doing the first is not >bad, but can result in extra round trips depending on what you're doing. Is there actually an AP_REP here? Or do you mean that euphemistically? I didn't think reuse of those formats and encryption types implied actual Kerberos-defined messages anywhere, but this is definitely not anything I'm familiar with directly. -- Scott From nobody Tue Mar 11 17:39:09 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ED71A08A7 for ; Tue, 11 Mar 2014 17:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.22 X-Spam-Level: X-Spam-Status: No, score=-16.22 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, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8q2mZCzZN0U for ; Tue, 11 Mar 2014 17:15:34 -0700 (PDT) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDB51A089A for ; Tue, 11 Mar 2014 17:15:34 -0700 (PDT) Received: from GQ1-EX10-CAHT14.y.corp.yahoo.com (gq1-ex10-caht14.corp.gq1.yahoo.com [10.73.119.195]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s2C0F2VS089675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Mar 2014 17:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1394583303; bh=twAtd6rhM6cEneiHjxJs2dQuXhvYOCpuB2BqpXyNmkg=; h=References:Date:From:Reply-To:Subject:To:CC:In-Reply-To; b=j1zjF9j7JYAQj23ABvaZopg8snJlhWadQnR1xxmSLnweNhCkSakzVaO1TSh0+hbW2 ATAkfkg7qarfWHkDwbLNgjzGLB4yGVzciXaIARvrjd8K564OX0m0sfLQa7nVdncPBG Ixb6QH6JPG0emON892wsyWNF5sdOo9fjN1Ue6foA= Received: from omp1010.mail.ne1.yahoo.com (98.138.87.10) by GQ1-EX10-CAHT14.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 11 Mar 2014 17:15:01 -0700 Received: (qmail 31338 invoked by uid 1000); 12 Mar 2014 00:15:01 -0000 Received: (qmail 62257 invoked by uid 60001); 12 Mar 2014 00:15:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1394583300; bh=Y96r6/PkpK4DX0CI0A/Suqor1rUl+NAJdmD4NGcOpNw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qfly4GrwPVQSSOOi2UPJB0vKqai0GdiU4X7uzjfUV4Fyo0DBqhQWmlWSoW0rglAXEq286KOxu3AU/Pl1lA6W80qQH2cXJLZym9RsAf2wiqsWcI/C3bbBYFIyiVb+R4+W+6FbORgQ1+PmjXB0yVh6G4uTeI+LfMZPH6gU+MFQV7g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rjUeJsJ5kc/68lkLjOgB5Omo+lVcsXVAYCYd9eUH/u728kCxYWAdhtoVg0V6qYzQL69He+057G04w+W9i6fotfGz4IWHmPYqPoEqCr9lk6+ja3EJAQgCIFRkQdJ3g4wO08eIQ8GXCbKGe07S7FSzFdVTLIJDskj6muU7dp+/3zE=; X-YMail-OSG: LROSb1UVM1mVf.6sv4E94iKJuHwuDv7b6YnDUW66MUu5fgQ 8yD2frDjcPEoq3JqSPPeTJxuThSz18gsEH.X6A6Scg.3MZQ3F1PLQj139lb_ 2qLqBIhB38LawebBAE2IUaB0IroBszgZmkasy2cBqu2PT1noigqGsZcTIlLK P4bx.czSy1j7ewBBT.ikndD3P_nWi6ZYqJ3YsjDOoxTicb8E3BJGOD9VhTIi 0KaklicdqfCEa.Kw3JW6XdurZP00K4T8ONE.fYmLKom9CF4esSIe1cDd.MvL QsE0vT6Z2pPQOEoMW30ziNjKz Received: from [209.131.62.115] by web125605.mail.ne1.yahoo.com via HTTP; Tue, 11 Mar 2014 17:15:00 PDT X-Rocket-MIMEInfo: 002.001, Q2FuIHdlIGxlYXZlIGE9IHRvIHdoZW4gYSBHUzIgbWVjaGFuaXNtIGlzIGRlZmluZWQ_wqAgb3IgZG8gd2UgbmVlZCBpdCBpbiBub3cgc28gdGhlIFNBU0wgbWVjaGFuaXNtIGlzIGZvcndhcmQgY29tcGF0aWJsZT8KCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGxpYW0gSi4gTWlsbHMKIlBhcmFub2lkIiBNVVggWWFob28hCgoKCgoKT24gVHVlc2RheSwgTWFyY2ggMTEsIDIwMTQgMzo1MiBQTSwgTmljbyBXaWxsaWFtcyA8bmljb0BjcnlwdG9uZWN0b3IuY29tPiB3cm8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> <1394500723.9375.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394502756.57259.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394575617.52449.YahooMailNeo@web142805.mail.bf1.yahoo.com> Message-ID: <1394583300.43796.YahooMailNeo@web125605.mail.ne1.yahoo.com> Date: Tue, 11 Mar 2014 17:15:00 -0700 From: Bill Mills To: Nico Williams , Bill Mills In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1124617404-1775119117-1394583300=:43796" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 583303000 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/X3VY9smQE0NyGHILjTyM-I1hcrs X-Mailman-Approved-At: Tue, 11 Mar 2014 17:39:05 -0700 Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 00:15:36 -0000 ---1124617404-1775119117-1394583300=:43796 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can we leave a=3D to when a GS2 mechanism is defined?=A0 or do we need it i= n now so the SASL mechanism is forward compatible?=0A=0A=A0=0A-bill=0A=0A= =0A=0A--------------------------------=0AWilliam J. Mills=0A"Paranoid" MUX = Yahoo!=0A=0A=0A=0A=0A=0AOn Tuesday, March 11, 2014 3:52 PM, Nico Williams <= nico@cryptonector.com> wrote:=0A =0AOn Tue, Mar 11, 2014 at 5:06 PM, Bill M= ills wrote:=0A> I was being more vague because you= (?) mentioned the renaming stuff.=A0 I'm=0A> happy to use that text.=0A=0A= Ah, I thought you were being vague because you didn't want to REQUIRE=0Athe= duplication.=0A=0AI would prefer to REQUIRE that the authzid go in the GS2= a=3D and in the=0Auser=3D.=A0 That gets us both: interop with Google and i= nterop with GS2.=0A=0A(But I can bend on this because I'm intent on adding = an authzid option=0Ato GSS (as a name attribute) so that in the end a GS2 i= mplementation=0Athat supported that option could live with just the user=3D= bit.)=0A=0A=0ANico=0A-- ---1124617404-1775119117-1394583300=:43796 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Can we le= ave a=3D to when a GS2 mechanism is defined?  or do we need it in now = so the SASL mechanism is forward compatible?
 
-bill=


--------------------------------
William J. Mills
"Paran= oid" MUX Yahoo!



On Tuesday, March 11, 2014 3:52 PM, Nico Williams <nico@cryptonector.c= om> wrote:
On Tue, Mar 11, = 2014 at 5:06 PM, Bill Mills <wmills_92105@yahoo.= com> wrote:
> I was being more vague because yo= u (?) mentioned the renaming stuff.  I'm
> happy = to use that text.

Ah, I thought you we= re being vague because you didn't want to REQUIRE
the dup= lication.

I would prefer to REQUIRE th= at the authzid go in the GS2 a=3D and in the
user=3D.&nbs= p; That gets us both: interop with Google and interop with GS2.

(But I can bend on this because I'm intent on add= ing an authzid option
to GSS (as a name attribute) so tha= t in the end a GS2 implementation
that supported that opt= ion could live with just the user=3D bit.)


Nico
--
<= br>
---1124617404-1775119117-1394583300=:43796-- From nobody Tue Mar 11 17:59:16 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D621A08AF for ; Tue, 11 Mar 2014 17:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THNzBW-k-7aI for ; Tue, 11 Mar 2014 17:58:39 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (unknown [69.163.253.184]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF051A087C for ; Tue, 11 Mar 2014 17:58:39 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 6CE7531805D for ; Tue, 11 Mar 2014 17:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=4jHq0e28cjflbOiuPdJk crQCSqw=; b=iIhr9YZwPj/qGvYZFlx4t4p7JDl5hPMkqk8AJlhIABjrI2dExUZI dN8bLTZU3kyngj8vBvnt6LpHDcofZZkGUjflbOA9RkpuHsREat43xsJ3gExi4kiU 2UQMmVIfLlxQWDf5IgBBWV3+NsH7xEZg+emfBZW6UqncNNxV5lhSg+k= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 1F735318065 for ; Tue, 11 Mar 2014 17:58:32 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id k14so8290723wgh.34 for ; Tue, 11 Mar 2014 17:58:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dOWwIE8xov4BuhlK45PkMpbd4LQGMVTxM8m3kX3OtM0=; b=JANh/nrn+MNYMgY+2rhGfQWI6gU+CdBYFIwWqlmB+fQwzgWUMhyPosHNLEfNjUblMt ujRx80jFb1DyZV3f9xwxrJfM8r5r54ha7dkI3Mz5vjAhNNUESKJwHBU14NmxgB0yuULY VdPX/ipl7ULXOxqIjexPpNUZIQozpL/J4Mt/yBua+Fs9y2HcO45zfUyoZTOdsmuD4jkY 3z0pA9Ln3YlXEHrCTLCY4aL6NKiLtcui2RvLFuZr0igJpxZRMblbskuGu4/HGvXFIYQA z35wcHYPEgXmLNZwD24AHfu5vqSM/xHi+/VYcQucMg8No1xHyhDJzpcQ5HXPnLNmw2Rn Y2YA== MIME-Version: 1.0 X-Received: by 10.194.86.233 with SMTP id s9mr11172864wjz.44.1394585911821; Tue, 11 Mar 2014 17:58:31 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 17:58:31 -0700 (PDT) In-Reply-To: <1394583300.43796.YahooMailNeo@web125605.mail.ne1.yahoo.com> References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> <1394500723.9375.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394502756.57259.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394575617.52449.YahooMailNeo@web142805.mail.bf1.yahoo.com> <1394583300.43796.YahooMailNeo@web125605.mail.ne1.yahoo.com> Date: Tue, 11 Mar 2014 19:58:31 -0500 Message-ID: From: Nico Williams To: Bill Mills Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/pF4infJbWsSREArczEHrcdsW8Pw Cc: "kitten@ietf.org" Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 00:59:14 -0000 On Tue, Mar 11, 2014 at 7:15 PM, Bill Mills wrote: > Can we leave a= to when a GS2 mechanism is defined? or do we need it in now > so the SASL mechanism is forward compatible? If you want implementations made now to be interoperable with future GS2 implementations, then it'd have to be now... unless we also agreed to update GS2 to take into account the notion of GSS authzid naming attribute that Viktor presented last week. I'll ask separately about the update to GS2. From nobody Tue Mar 11 19:33:33 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6D91A06B2 for ; Tue, 11 Mar 2014 19:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEMTkjrpRY7a for ; Tue, 11 Mar 2014 19:33:29 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (agjbgdcfdbfa.dreamhost.com [69.163.253.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA351A036B for ; Tue, 11 Mar 2014 19:33:29 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id D4F482005D908 for ; Tue, 11 Mar 2014 19:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=lTCSGBwLj4SfK9n8eG8v iFhvI/Y=; b=mCbd5jZB1izwLeIZ5eXZe7K5B+LIIqrz3Op6VhCwES5/36gIn/WY 3c/taFEcyRftbiwozfDRjBm+OHMGqiQzZDQ9Jjfzlv0gg0SLQgreIwS7Q2mVruqh mGdZ9CD05pO2ZeJm5z7Baciyu60pmEoJACPmIokKQTgmsLFAYnY4Bi4= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id 879E72005D907 for ; Tue, 11 Mar 2014 19:33:23 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id n15so1609190wiw.5 for ; Tue, 11 Mar 2014 19:33:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rVnKGxU6EnbQUq3Bt11VnsDXWsF5g1RN+NgSjyJ0FCg=; b=fF6p8MQ/5xz4pD+d9IoL+seizs/H+kGvRH9qYuVkUgFmoiPcgnpX6vnqmOxQmP/xD8 erPVqkGG0+rge6nB0gIRhxLvrP/GGupoISSmwcvoZ6ZjkGmz/yMyrDiXI1S7tGukvfOy efutLMPn2hMtow74MtTQktJ6MMxiCDJ6ZrHSHK3Htewf/vjX2Q3fLIdJl5oQ0EXwTTgy Xzz1jgpE28B3wCfJWEtsP9l9F344mVYN2nGpNWfFTyruiO9zG06xNhE1zxlj7u/DG2aC JRNgpUUEc1SQrMSIKqfT7UhnS6ggWRxzyTcapSsVT8XEcfbjXqK9touqNOJoM3TAXM79 eHqA== MIME-Version: 1.0 X-Received: by 10.194.61.210 with SMTP id s18mr39780313wjr.10.1394591602083; Tue, 11 Mar 2014 19:33:22 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 19:33:22 -0700 (PDT) In-Reply-To: <87ob1n5t7f.fsf@latte.josefsson.org> References: <87ob1n5t7f.fsf@latte.josefsson.org> Date: Tue, 11 Mar 2014 21:33:22 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/aCpAx2hzjhmd-FjU5o1Q8twFGIY Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC5801bis: relaxing GS2 requirements X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 02:33:30 -0000 While we're at it, with the OAuth user= / a= issue in mind, I propose that we add a notion of authzid to the GSS-API via a naming attribute. The initiator calls GSS_Set_name_attribute() on a NAME for itself or the target (doesn't matter which, but we should decide which) to set an authzid attribute's value. The mechanism will return an error if it cannot handle this, per-RFC6680, but if it can handle it, then it will make it available to the acceptor as an attribute of the initiator's name, which it can get with GSS_Get_name_attribute(). Then we modify GS2 to say that the a= attribute in the GS2 header may be left out when a) the GSS mechanism doesn't support channel binding, and b) accepts the authzid name attribute. See http://tools.ietf.org/html/draft-williams-kitten-impersonation-naming-attr-00 Nico -- From nobody Tue Mar 11 20:09:33 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82511A08D3 for ; Tue, 11 Mar 2014 20:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzPPsROhJcHt for ; Tue, 11 Mar 2014 20:09:29 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A54FF1A08B4 for ; Tue, 11 Mar 2014 20:09:29 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id w5so9440372qac.34 for ; Tue, 11 Mar 2014 20:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HRxlQ2YNJOL9wIeLuvC86K9tZB9gCAorlckVcRPmFFU=; b=Pcf12gm/dRZWUzeGCrtB2kjVquscdFTjKQ0CE6qt2hXc3WnoclD32yJqMk+1/W4wkJ QFBNNsLRXqvneh84mKHytXW0jlB/u0ybhVUl3dG8tAiBFTFUZwWZIW4bpfvn+wzmqK4B D1UuZpZVQ6/ChQgWr4LBGcJgKu6tJwQ5miNrA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HRxlQ2YNJOL9wIeLuvC86K9tZB9gCAorlckVcRPmFFU=; b=HXc9epYCNO8vblpJKgJKSundKC9qjObAvrDcAnSDBhuAxMaf3zx/e4ig6Ms/sVi6vN vSvASXvS/XQcSf1IhHehM2+n6My7RaufiaRgOicN4VP9G5wFoFK3d+cQbzls8jPTeG6a uYp/3DEizKvwq3OqrbpiFDOPpj0y6rGvcYjEXs90rNFWH3Kx2tLJPIy2wqdb8aIGzgnf pmezpAdEyaDfsNPqUzDNrHUkeU8aISsWPQVKlexJzEbPyVMjIjVjRZEAM0u5C+adkBKu AFVDank0QqcmbC+Xzai6dpmE+7/cobhlzqD7rvE68LR7dxlmhWaOg/tYxR1lKfSqadWO +HhQ== X-Gm-Message-State: ALoCoQnRwPkCMq40+yWnDMYvwsbIp4+V/hAxOjskAiu368X3nYJr8a8/orR0GXKFWmY27Z4G8r+7RINFWbyfBl1P5I5KChkpWL56J/7Tlf96vkY85THLovXEJolmABo8f6KeXV8i6FMurr0pIoJO99Nalbfu48jercqWRNWO9Ut87rK/HkWFDaLjrEH/coAYep+LYkE9Dgxw MIME-Version: 1.0 X-Received: by 10.140.40.5 with SMTP id w5mr49531337qgw.65.1394593763435; Tue, 11 Mar 2014 20:09:23 -0700 (PDT) Received: by 10.229.205.197 with HTTP; Tue, 11 Mar 2014 20:09:23 -0700 (PDT) In-Reply-To: References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> <1394500723.9375.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394502756.57259.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394575617.52449.YahooMailNeo@web142805.mail.bf1.yahoo.com> Date: Tue, 11 Mar 2014 20:09:23 -0700 Message-ID: From: Ryan Troll To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c12976e0403204f4602906 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/acgPqzGzNNrcAvd5DsBeXjY2dkY Cc: "kitten@ietf.org" , Bill Mills Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 03:09:32 -0000 --001a11c12976e0403204f4602906 Content-Type: text/plain; charset=UTF-8 Once this is published, Google will be making changes in order to conform to the RFC. This should require two specific changes: - Support for the appropriate mechanism name - Update to use (whatever user= becomes) In other words, we will use whatever authzid attribute name you guys decide on - it doesn't have to be "user=" just because we said so. If you'd prefer to name it something else, go for it - don't stick with "user=" for Google interop. -R On Tue, Mar 11, 2014 at 3:51 PM, Nico Williams wrote: > On Tue, Mar 11, 2014 at 5:06 PM, Bill Mills > wrote: > > I was being more vague because you (?) mentioned the renaming stuff. I'm > > happy to use that text. > > Ah, I thought you were being vague because you didn't want to REQUIRE > the duplication. > > I would prefer to REQUIRE that the authzid go in the GS2 a= and in the > user=. That gets us both: interop with Google and interop with GS2. > > (But I can bend on this because I'm intent on adding an authzid option > to GSS (as a name attribute) so that in the end a GS2 implementation > that supported that option could live with just the user= bit.) > > Nico > -- > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > --001a11c12976e0403204f4602906 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Once this is published, Google will be making changes in o= rder to conform to the RFC. =C2=A0This should require two specific changes:=
  • Support for the appropriate mechanism name
  • Update to u= se (whatever user=3D becomes)
In other words, we will use whatever authzid attribute name you g= uys decide on - it doesn't have to be "user=3D" just because = we said so. =C2=A0If you'd prefer to name it something else, go for it = - don't stick with "user=3D" for Google interop.

-R


=
On Tue, Mar 11, 2014 at 3:51 PM, Nico Williams <= span dir=3D"ltr"><nico@cryptonector.com> wrote:
On Tue, Mar 11, 2014 at 5:06= PM, Bill Mills <wmills_92105@= yahoo.com> wrote:
> I was being more vague because you (?) mentioned the renaming stuff. = =C2=A0I'm
> happy to use that text.

Ah, I thought you were being vague because you didn't want to REQ= UIRE
the duplication.

I would prefer to REQUIRE that the authzid go in the GS2 a=3D and in the user=3D. =C2=A0That gets us both: interop with Google and interop with GS2.=

(But I can bend on this because I'm intent on adding an authzid option<= br> to GSS (as a name attribute) so that in the end a GS2 implementation
that supported that option could live with just the user=3D bit.)

Nico
--

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

--001a11c12976e0403204f4602906-- From nobody Tue Mar 11 20:17:53 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250621A08D3 for ; Tue, 11 Mar 2014 20:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf73rHLiC0ba for ; Tue, 11 Mar 2014 20:17:49 -0700 (PDT) Received: from nm43-vm9.bullet.mail.bf1.yahoo.com (nm43-vm9.bullet.mail.bf1.yahoo.com [216.109.114.170]) by ietfa.amsl.com (Postfix) with ESMTP id B17A61A08B4 for ; Tue, 11 Mar 2014 20:17:48 -0700 (PDT) Received: from [98.139.215.141] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2014 03:17:42 -0000 Received: from [98.139.212.203] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2014 03:17:42 -0000 Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 12 Mar 2014 03:17:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 559035.96177.bm@omp1012.mail.bf1.yahoo.com Received: (qmail 25441 invoked by uid 60001); 12 Mar 2014 03:17:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394594262; bh=zoBDI5Gp+5zIHgjQksxdDdvw/aOstjVkakjVXq3g2cc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bZPzJPjprxr4OgPZwTT9tAkgxNiop51nDB3USFRDOdawhyMnzszYIqyyPxfa10NOKpRHMb8BO1pl2d2b/icsVMDAKLk/+egM1tdu3mVVLyfeAmnP3NqOFGst5bPVImcNVkfHlA1E9GEIfyLT8hArdTPGk3vspP3b03+0SQZBJGc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hIMuYj7z6IWh4gUa3bNlEWwLUr+CIlOIKZhkPyFGK7w6Rsdu0HWLFq6my9/21J4MxMdYwx/AAIDR7WF5xO5zf7HTbLemRvrq87PsJ4KSN2x+alEnI7KWEb/sT5v9rQkh2vqy3Y7o8RjNPv9qzz4R93YYYS4bGtTfQ6EDGgblGE0=; X-YMail-OSG: Nn98Jv8VM1k_jz_y1B690qnl3Qk6rV86zkHFx4INnVONwwn 4o6QnwPA3gWpwH5GVsYb_LpDd4I78G5gdQEgGgTnumOx_mDOfQnXJxqbSuBd 6Rl6.ciLcyIatjivt4bxLmQ4RDV0DgU9OzEMlyH8Of1bG15j5pq_8qeD_GEB EA_HFQdcecaWHq_0dF_cyyoTp933E_sPpqINBBI8aiU9z239Mo00_FrAccaY uzYTDi3.192pZVcfkviGAdK2T3hMV3Cfei.Vk0TIg0ONBOL00CbrJe5Xen3s RsyS.bvQhKXvoD4eN05Zc8A4kwxhVUqdAFmSvu5zQw1fPQzNgYFM6xbAA3Zh SLJJ19R4tMxRFErOCZaPtaY9lbb_2OFnwekPophz3mJmCNZmfsn2NtdVAKI2 lkSgUykb28Yi7JL41wLDXzD_xwMlpsuXinrAciS_7VIfNZUWT9dJ7BzISXFv S18DbxDKlnI9npqn7ftSP7.jgxbHIrjVNYcjQSPTq32OU3FKF.8zW8OaZgV_ fxQaEcbECEZpe1bqCzZipNd_xBUC5NeII_Sm6kuN18zvKUFp9Y5wvuHRCnuq UR4NvMptlBGtgWkumSSUzV_Hi2svIYO0- Received: from [209.131.62.115] by web142801.mail.bf1.yahoo.com via HTTP; Tue, 11 Mar 2014 20:17:42 PDT X-Rocket-MIMEInfo: 002.001, TmljbywgY29uZmlybWluZyBpdCdzIE9LIGlmIHdlIG1ha2UgdGhlICJhPSIgYXV0aHppZCBtYW5kYXRvcnk_CgoKCk9uIFR1ZXNkYXksIE1hcmNoIDExLCAyMDE0IDg6MDkgUE0sIFJ5YW4gVHJvbGwgPHJ0cm9sbEBnb29nbGVycy5jb20.IHdyb3RlOgogCk9uY2UgdGhpcyBpcyBwdWJsaXNoZWQsIEdvb2dsZSB3aWxsIGJlIG1ha2luZyBjaGFuZ2VzIGluIG9yZGVyIHRvIGNvbmZvcm0gdG8gdGhlIFJGQy4gwqBUaGlzIHNob3VsZCByZXF1aXJlIHR3byBzcGVjaWZpYyBjaGFuZ2VzOgoJKiBTdXBwb3J0IGZvciABMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> <1394500723.9375.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394502756.57259.YahooMailNeo@web142803.mail.bf1.yahoo.com> < 1394575617.52449.YahooMailNeo@web142805.mail.bf1.yahoo.com> Message-ID: <1394594262.98344.YahooMailNeo@web142801.mail.bf1.yahoo.com> Date: Tue, 11 Mar 2014 20:17:42 -0700 (PDT) From: Bill Mills To: Ryan Troll , Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="469468616-1762624885-1394594262=:98344" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/IwEgO1ZvbdwahY0Tk51DnZkcf7A Cc: "kitten@ietf.org" , Bill Mills Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 03:17:51 -0000 --469468616-1762624885-1394594262=:98344 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Nico, confirming it's OK if we make the "a=3D" authzid mandatory?=0A=0A=0A= =0AOn Tuesday, March 11, 2014 8:09 PM, Ryan Troll wro= te:=0A =0AOnce this is published, Google will be making changes in order to= conform to the RFC. =A0This should require two specific changes:=0A=09* Su= pport for the appropriate mechanism name=0A=09* Update to use (whatever use= r=3D becomes)=0AIn other words, we will use whatever authzid attribute name= you guys decide on - it doesn't have to be "user=3D" just because we said = so. =A0If you'd prefer to name it something else, go for it - don't stick w= ith "user=3D" for Google interop.=0A=0A-R=0A=0A=0A=0AOn Tue, Mar 11, 2014 a= t 3:51 PM, Nico Williams wrote:=0A=0AOn Tue, Mar 11= , 2014 at 5:06 PM, Bill Mills wrote:=0A>> I was be= ing more vague because you (?) mentioned the renaming stuff. =A0I'm=0A>> ha= ppy to use that text.=0A>=0A>Ah, I thought you were being vague because you= didn't want to REQUIRE=0A>the duplication.=0A>=0A>I would prefer to REQUIR= E that the authzid go in the GS2 a=3D and in the=0A>user=3D. =A0That gets u= s both: interop with Google and interop with GS2.=0A>=0A>(But I can bend on= this because I'm intent on adding an authzid option=0A>to GSS (as a name a= ttribute) so that in the end a GS2 implementation=0A>that supported that op= tion could live with just the user=3D bit.)=0A>=0A>=0A>Nico=0A>--=0A>=0A>__= _____________________________________________=0A>Kitten mailing list=0A>Kit= ten@ietf.org=0A>https://www.ietf.org/mailman/listinfo/kitten=0A> --469468616-1762624885-1394594262=:98344 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Nico, confirming it's OK if we make the "a=3D" aut= hzid mandatory?


On Tuesday, March 11, 2014 8:09 PM, Ryan Troll <r= troll@googlers.com> wrote:
Once this is publishe= d, Google will be making changes in order to conform to the RFC.  This= should require two specific changes:
  • Support for the appropria= te mechanism name
  • Update to use (whatever user=3D becomes)
In oth= er words, we will use whatever authzid attribute name you guys decide on - = it doesn't have to be "user=3D" just because we said so.  If you'd pre= fer to name it something else, go for it - don't stick with "user=3D" for G= oogle interop.
=0A

-R


On Tue, Mar 11, 2014 at 3:51 PM= , Nico Williams <nico@cryptonector.com> wrote:
=0A
On Tue, Mar 11, 2014 at 5:06 PM, Bill Mills <wmills_92105@yahoo.com> wro= te:
=0A=0A> I was being more vague because you (?) men= tioned the renaming stuff.  I'm
=0A> happy to use= that text.
=0A
=0A
Ah, I thought = you were being vague because you didn't want to REQUIRE
= =0Athe duplication.
=0A
=0AI would pref= er to REQUIRE that the authzid go in the GS2 a=3D and in the
=0Auser=3D.  That gets us both: interop with Google and interop wi= th GS2.
=0A
=0A(But I can bend on this = because I'm intent on adding an authzid option
=0Ato GSS = (as a name attribute) so that in the end a GS2 implementation
=0Athat supported that option could live with just the user=3D bit.)=0A

=0ANico
=0A--
=0A
=0A_____________________________________________= __
=0AKitten mailing list
=0AKitten@ietf.org
= =0Ahttps://www.ietf.org/mailman/listinfo/ki= tten
=0A



--469468616-1762624885-1394594262=:98344-- From nobody Tue Mar 11 20:42:31 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095BC1A039A for ; Tue, 11 Mar 2014 20:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJmYVo9XNOFo for ; Tue, 11 Mar 2014 20:42:28 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id AB3331A0398 for ; Tue, 11 Mar 2014 20:42:28 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (unknown [69.163.253.160]) by hapkido.dreamhost.com (Postfix) with ESMTP id B39162BC95 for ; Tue, 11 Mar 2014 20:42:22 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 4C06121DE6A for ; Tue, 11 Mar 2014 20:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ccduMG2U/dAaX0ghXuP/ LyArLaE=; b=k524WmChjGM1PQqO3SN/Em/rHuFW9s+4Lda+q35AMKduy9SIDf9G 6CrBHtDFG/4j6ctCGachWHbJ7lp3xya/qhUtr/k0/lH+Qc3gAA+IJvPXDgvrjcF0 jDG5o+9nsdbtBP4Uy0kNoI9fiGirFqz4IdOC7xrhXqGPZql7Egng2VE= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id E6BEE21DE65 for ; Tue, 11 Mar 2014 20:42:21 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so1799482wiv.7 for ; Tue, 11 Mar 2014 20:42:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dXGV4N/iWdwa0KC7Rb5yfCzKzr+Qg/oOWZ5xQFkWn0E=; b=RWtna5rPJmBQCx/rjY48LP/lu7Oco/0GY48MjFOpYkKz+am3sLZ/qYz7DVK84s2xC5 aTBPUYxWWDVtP3KVkRpNZMitlaO9zK11G276kXrnnFxs1Rzo8De+gybNR7wzzrDCwfdQ n6KsfFgEmEo5XOG5VoNjRbRPjJ8Jbpewzxvy2C2omHnZEoiHPkqvl7pT3zTrIjqvWeAs 3s8SMPXowqR8b07SvB943Z+o0m6gSLsie222eE9xu1ogToYINq1Aj7WV361uSijUfXIu AFMZCXAeYPA3DzBbI4bRY3P2UlVgspiW2ptUSgvtMIAgOe+feC1PUuJvCuhCR7RMjfn2 oJHA== MIME-Version: 1.0 X-Received: by 10.180.97.72 with SMTP id dy8mr5573138wib.5.1394595740781; Tue, 11 Mar 2014 20:42:20 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 20:42:20 -0700 (PDT) In-Reply-To: <1394594262.98344.YahooMailNeo@web142801.mail.bf1.yahoo.com> References: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> <1394500723.9375.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394502756.57259.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394594262.98344.YahooMailNeo@web142801.mail.bf1.yahoo.com> Date: Tue, 11 Mar 2014 22:42:20 -0500 Message-ID: From: Nico Williams To: Bill Mills Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Qj_Yk41xnATUl7VlaE28hdbChDk Cc: "kitten@ietf.org" , Bill Mills Subject: Re: [kitten] On SASL's authzid X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 03:42:30 -0000 On Tue, Mar 11, 2014 at 10:17 PM, Bill Mills wrote: > On Tuesday, March 11, 2014 8:09 PM, Ryan Troll wrote: > > Once this is published, Google will be making changes in order to conform to > > the RFC. This should require two specific changes: > > > > o Support for the appropriate mechanism name > > o Update to use (whatever user= becomes) > > > > In other words, we will use whatever authzid attribute name you guys decide > > on - it doesn't have to be "user=" just because we said so. If you'd prefer > > to name it something else, go for it - don't stick with "user=" for Google > > interop. Perfect. > Nico, confirming it's OK if we make the "a=" authzid mandatory? Yes. Nico -- From nobody Wed Mar 12 03:29:46 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314081A0953 for ; Wed, 12 Mar 2014 03:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_x-xBjtqUzn for ; Wed, 12 Mar 2014 03:29:41 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id B29021A0947 for ; Wed, 12 Mar 2014 03:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1394620174; d=isode.com; s=selector; i=@isode.com; bh=Doh2pR/rJQfq23f8kcfnYmMMFQOI4ZNSPVI/JUnMVXE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=N5bpUvy53lxQNT0/8OEI4DVoCZ4WVOU0xTyF/XlMVkk88yVBIxlxaCuu3iP+wsL+gz8FcE luhpkNn9cD7i3XVB5BLzRPR/vmZGqlv9U2C0D/k8by3KIrAi4G5kCF5s2B2SLV03FGxR9A tHabhZm6B4AWKo0mCXthTgua87sHZxI=; Received: from [172.17.128.50] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 12 Mar 2014 10:29:34 +0000 date: Wed, 12 Mar 2014 10:28:57 +0000 from: "Alexey\ Melnikov" in-reply-to: <1394583300.43796.YahooMailNeo@web125605.mail.ne1.yahoo.com> message-id: <485a768b-c919-46dc-a8da-4e33ff6ba14a@imap.isode.com> references: <1394230922.9009.YahooMailAndroidMobile@web142803.mail.bf1.yahoo.com> <1394474177.99427.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1394475268.88821.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1394475967.98405.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1394499537.96053.YahooMailNeo@web142802.mail.bf1.yahoo.com> <1394500723.9375.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394502756.57259.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1394575617.52449.YahooMailNeo@web142805.mail.bf1.yahoo.com> <1394583300.43796.YahooMailNeo@web125605.mail.ne1.yahoo.com> to: "Bill\ Mills" x-mailer: Harrier x-priority: 3 MIME-Version: 1.0 content-type: text/plain; charset=UTF-8; delsp=yes; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/FJR2-wmQSZN6CAPxga6D18lR2XA Cc: "kitten@ietf.org" Subject: Re: [kitten] =?utf-8?q?On_SASL=27s_authzid?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 10:29:44 -0000 On Wed, 12 Mar 2014 00:15:00 +0000, Bill Mills wrote: >Can we leave a= to when a GS2 mechanism is defined?  or do we need it in now so the SASL mechanism is forward compatible? I would prefer not to have any new SASL mechanisms that don't support authorization identities (a= in this case). So yes, we need it now. -bill -------------------------------- William J. Mills "Paranoid" MUX Yahoo! On Tuesday, March 11, 2014 3:52 PM, Nico Williams wrote: On Tue, Mar 11, 2014 at 5:06 PM, Bill Mills wrote: > I was being more vague because you (?) mentioned the renaming stuff.  I'm > happy to use that text. Ah, I thought you were being vague because you didn't want to REQUIRE the duplication. I would prefer to REQUIRE that the authzid go in the GS2 a= and in the user=.  That gets us both: interop with Google and interop with GS2. (But I can bend on this because I'm intent on adding an authzid option to GSS (as a name attribute) so that in the end a GS2 implementation that supported that option could live with just the user= bit.) Nico -- From nobody Wed Mar 12 08:29:12 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295CC1A09A8 for ; Wed, 12 Mar 2014 08:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aE1XtmAq6_sd for ; Wed, 12 Mar 2014 08:29:07 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id B4B491A09B3 for ; Wed, 12 Mar 2014 08:29:06 -0700 (PDT) Received: from latte.josefsson.org (46.182.205.36.c.fiberdirekt.net [46.182.205.36]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s2CFSuF3022793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 12 Mar 2014 16:28:57 +0100 Date: Wed, 12 Mar 2014 16:28:49 +0100 From: Simon Josefsson To: kitten@ietf.org Message-ID: <20140312162849.152e924b@latte.josefsson.org> In-Reply-To: References: <5319DE8B.1030202@att.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/geAJqiBe1dZSf68KJnfp7q0jEQA Subject: Re: [kitten] [IANA #748877] please review SASL-SCRAM-256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 15:29:11 -0000 Dear all, We have received a request to register the SCRAM-SHA-256 and SCRAM-SHA-256-PLUS mechanism. According to my understanding of what RFC 5802 section 10 says, the registration process is "IETF Review" http://tools.ietf.org/html/rfc5226#page-11 which requires an RFC, but I may be mistaken. Anyway, suggestions on how to deal with the registration request is appreciated. Having a SCRAM with SHA-256 seems like a fairly non-controversial thing to me. There are interop aspects though, and the utility of defining a lot of variants could be debated. I would like to see a GSS-API OID registered at the same time for any new SCRAM-SHA-* family member, but it seems we forgot to write a policy to make sure that happens. Other thoughts? /Simon You wrote: > Dear Simon, > > IANA has received a request from Tony Hansen (tony@att.com) for two > new registrations in the SASL Mechanisms registry at > http://www.iana.org/assignments/sasl-mechanisms. > > Please let us know when the two-week review period on sasl@ietf.org > is complete. > > thanks, > > Amanda Baber > IANA Request Specialist > ICANN > > === > > IANA, please register the following: > > To: iana@iana.org > Subject: Registration of a new SASL mechanism SCRAM-SHA-256 > > SASL mechanism name (or prefix for the family): SCRAM-SHA-256 > Security considerations: Section 7 of [RFC5802] > Published specification (optional, recommended): [RFC5802] > Person & email address to contact for further information: > IETF SASL WG > Intended usage: COMMON > Owner/Change controller: IESG > Note: > > To: iana@iana.org > Subject: Registration of a new SASL mechanism SCRAM-SHA-256-PLUS > > SASL mechanism name (or prefix for the family): SCRAM-SHA-256-PLUS > Security considerations: Section 7 of [RFC5802] > Published specification (optional, recommended): [RFC5802] > Person & email address to contact for further information: > IETF SASL WG > Intended usage: COMMON > Owner/Change controller: IESG > Note: > From nobody Wed Mar 12 11:56:18 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AE71A0744 for ; Wed, 12 Mar 2014 11:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.06 X-Spam-Level: * X-Spam-Status: No, score=1.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.547, T_HTML_ATTACH=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8yZED2N3Z55 for ; Wed, 12 Mar 2014 11:56:09 -0700 (PDT) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) by ietfa.amsl.com (Postfix) with ESMTP id 830F21A0709 for ; Wed, 12 Mar 2014 11:56:08 -0700 (PDT) Received: from [98.139.215.142] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2014 18:56:02 -0000 Received: from [98.139.212.226] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2014 18:56:02 -0000 Received: from [127.0.0.1] by omp1035.mail.bf1.yahoo.com with NNFMP; 12 Mar 2014 18:56:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 981326.55552.bm@omp1035.mail.bf1.yahoo.com Received: (qmail 7489 invoked by uid 60001); 12 Mar 2014 18:56:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394650561; bh=Qis6cXXXngirAp8Bm8tMeNvVt6akaBpNFuC7SUqf/YQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xAXDqgilzx0fRozkpI38XfSjhMfbQ3rNIcwLDS8VC05z/tXvhAxqr0OEalHiQEg4goQgL2aRuivn/G8zMDiBLQPL2UKMSTWgboBExeb8dclvihpdvXkLQO57+l1d3dCoJQ2VZRslusxrmoJ3TuW/hqEx8NFaJQsrUhnuSzKArnI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=6RcUsqN5pXDIi6Lhddd2GtPcvX0YzPNEG70nN2aBwGNEx4mWqvSrUuUI/X56Y7ux5p+MbUz1ospXSS/nXG3djdO+0FD75bb/nJXUG3TGxweBa0jipmY95TQZwslbZl8xNoAzW30zt5DlwLSGffHyYD4HH2V+7p4h0FxJDnJvvK8=; X-YMail-OSG: FFTRIjIVM1knE2Z4ZNfxJgeQln8flGBk8Lubni6fFO4o6N. juCftvnHlOgUBAmA75_.1n49Oi6Y9CC6I1WsL8sYkpXmuaA3YIx7RDmqnt.8 TIaXTx6cU5b2KgsdwkYcY.A0jAU3YI886HsnugPJjoqxZThFM7VbzRkymb.F TF4ztp.oamdTADpFkWSEoVE7nUPolpLeMtD258G1JjdZ_EjRoUd5_vCwKG_U cU.Y6U0m2kSpAanAaXc6NWH9_ss_bslgImQZ2GMn6yKFP05nGx6pqyETjLrd 6d63WcYzAfnc0s6AwFgqbzhO8zd0wUhn0YpRHj5GWFc6zjWqgtptmx04qyWm Wy.ETD5NMVe64pS1pqS0J00bGYDZAaIZOd09oAk5jXdm9oW4JdBTzrpGf.iW JMSxjLA6VqbNguZLVFLSER7kB9LiJiupV6AZF5yuXtpXdX0D9EeLUh6R421B umpetVfavkzxtXFd3azE3WdkbX6TLIXtaD7S5f8H_5wbcK1vznsyLWn7FiC2 aAjm8d99I6pRhxe2pPlpAZ8kr4Hx60c3ufyBQw0Y8gxg4fePsNxoC2HniYVy 27W5xR95ipEvQDTuOCM95AH909DibIyUIAgjDKOIqhU6LrIt6XuiDt4RqmL5 hM27W4DUB0RV3U.jwsCxvF.gGFJVg47NUa136jzdHPKAkm4OFtG2ynMDRku3 CTSZYYnIXc6Kz_FYc Received: from [99.31.212.42] by web142801.mail.bf1.yahoo.com via HTTP; Wed, 12 Mar 2014 11:56:01 PDT X-Rocket-MIMEInfo: 002.001, UGxlYXNlIHRha2UgYSBsb29rIGF0IHRoZSBhdHRhY2hlZCwgc3BlY2lmaWNhbGx5IDMuMSwgYW5kIHNlZSBpZiBpdCBjYXB0dXJlcyB3aGF0J3MgYmVlbiBkaXNjdXNzZWQuCgpUaGFua3MsCgotYmlsbAoKCgpPbiBUaHVyc2RheSwgTWFyY2ggNiwgMjAxNCAzOjM4IFBNLCBSeWFuIFRyb2xsIDxydHJvbGxAZ29vZ2xlcnMuY29tPiB3cm90ZToKIApBcG9sb2dpZXMgZm9yIHRoZSBkZWxheSBpbiByZXNwb25kaW5nLgoKSSB1bmRlcnN0YW5kIHRoaXMgd2FzIGRpc2N1c3NlZCBpbiB0b2RheSdzIG1lZXRpbmc7IGEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.178.641 References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> Message-ID: <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> Date: Wed, 12 Mar 2014 11:56:01 -0700 (PDT) From: Bill Mills To: Ryan Troll , Bill Mills In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="469468616-147888852-1394650561=:77489" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/CPGu0Z4r609HrD4mEvVJ3lajfrI Cc: "kitten@ietf.org" , Sam Hartman Subject: [kitten] Pending draft 15 Re: sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 18:56:16 -0000 --469468616-147888852-1394650561=:77489 Content-Type: multipart/alternative; boundary="469468616-156731608-1394650561=:77489" --469468616-156731608-1394650561=:77489 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Please take a look at the attached, specifically 3.1, and see if it capture= s what's been discussed.=0A=0AThanks,=0A=0A-bill=0A=0A=0A=0AOn Thursday, Ma= rch 6, 2014 3:38 PM, Ryan Troll wrote:=0A =0AApologie= s for the delay in responding.=0A=0AI understand this was discussed in toda= y's meeting; and we're going to have a follow-up to discuss further - very = reasonable.=0A=0ATo answer Bill's original question: user=3D or a=3D --> Ei= ther works for us. =A0If one has better implications than the other, we'll = use it.=0A=0A-R=0A=0A=0A=0A=0AOn Tue, Mar 4, 2014 at 7:55 AM, Bill Mills wrote:=0A=0A=0A>=0A>It is not used as a SASL identity.= =A0 Quoting from -03 and -14 in progress:=0A>=0A>"user (REQUIRED):=0A>=0A>= =0A>Contains the user name being =0Aauthenticated. The server MAY use this= as a routing or database lookup =0Ahint. The server MUST NOT use this as = authoritative, the user name MUST be asserted by the OAuth credential."=0A>= =A0=0A>Also, looking at the Google API docs for XOAUTH2, they implemented b= ased on the -03 spec and have the "user=3D$username" syntax.=A0 See https:/= /developers.google.com/gmail/xoauth2_protocol =0A>=0A>Based on Google's ser= ver API and the extant clients they have I'd like to ask for a consensus ca= ll on the following:=0A>=0A>1) Add the -03 "user" kvpair back into the spec= .=0A>=0A>a) YES or b) NO.=A0 =0A>=0A>2) Should we include a GS2 header"=0A>= =0A>a) No, let's wait for the GS2 update that deals with things that lack m= utual auth and then write a spec that defines a GS2 header for SASL+OAUTH.= =0A>=0A>b) Change the definition of "key" in kvpair to 1*(ALPHA / ",").=A0 = This makes a GS2 header followed by a ^A (i.e.=0A "n,a=3Duser@example.com^A= ") a valid kvpair which would be ignored by servers that don't understand i= t. =0A>=0A>c) Define a stub OPTIONAL GS2 header explicitly.=0A>=0A>d) Inclu= de a fully=0A defined GS2 header (language from draft -10).=0A>=0A>=0A>My o= wn feedback is 1: YES, 2: a or b.=0A>=0A>=0A>-bill=0A>=0A>=0A>=0A>---------= -----------------------=0A>William J. Mills=0A>"Paranoid" MUX Yahoo!=0A>=0A= >=0A>=0A>=0A>=0A>=0A>On Tuesday, March 4, 2014 12:06 AM, Sam Hartman wrote:=0A> =0A>t's discuss Thursday.=0A>I'd like to under= stand what the user=3D value signifies and whether it's=0A>actually a SASL = authorization identifier.=0A>=0A>I'd like to understand whether there's val= ue in an unprotected SASL=0A>authorization identifier.=0A>=0A>=0A>=0A>=0A>= =0A>=0A>_______________________________________________=0A>Kitten mailing l= ist=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/listinfo/kitten=0A>= =0A>=0A=0A=0A_______________________________________________=0AKitten maili= ng list=0AKitten@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/kitten --469468616-156731608-1394650561=:77489 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Please take a look at the attached, specifically 3= .1, and see if it captures what's been discussed.

Thanks,

-bill


On Thursday, March 6, 2014 3:38 PM, Ry= an Troll <rtroll@googlers.com> wrote:
Apolog= ies for the delay in responding.

I unders= tand this was discussed in today's meeting; and we're going to have a follo= w-up to discuss further - very reasonable.

=0A
To answer Bill's original question: user=3D or a=3D --> Eithe= r works for us.  If one has better implications than the other, we'll = use it.

-R

=0A

On Tue, Mar = 4, 2014 at 7:55 AM, Bill Mills <wmills@yahoo-inc.com> wrote:=
=0A
=0A

=0A
It is no= t used as a SASL identity.  Quoting from -03 and -14 in progress:
=0A
"user (REQUIRED):

Contains= the user name being =0Aauthenticated. The server MAY use this as a routin= g or database lookup =0Ahint. The server MUST NOT use this as authoritativ= e, the user name MUST=0A be asserted by the OAuth credential."
 
Also, looking at the Google API docs for XOAUTH2= , they implemented based on the -03 spec and have the "user=3D$username" sy= ntax.  See https://developer= s.google.com/gmail/xoauth2_protocol
=0A
Based on Google's server API and the extant clients they have I'd lik= e to ask for a consensus call on the following:

1) Add the -03 "user" kvpair back into the spec.
=0A
a) YES or b) NO. 

2) Should we include a GS2 header"

a) No, let's wait for the GS2 update that deals with things that lac= k mutual auth and then write a spec that defines a GS2 header for SASL+OAUT= H.
=0A
b) Change the definition of "key= " in kvpair to 1*(ALPHA / ",").  This makes a GS2 header followed by a= ^A (i.e.=0A "n,a=3Duser@exa= mple.com^A") a valid kvpair which would be ignored by servers that don'= t understand it.

c) Define a stub OPT= IONAL GS2 header explicitly.
=0A
d) Inc= lude a fully=0A defined GS2 header (language from draft -10).


My own feedback is 1: YES, 2: a = or b.

-bill


=0A
--------------------------------
William J. Mills
"Paranoid" MUX Yahoo!
=0A



=
=0A
On=0A Tuesday, March 4, 2014 12:06 AM, Sam Hartman <= hartmans-ietf@mit.= edu> wrote:
t's discuss Thur= sday.
=0AI'd like to understand what the user=3D value si= gnifies and whether it's
actually a SASL authorization id= entifier.

I'd like to understand wheth= er there's value in an unprotected SASL
=0Aauthorization = identifier.





=

_______________________________________________=0A=0AKitten mailing list
=0AKitten@ietf.org
=0A<= a rel=3D"nofollow" shape=3D"rect" target=3D"_blank" href=3D"https://www.iet= f.org/mailman/listinfo/kitten">https://www.ietf.org/mailman/listinfo/kitten=
=0A


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


--469468616-156731608-1394650561=:77489-- --469468616-147888852-1394650561=:77489 Content-Type: text/html; name="draft-ietf-kitten-sasl-oauth-15.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-kitten-sasl-oauth-15.html" PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAg U3RyaWN0Ly9FTiIgCiAgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9E VEQveGh0bWwxLXN0cmljdC5kdGQiPgoKPGh0bWwgbGFuZz0iZW4iIHhtbG5z PSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWw6bGFuZz0iZW4i Pgo8aGVhZCBwcm9maWxlPSJodHRwOi8vd3d3LnczLm9yZy8yMDA2LzAzL2hj YXJkJTIwaHR0cDovL2R1YmxpbmNvcmUub3JnL2RvY3VtZW50cy8yMDA4LzA4 LzA0L2RjLWh0bWwvIj4KICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5 cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11cy1hc2NpaSIgLz4K CiAgPHRpdGxlPkEgc2V0IG9mIFNBU0wgTWVjaGFuaXNtcyBmb3IgT0F1dGg8 L3RpdGxlPgoKICA8c3R5bGUgdHlwZT0idGV4dC9jc3MiIHRpdGxlPSJYbWwy UmZjIChzYW5zIHNlcmlmKSI+CiAgLyo8IVtDREFUQVsqLwoJICBhIHsKCSAg dGV4dC1kZWNvcmF0aW9uOiBub25lOwoJICB9CgkgIGEuc21wbCB7CgkgIGNv bG9yOiBibGFjazsKCSAgfQoJICBhOmhvdmVyIHsKCSAgdGV4dC1kZWNvcmF0 aW9uOiB1bmRlcmxpbmU7CgkgIH0KCSAgYTphY3RpdmUgewoJICB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsKCSAgfQoJICBhZGRyZXNzIHsKCSAgbWFy Z2luLXRvcDogMWVtOwoJICBtYXJnaW4tbGVmdDogMmVtOwoJICBmb250LXN0 eWxlOiBub3JtYWw7CgkgIH0KCSAgYm9keSB7CgkgIGNvbG9yOiBibGFjazsK CSAgZm9udC1mYW1pbHk6IHZlcmRhbmEsIGhlbHZldGljYSwgYXJpYWwsIHNh bnMtc2VyaWY7CgkgIGZvbnQtc2l6ZTogMTBwdDsKCSAgCgkgIH0KCSAgY2l0 ZSB7CgkgIGZvbnQtc3R5bGU6IG5vcm1hbDsKCSAgfQoJICBkZCB7CgkgIG1h cmdpbi1yaWdodDogMmVtOwoJICB9CgkgIGRsIHsKCSAgbWFyZ2luLWxlZnQ6 IDJlbTsKCSAgfQoJCgkgIHVsLmVtcHR5IHsKCSAgbGlzdC1zdHlsZS10eXBl OiBub25lOwoJICB9CgkgIHVsLmVtcHR5IGxpIHsKCSAgbWFyZ2luLXRvcDog LjVlbTsKCSAgfQoJICBkbCBwIHsKCSAgbWFyZ2luLWxlZnQ6IDBlbTsKCSAg fQoJICBkdCB7CgkgIG1hcmdpbi10b3A6IC41ZW07CgkgIH0KCSAgaDEgewoJ ICBmb250LXNpemU6IDE0cHQ7CgkgIGxpbmUtaGVpZ2h0OiAyMXB0OwoJICBw YWdlLWJyZWFrLWFmdGVyOiBhdm9pZDsKCSAgfQoJICBoMS5ucCB7CgkgIHBh Z2UtYnJlYWstYmVmb3JlOiBhbHdheXM7CgkgIH0KCSAgaDEgYSB7CgkgIGNv bG9yOiAjMzMzMzMzOwoJICB9CgkgIGgyIHsKCSAgZm9udC1zaXplOiAxMnB0 OwoJICBsaW5lLWhlaWdodDogMTVwdDsKCSAgcGFnZS1icmVhay1hZnRlcjog YXZvaWQ7CgkgIH0KCSAgaDMsIGg0LCBoNSwgaDYgewoJICBmb250LXNpemU6 IDEwcHQ7CgkgIHBhZ2UtYnJlYWstYWZ0ZXI6IGF2b2lkOwoJICB9CgkgIGgy IGEsIGgzIGEsIGg0IGEsIGg1IGEsIGg2IGEgewoJICBjb2xvcjogYmxhY2s7 CgkgIH0KCSAgaW1nIHsKCSAgbWFyZ2luLWxlZnQ6IDNlbTsKCSAgfQoJICBs aSB7CgkgIG1hcmdpbi1sZWZ0OiAyZW07CgkgIG1hcmdpbi1yaWdodDogMmVt OwoJICB9CgkgIG9sIHsKCSAgbWFyZ2luLWxlZnQ6IDJlbTsKCSAgbWFyZ2lu LXJpZ2h0OiAyZW07CgkgIH0KCSAgb2wgcCB7CgkgIG1hcmdpbi1sZWZ0OiAw ZW07CgkgIH0KCSAgcCB7CgkgIG1hcmdpbi1sZWZ0OiAyZW07CgkgIG1hcmdp bi1yaWdodDogMmVtOwoJICB9CgkgIHByZSB7CgkgIG1hcmdpbi1sZWZ0OiAz ZW07CgkgIGJhY2tncm91bmQtY29sb3I6IGxpZ2h0eWVsbG93OwoJICBwYWRk aW5nOiAuMjVlbTsKCSAgfQoJICBwcmUudGV4dDIgewoJICBib3JkZXItc3R5 bGU6IGRvdHRlZDsKCSAgYm9yZGVyLXdpZHRoOiAxcHg7CgkgIGJhY2tncm91 bmQtY29sb3I6ICNmMGYwZjA7CgkgIHdpZHRoOiA2OWVtOwoJICB9CgkgIHBy ZS5pbmxpbmUgewoJICBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsKCSAgcGFk ZGluZzogMGVtOwoJICB9CgkgIHByZS50ZXh0IHsKCSAgYm9yZGVyLXN0eWxl OiBkb3R0ZWQ7CgkgIGJvcmRlci13aWR0aDogMXB4OwoJICBiYWNrZ3JvdW5k LWNvbG9yOiAjZjhmOGY4OwoJICB3aWR0aDogNjllbTsKCSAgfQoJICBwcmUu ZHJhd2luZyB7CgkgIGJvcmRlci1zdHlsZTogc29saWQ7CgkgIGJvcmRlci13 aWR0aDogMXB4OwoJICBiYWNrZ3JvdW5kLWNvbG9yOiAjZjhmOGY4OwoJICBw YWRkaW5nOiAyZW07CgkgIH0KCSAgdGFibGUgewoJICBtYXJnaW4tbGVmdDog MmVtOwoJICB9CgkgIHRhYmxlLnR0IHsKCSAgdmVydGljYWwtYWxpZ246IHRv cDsKCSAgfQoJICB0YWJsZS5mdWxsIHsKCSAgYm9yZGVyLXN0eWxlOiBvdXRz ZXQ7CgkgIGJvcmRlci13aWR0aDogMXB4OwoJICB9CgkgIHRhYmxlLmhlYWRl cnMgewoJICBib3JkZXItc3R5bGU6IG91dHNldDsKCSAgYm9yZGVyLXdpZHRo OiAxcHg7CgkgIH0KCSAgdGFibGUudHQgdGQgewoJICB2ZXJ0aWNhbC1hbGln bjogdG9wOwoJICB9CgkgIHRhYmxlLmZ1bGwgdGQgewoJICBib3JkZXItc3R5 bGU6IGluc2V0OwoJICBib3JkZXItd2lkdGg6IDFweDsKCSAgfQoJICB0YWJs ZS50dCB0aCB7CgkgIHZlcnRpY2FsLWFsaWduOiB0b3A7CgkgIH0KCSAgdGFi bGUuZnVsbCB0aCB7CgkgIGJvcmRlci1zdHlsZTogaW5zZXQ7CgkgIGJvcmRl ci13aWR0aDogMXB4OwoJICB9CgkgIHRhYmxlLmhlYWRlcnMgdGggewoJICBi b3JkZXItc3R5bGU6IG5vbmUgbm9uZSBpbnNldCBub25lOwoJICBib3JkZXIt d2lkdGg6IDFweDsKCSAgfQoJICB0YWJsZS5sZWZ0IHsKCSAgbWFyZ2luLXJp Z2h0OiBhdXRvOwoJICB9CgkgIHRhYmxlLnJpZ2h0IHsKCSAgbWFyZ2luLWxl ZnQ6IGF1dG87CgkgIH0KCSAgdGFibGUuY2VudGVyIHsKCSAgbWFyZ2luLWxl ZnQ6IGF1dG87CgkgIG1hcmdpbi1yaWdodDogYXV0bzsKCSAgfQoJICBjYXB0 aW9uIHsKCSAgY2FwdGlvbi1zaWRlOiBib3R0b207CgkgIGZvbnQtd2VpZ2h0 OiBib2xkOwoJICBmb250LXNpemU6IDlwdDsKCSAgbWFyZ2luLXRvcDogLjVl bTsKCSAgfQoJCgkgIHRhYmxlLmhlYWRlciB7CgkgIGJvcmRlci1zcGFjaW5n OiAxcHg7CgkgIHdpZHRoOiA5NSU7CgkgIGZvbnQtc2l6ZTogMTBwdDsKCSAg Y29sb3I6IHdoaXRlOwoJICB9CgkgIHRkLnRvcCB7CgkgIHZlcnRpY2FsLWFs aWduOiB0b3A7CgkgIH0KCSAgdGQudG9wbm93cmFwIHsKCSAgdmVydGljYWwt YWxpZ246IHRvcDsKCSAgd2hpdGUtc3BhY2U6IG5vd3JhcDsgCgkgIH0KCSAg dGFibGUuaGVhZGVyIHRkIHsKCSAgYmFja2dyb3VuZC1jb2xvcjogZ3JheTsK CSAgd2lkdGg6IDUwJTsKCSAgfQoJICB0YWJsZS5oZWFkZXIgYSB7CgkgIGNv bG9yOiB3aGl0ZTsKCSAgfQoJICB0ZC5yZWZlcmVuY2UgewoJICB2ZXJ0aWNh bC1hbGlnbjogdG9wOwoJICB3aGl0ZS1zcGFjZTogbm93cmFwOwoJICBwYWRk aW5nLXJpZ2h0OiAxZW07CgkgIH0KCSAgdGhlYWQgewoJICBkaXNwbGF5OnRh YmxlLWhlYWRlci1ncm91cDsKCSAgfQoJICB1bC50b2MsIHVsLnRvYyB1bCB7 CgkgIGxpc3Qtc3R5bGU6IG5vbmU7CgkgIG1hcmdpbi1sZWZ0OiAxLjVlbTsK CSAgbWFyZ2luLXJpZ2h0OiAwZW07CgkgIHBhZGRpbmctbGVmdDogMGVtOwoJ ICB9CgkgIHVsLnRvYyBsaSB7CgkgIGxpbmUtaGVpZ2h0OiAxNTAlOwoJICBm b250LXdlaWdodDogYm9sZDsKCSAgZm9udC1zaXplOiAxMHB0OwoJICBtYXJn aW4tbGVmdDogMGVtOwoJICBtYXJnaW4tcmlnaHQ6IDBlbTsKCSAgfQoJICB1 bC50b2MgbGkgbGkgewoJICBsaW5lLWhlaWdodDogbm9ybWFsOwoJICBmb250 LXdlaWdodDogbm9ybWFsOwoJICBmb250LXNpemU6IDlwdDsKCSAgbWFyZ2lu LWxlZnQ6IDBlbTsKCSAgbWFyZ2luLXJpZ2h0OiAwZW07CgkgIH0KCSAgbGku ZXhjbHVkZWQgewoJICBmb250LXNpemU6IDBwdDsKCSAgfQoJICB1bCBwIHsK CSAgbWFyZ2luLWxlZnQ6IDBlbTsKCSAgfQoJCgkgIC5jb21tZW50IHsKCSAg YmFja2dyb3VuZC1jb2xvcjogeWVsbG93OwoJICB9CgkgIC5jZW50ZXIgewoJ ICB0ZXh0LWFsaWduOiBjZW50ZXI7CgkgIH0KCSAgLmVycm9yIHsKCSAgY29s b3I6IHJlZDsKCSAgZm9udC1zdHlsZTogaXRhbGljOwoJICBmb250LXdlaWdo dDogYm9sZDsKCSAgfQoJICAuZmlndXJlIHsKCSAgZm9udC13ZWlnaHQ6IGJv bGQ7CgkgIHRleHQtYWxpZ246IGNlbnRlcjsKCSAgZm9udC1zaXplOiA5cHQ7 CgkgIH0KCSAgLmZpbGVuYW1lIHsKCSAgY29sb3I6ICMzMzMzMzM7CgkgIGZv bnQtd2VpZ2h0OiBib2xkOwoJICBmb250LXNpemU6IDEycHQ7CgkgIGxpbmUt aGVpZ2h0OiAyMXB0OwoJICB0ZXh0LWFsaWduOiBjZW50ZXI7CgkgIH0KCSAg LmZuIHsKCSAgZm9udC13ZWlnaHQ6IGJvbGQ7CgkgIH0KCSAgLmhpZGRlbiB7 CgkgIGRpc3BsYXk6IG5vbmU7CgkgIH0KCSAgLmxlZnQgewoJICB0ZXh0LWFs aWduOiBsZWZ0OwoJICB9CgkgIC5yaWdodCB7CgkgIHRleHQtYWxpZ246IHJp Z2h0OwoJICB9CgkgIC50aXRsZSB7CgkgIGNvbG9yOiAjOTkwMDAwOwoJICBm b250LXNpemU6IDE4cHQ7CgkgIGxpbmUtaGVpZ2h0OiAxOHB0OwoJICBmb250 LXdlaWdodDogYm9sZDsKCSAgdGV4dC1hbGlnbjogY2VudGVyOwoJICBtYXJn aW4tdG9wOiAzNnB0OwoJICB9CgkgIC52Y2FyZGxpbmUgewoJICBkaXNwbGF5 OiBibG9jazsKCSAgfQoJICAud2FybmluZyB7CgkgIGZvbnQtc2l6ZTogMTRw dDsKCSAgYmFja2dyb3VuZC1jb2xvcjogeWVsbG93OwoJICB9CgkKCQoJICBA bWVkaWEgcHJpbnQgewoJICAubm9wcmludCB7CgkJZGlzcGxheTogbm9uZTsK CSAgfQoJCgkgIGEgewoJCWNvbG9yOiBibGFjazsKCQl0ZXh0LWRlY29yYXRp b246IG5vbmU7CgkgIH0KCQoJICB0YWJsZS5oZWFkZXIgewoJCXdpZHRoOiA5 MCU7CgkgIH0KCQoJICB0ZC5oZWFkZXIgewoJCXdpZHRoOiA1MCU7CgkJY29s b3I6IGJsYWNrOwoJCWJhY2tncm91bmQtY29sb3I6IHdoaXRlOwoJCXZlcnRp Y2FsLWFsaWduOiB0b3A7CgkJZm9udC1zaXplOiAxMnB0OwoJICB9CgkKCSAg dWwudG9jIGE6OmFmdGVyIHsKCQljb250ZW50OiBsZWFkZXIoJy4nKSB0YXJn ZXQtY291bnRlcihhdHRyKGhyZWYpLCBwYWdlKTsKCSAgfQoJCgkgIHVsLmlu ZCBsaSBsaSBhIHsKCQljb250ZW50OiB0YXJnZXQtY291bnRlcihhdHRyKGhy ZWYpLCBwYWdlKTsKCSAgfQoJCgkgIC5wcmludDJjb2wgewoJCWNvbHVtbi1j b3VudDogMjsKCQktbW96LWNvbHVtbi1jb3VudDogMjsKCQljb2x1bW4tZmls bDogYXV0bzsKCSAgfQoJICB9CgkKCSAgQHBhZ2UgewoJICBAdG9wLWxlZnQg ewoJCSAgIGNvbnRlbnQ6ICJJbnRlcm5ldC1EcmFmdCI7IAoJICB9IAoJICBA dG9wLXJpZ2h0IHsKCQkgICBjb250ZW50OiAiRGVjZW1iZXIgMjAxMCI7IAoJ ICB9IAoJICBAdG9wLWNlbnRlciB7CgkJICAgY29udGVudDogIkFiYnJldmlh dGVkIFRpdGxlIjszCgkgIH0gCgkgIEBib3R0b20tbGVmdCB7CgkJICAgY29u dGVudDogIkRvZSI7IAoJICB9IAoJICBAYm90dG9tLWNlbnRlciB7CgkJICAg Y29udGVudDogIkV4cGlyZXMgSnVuZSAyMDExIjsgCgkgIH0gCgkgIEBib3R0 b20tcmlnaHQgewoJCSAgIGNvbnRlbnQ6ICJbUGFnZSAiIGNvdW50ZXIocGFn ZSkgIl0iOyAKCSAgfSAKCSAgfQoJCgkgIEBwYWdlOmZpcnN0IHsgCgkJQHRv cC1sZWZ0IHsKCQkgIGNvbnRlbnQ6IG5vcm1hbDsKCQl9CgkJQHRvcC1yaWdo dCB7CgkJICBjb250ZW50OiBub3JtYWw7CgkJfQoJCUB0b3AtY2VudGVyIHsK CQkgIGNvbnRlbnQ6IG5vcm1hbDsKCQl9CgkgIH0KICAvKl1dPiovCiAgPC9z dHlsZT4KCiAgPGxpbmsgaHJlZj0iI3JmYy50b2MiIHJlbD0iQ29udGVudHMi Pgo8bGluayBocmVmPSIjcmZjLnNlY3Rpb24uMSIgcmVsPSJDaGFwdGVyIiB0 aXRsZT0iMSBJbnRyb2R1Y3Rpb24iPgo8bGluayBocmVmPSIjcmZjLnNlY3Rp b24uMiIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iMiBUZXJtaW5vbG9neSI+Cjxs aW5rIGhyZWY9IiNyZmMuc2VjdGlvbi4zIiByZWw9IkNoYXB0ZXIiIHRpdGxl PSIzIE9BdXRoIFNBU0wgTWVjaGFuaXNtIFNwZWNpZmljYXRpb25zIj4KPGxp bmsgaHJlZj0iI3JmYy5zZWN0aW9uLjMuMSIgcmVsPSJDaGFwdGVyIiB0aXRs ZT0iMy4xIEluaXRpYWwgQ2xpZW50IFJlc3BvbnNlIj4KPGxpbmsgaHJlZj0i I3JmYy5zZWN0aW9uLjMuMS4xIiByZWw9IkNoYXB0ZXIiIHRpdGxlPSIzLjEu MSBSZXNlcnZlZCBLZXkvVmFsdWVzIj4KPGxpbmsgaHJlZj0iI3JmYy5zZWN0 aW9uLjMuMiIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iMy4yIFNlcnZlcidzIFJl c3BvbnNlIj4KPGxpbmsgaHJlZj0iI3JmYy5zZWN0aW9uLjMuMi4xIiByZWw9 IkNoYXB0ZXIiIHRpdGxlPSIzLjIuMSBPQXV0aCBJZGVudGlmaWVycyBpbiB0 aGUgU0FTTCBDb250ZXh0Ij4KPGxpbmsgaHJlZj0iI3JmYy5zZWN0aW9uLjMu Mi4yIiByZWw9IkNoYXB0ZXIiIHRpdGxlPSIzLjIuMiBTZXJ2ZXIgUmVzcG9u c2UgdG8gRmFpbGVkIEF1dGhlbnRpY2F0aW9uIj4KPGxpbmsgaHJlZj0iI3Jm Yy5zZWN0aW9uLjMuMi4zIiByZWw9IkNoYXB0ZXIiIHRpdGxlPSIzLjIuMyBD b21wbGV0aW5nIGFuIEVycm9yIE1lc3NhZ2UgU2VxdWVuY2UiPgo8bGluayBo cmVmPSIjcmZjLnNlY3Rpb24uMy4zIiByZWw9IkNoYXB0ZXIiIHRpdGxlPSIz LjMgT0F1dGggQWNjZXNzIFRva2VuIFR5cGVzIHVzaW5nIEtleWVkIE1lc3Nh Z2UgRGlnZXN0cyI+CjxsaW5rIGhyZWY9IiNyZmMuc2VjdGlvbi40IiByZWw9 IkNoYXB0ZXIiIHRpdGxlPSI0IEV4YW1wbGVzIj4KPGxpbmsgaHJlZj0iI3Jm Yy5zZWN0aW9uLjQuMSIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iNC4xIFN1Y2Nl c3NmdWwgQmVhcmVyIFRva2VuIEV4Y2hhbmdlIj4KPGxpbmsgaHJlZj0iI3Jm Yy5zZWN0aW9uLjQuMiIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iNC4yIFN1Y2Nl c3NmdWwgT0F1dGggMS4wYSBUb2tlbiBFeGNoYW5nZSI+CjxsaW5rIGhyZWY9 IiNyZmMuc2VjdGlvbi40LjMiIHJlbD0iQ2hhcHRlciIgdGl0bGU9IjQuMyBG YWlsZWQgRXhjaGFuZ2UiPgo8bGluayBocmVmPSIjcmZjLnNlY3Rpb24uNC40 IiByZWw9IkNoYXB0ZXIiIHRpdGxlPSI0LjQgU01UUCBFeGFtcGxlIG9mIGEg RmFpbGVkIE5lZ290aWF0aW9uIj4KPGxpbmsgaHJlZj0iI3JmYy5zZWN0aW9u LjUiIHJlbD0iQ2hhcHRlciIgdGl0bGU9IjUgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMiPgo8bGluayBocmVmPSIjcmZjLnNlY3Rpb24uNiIgcmVsPSJDaGFw dGVyIiB0aXRsZT0iNiBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb25zaWRlcmF0 aW9ucyI+CjxsaW5rIGhyZWY9IiNyZmMuc2VjdGlvbi43IiByZWw9IkNoYXB0 ZXIiIHRpdGxlPSI3IElBTkEgQ29uc2lkZXJhdGlvbnMiPgo8bGluayBocmVm PSIjcmZjLnNlY3Rpb24uNy4xIiByZWw9IkNoYXB0ZXIiIHRpdGxlPSI3LjEg U0FTTCBSZWdpc3RyYXRpb24iPgo8bGluayBocmVmPSIjcmZjLnJlZmVyZW5j ZXMiIHJlbD0iQ2hhcHRlciIgdGl0bGU9IjggUmVmZXJlbmNlcyI+CjxsaW5r IGhyZWY9IiNyZmMucmVmZXJlbmNlcy4xIiByZWw9IkNoYXB0ZXIiIHRpdGxl PSI4LjEgTm9ybWF0aXZlIFJlZmVyZW5jZXMiPgo8bGluayBocmVmPSIjcmZj LnJlZmVyZW5jZXMuMiIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iOC4yIEluZm9y bWF0aXZlIFJlZmVyZW5jZXMiPgo8bGluayBocmVmPSIjcmZjLmFwcGVuZGl4 LkFwcGVuZGl4JTIwQSIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iQXBwZW5kaXgg QSBBY2tub3dsZWdlbWVudHMiPgo8bGluayBocmVmPSIjcmZjLmFwcGVuZGl4 LkFwcGVuZGl4JTIwQiIgcmVsPSJDaGFwdGVyIiB0aXRsZT0iQXBwZW5kaXgg QiBEb2N1bWVudCBIaXN0b3J5Ij4KPGxpbmsgaHJlZj0iI3JmYy5hdXRob3Jz IiByZWw9IkNoYXB0ZXIiPgoKCiAgPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBj b250ZW50PQogICJodHRwOi8vZ3JlZW5ieXRlcy5kZS90ZWNoL3dlYmRhdi9y ZmMyNjI5LnhzbHQsIFJldmlzaW9uIDEuNTM5LCAyMDExLTAxLTAyIDE3OjEz OjAwLCBYU0xUIHZlbmRvcjogU0FYT04gNi41LjUgZnJvbSBNaWNoYWVsIEth eSBodHRwOi8vc2F4b24uc2YubmV0LyIgLz4KICA8bGluayByZWw9InNjaGVt YS5kY3QiIGhyZWY9Imh0dHA6Ly9wdXJsLm9yZy9kYy90ZXJtcy8iIC8+CiAg PG1ldGEgbmFtZT0iZGN0LmNyZWF0b3IiIGNvbnRlbnQ9IkRvZSwgSi4iIC8+ CiAgPG1ldGEgbmFtZT0iZGN0LmlkZW50aWZpZXIiIGNvbnRlbnQ9InVybjpp ZXRmOmlkOmRyYWZ0LXNhbXBsZS1pbnB1dC0wMCIgLz4KICA8bWV0YSBuYW1l PSJkY3QuaXNzdWVkIiBzY2hlbWU9IklTTzg2MDEiIGNvbnRlbnQ9IjIwMTAt MTIiIC8+CiAgCiAgPG1ldGEgbmFtZT0iZGN0LmFic3RyYWN0IiBjb250ZW50 PSJPQXV0aCBlbmFibGVzIGEgdGhpcmQtcGFydHkgYXBwbGljYXRpb24gdG8g b2J0YWluIGxpbWl0ZWQgYWNjZXNzIHRvIGEgcHJvdGVjdGVkIHJlc291cmNl LCBlaXRoZXIgb24gYmVoYWxmIG9mIGEgcmVzb3VyY2Ugb3duZXIgYnkgb3Jj aGVzdHJhdGluZyBhbiBhcHByb3ZhbCBpbnRlcmFjdGlvbiwgb3IgYnkgYWxs b3dpbmcgdGhlIHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9uIHRvIG9idGFpbiBh Y2Nlc3Mgb24gaXRzIG93biBiZWhhbGYuICAiIC8+CiAgPG1ldGEgbmFtZT0i ZGVzY3JpcHRpb24iIGNvbnRlbnQ9Ik9BdXRoIGVuYWJsZXMgYSB0aGlyZC1w YXJ0eSBhcHBsaWNhdGlvbiB0byBvYnRhaW4gbGltaXRlZCBhY2Nlc3MgdG8g YSBwcm90ZWN0ZWQgcmVzb3VyY2UsIGVpdGhlciBvbiBiZWhhbGYgb2YgYSBy ZXNvdXJjZSBvd25lciBieSBvcmNoZXN0cmF0aW5nIGFuIGFwcHJvdmFsIGlu dGVyYWN0aW9uLCBvciBieSBhbGxvd2luZyB0aGUgdGhpcmQtcGFydHkgYXBw bGljYXRpb24gdG8gb2J0YWluIGFjY2VzcyBvbiBpdHMgb3duIGJlaGFsZi4g ICIgLz4KICA8bWV0YSBuYW1lPSJrZXl3b3JkcyIgY29udGVudD0iIiAvPgoK PC9oZWFkPgoKPGJvZHk+CgogIDx0YWJsZSBjbGFzcz0iaGVhZGVyIj4KICAg IDx0Ym9keT4KICAgIAogICAgCTx0cj4KPHRkIGNsYXNzPSJsZWZ0Ij5LSVRU RU48L3RkPgo8dGQgY2xhc3M9InJpZ2h0Ij5XLiBNaWxsczwvdGQ+CjwvdHI+ Cjx0cj4KPHRkIGNsYXNzPSJsZWZ0Ij5JbnRlcm5ldC1EcmFmdDwvdGQ+Cjx0 ZCBjbGFzcz0icmlnaHQiPllhaG9vISBJbmMuPC90ZD4KPC90cj4KPHRyPgo8 dGQgY2xhc3M9ImxlZnQiPkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRy YWNrPC90ZD4KPHRkIGNsYXNzPSJyaWdodCI+VC4gU2hvd2FsdGVyPC90ZD4K PC90cj4KPHRyPgo8dGQgY2xhc3M9ImxlZnQiPkV4cGlyZXM6IFNlcHRlbWJl ciAxMSwgMjAxNDwvdGQ+Cjx0ZCBjbGFzcz0icmlnaHQiPkguVC4gVHNjaG9m ZW5pZzwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGNsYXNzPSJsZWZ0Ij48L3RkPgo8 dGQgY2xhc3M9InJpZ2h0Ij5BUk0gTHRkLjwvdGQ+CjwvdHI+Cjx0cj4KPHRk IGNsYXNzPSJsZWZ0Ij48L3RkPgo8dGQgY2xhc3M9InJpZ2h0Ij5NYXJjaCAx MiwgMjAxNDwvdGQ+CjwvdHI+CgogICAgCQogICAgPC90Ym9keT4KICA8L3Rh YmxlPgoKICA8cCBjbGFzcz0idGl0bGUiPkEgc2V0IG9mIFNBU0wgTWVjaGFu aXNtcyBmb3IgT0F1dGg8YnIgLz4KICA8c3BhbiBjbGFzcz0iZmlsZW5hbWUi PmRyYWZ0LWlldGYta2l0dGVuLXNhc2wtb2F1dGgtMTUudHh0PC9zcGFuPjwv cD4KICAKICA8aDEgaWQ9InJmYy5hYnN0cmFjdCI+PGEgaHJlZj0iI3JmYy5h YnN0cmFjdCI+QWJzdHJhY3Q8L2E+PC9oMT4KPHA+T0F1dGggZW5hYmxlcyBh IHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9uIHRvIG9idGFpbiBsaW1pdGVkIGFj Y2VzcyB0byBhIHByb3RlY3RlZCByZXNvdXJjZSwgZWl0aGVyIG9uIGJlaGFs ZiBvZiBhIHJlc291cmNlIG93bmVyIGJ5IG9yY2hlc3RyYXRpbmcgYW4gYXBw cm92YWwgaW50ZXJhY3Rpb24sIG9yIGJ5IGFsbG93aW5nIHRoZSB0aGlyZC1w YXJ0eSBhcHBsaWNhdGlvbiB0byBvYnRhaW4gYWNjZXNzIG9uIGl0cyBvd24g YmVoYWxmLiAgPC9wPgo8cD5UaGlzIGRvY3VtZW50IGRlZmluZXMgaG93IGFu IGFwcGxpY2F0aW9uIGNsaWVudCB1c2VzIGNyZWRlbnRpYWxzIG9idGFpbmVk IHZpYSBPQXV0aCBvdmVyIHRoZSBTaW1wbGUgQXV0aGVudGljYXRpb24gYW5k IFNlY3VyaXR5IExheWVyIChTQVNMKSB0byBhY2Nlc3MgYSBwcm90ZWN0ZWQg cmVzb3VyY2UgYXQgYSByZXNvdXJjZSBzZXJ2ZS4gIFRoZXJlYnksIGl0IGVu YWJsZXMgc2NoZW1lcyBkZWZpbmVkIHdpdGhpbiB0aGUgT0F1dGggZnJhbWV3 b3JrIGZvciBub24tSFRUUC1iYXNlZCBhcHBsaWNhdGlvbiBwcm90b2NvbHMu ICA8L3A+CjxwPkNsaWVudHMgdHlwaWNhbGx5IHN0b3JlIHRoZSB1c2VyJ3Mg bG9uZy10ZXJtIGNyZWRlbnRpYWwuIFRoaXMgZG9lcywgaG93ZXZlciwgbGVh ZCB0byBzaWduaWZpY2FudCBzZWN1cml0eSB2dWxuZXJhYmlsaXRpZXMsIGZv ciBleGFtcGxlLCB3aGVuIHN1Y2ggYSBjcmVkZW50aWFsIGxlYWtzLiBBIHNp Z25pZmljYW50IGJlbmVmaXQgb2YgT0F1dGggZm9yIHVzYWdlIGluIHRob3Nl IGNsaWVudHMgaXMgdGhhdCB0aGUgcGFzc3dvcmQgaXMgcmVwbGFjZWQgYnkg YSBzaGFyZWQgc2VjcmV0IHdpdGggaGlnaGVyIGVudHJvcHksIGkuZS4sIHRo ZSB0b2tlbi4gVG9rZW5zIHR5cGljYWxseSBwcm92aWRlIGxpbWl0ZWQgYWNj ZXNzIHJpZ2h0cyBhbmQgY2FuIGJlIG1hbmFnZWQgYW5kIHJldm9rZWQgc2Vw YXJhdGVseSBmcm9tIHRoZSB1c2VyJ3MgbG9uZy10ZXJtIHBhc3N3b3JkLiAg PC9wPgo8aDEgaWQ9InJmYy5zdGF0dXMiPjxhIGhyZWY9IiNyZmMuc3RhdHVz Ij5TdGF0dXMgb2YgdGhpcyBNZW1vPC9hPjwvaDE+CjxwPlRoaXMgSW50ZXJu ZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0 aCB0aGUgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS48L3A+Cjxw PkludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhl IEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90 ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtp bmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9m IGN1cnJlbnQgSW50ZXJuZXQtIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLjwvcD4KPHA+SW50ZXJu ZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4 aW11bSBvZiBzaXggbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFj ZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55IHRp bWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFm dHMgYXMgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhl ciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8L3A+CjxwPlRoaXMgSW50 ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gU2VwdGVtYmVyIDExLCAyMDE0 LjwvcD4KPGgxIGlkPSJyZmMuY29weXJpZ2h0bm90aWNlIj48YSBocmVmPSIj cmZjLmNvcHlyaWdodG5vdGljZSI+Q29weXJpZ2h0IE5vdGljZTwvYT48L2gx Pgo8cD5Db3B5cmlnaHQgKGMpIDIwMTQgSUVURiBUcnVzdCBhbmQgdGhlIHBl cnNvbnMgaWRlbnRpZmllZCBhcyB0aGUgZG9jdW1lbnQgYXV0aG9ycy4gIEFs bCByaWdodHMgcmVzZXJ2ZWQuPC9wPgo8cD5UaGlzIGRvY3VtZW50IGlzIHN1 YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsIFBy b3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMgKGh0dHA6Ly90 cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRo ZSBkYXRlIG9mIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVh c2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cyBjYXJlZnVsbHksIGFzIHRoZXkg ZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJl c3BlY3QgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRy YWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QgaW5jbHVkZSBTaW1wbGlm aWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24g NC5lIG9mIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJv dmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcyBkZXNjcmliZWQgaW4gdGhlIFNp bXBsaWZpZWQgQlNEIExpY2Vuc2UuPC9wPgoKICAKICA8aHIgY2xhc3M9Im5v cHJpbnQiIC8+CiAgPGgxIGNsYXNzPSJucCIgaWQ9InJmYy50b2MiPjxhIGhy ZWY9IiNyZmMudG9jIj5UYWJsZSBvZiBDb250ZW50czwvYT48L2gxPgogIDx1 bCBjbGFzcz0idG9jIj4KCiAgCTxsaT4xLiAgIDxhIGhyZWY9IiNyZmMuc2Vj dGlvbi4xIj5JbnRyb2R1Y3Rpb248L2E+CjwvbGk+CjxsaT4yLiAgIDxhIGhy ZWY9IiNyZmMuc2VjdGlvbi4yIj5UZXJtaW5vbG9neTwvYT4KPC9saT4KPGxp PjMuICAgPGEgaHJlZj0iI3JmYy5zZWN0aW9uLjMiPk9BdXRoIFNBU0wgTWVj aGFuaXNtIFNwZWNpZmljYXRpb25zPC9hPgo8L2xpPgo8bGk+My4xLiAgIDxh IGhyZWY9IiNyZmMuc2VjdGlvbi4zLjEiPkluaXRpYWwgQ2xpZW50IFJlc3Bv bnNlPC9hPgo8L2xpPgo8bGk+My4xLjEuICAgPGEgaHJlZj0iI3JmYy5zZWN0 aW9uLjMuMS4xIj5SZXNlcnZlZCBLZXkvVmFsdWVzPC9hPgo8L2xpPgo8bGk+ My4yLiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlvbi4zLjIiPlNlcnZlcidzIFJl c3BvbnNlPC9hPgo8L2xpPgo8bGk+My4yLjEuICAgPGEgaHJlZj0iI3JmYy5z ZWN0aW9uLjMuMi4xIj5PQXV0aCBJZGVudGlmaWVycyBpbiB0aGUgU0FTTCBD b250ZXh0PC9hPgo8L2xpPgo8bGk+My4yLjIuICAgPGEgaHJlZj0iI3JmYy5z ZWN0aW9uLjMuMi4yIj5TZXJ2ZXIgUmVzcG9uc2UgdG8gRmFpbGVkIEF1dGhl bnRpY2F0aW9uPC9hPgo8L2xpPgo8bGk+My4yLjMuICAgPGEgaHJlZj0iI3Jm Yy5zZWN0aW9uLjMuMi4zIj5Db21wbGV0aW5nIGFuIEVycm9yIE1lc3NhZ2Ug U2VxdWVuY2U8L2E+CjwvbGk+CjxsaT4zLjMuICAgPGEgaHJlZj0iI3JmYy5z ZWN0aW9uLjMuMyI+T0F1dGggQWNjZXNzIFRva2VuIFR5cGVzIHVzaW5nIEtl eWVkIE1lc3NhZ2UgRGlnZXN0czwvYT4KPC9saT4KPGxpPjQuICAgPGEgaHJl Zj0iI3JmYy5zZWN0aW9uLjQiPkV4YW1wbGVzPC9hPgo8L2xpPgo8bGk+NC4x LiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlvbi40LjEiPlN1Y2Nlc3NmdWwgQmVh cmVyIFRva2VuIEV4Y2hhbmdlPC9hPgo8L2xpPgo8bGk+NC4yLiAgIDxhIGhy ZWY9IiNyZmMuc2VjdGlvbi40LjIiPlN1Y2Nlc3NmdWwgT0F1dGggMS4wYSBU b2tlbiBFeGNoYW5nZTwvYT4KPC9saT4KPGxpPjQuMy4gICA8YSBocmVmPSIj cmZjLnNlY3Rpb24uNC4zIj5GYWlsZWQgRXhjaGFuZ2U8L2E+CjwvbGk+Cjxs aT40LjQuICAgPGEgaHJlZj0iI3JmYy5zZWN0aW9uLjQuNCI+U01UUCBFeGFt cGxlIG9mIGEgRmFpbGVkIE5lZ290aWF0aW9uPC9hPgo8L2xpPgo8bGk+NS4g ICA8YSBocmVmPSIjcmZjLnNlY3Rpb24uNSI+U2VjdXJpdHkgQ29uc2lkZXJh dGlvbnM8L2E+CjwvbGk+CjxsaT42LiAgIDxhIGhyZWY9IiNyZmMuc2VjdGlv bi42Ij5JbnRlcm5hdGlvbmFsaXphdGlvbiBDb25zaWRlcmF0aW9uczwvYT4K PC9saT4KPGxpPjcuICAgPGEgaHJlZj0iI3JmYy5zZWN0aW9uLjciPklBTkEg Q29uc2lkZXJhdGlvbnM8L2E+CjwvbGk+CjxsaT43LjEuICAgPGEgaHJlZj0i I3JmYy5zZWN0aW9uLjcuMSI+U0FTTCBSZWdpc3RyYXRpb248L2E+CjwvbGk+ CjxsaT44LiAgIDxhIGhyZWY9IiNyZmMucmVmZXJlbmNlcyI+UmVmZXJlbmNl czwvYT4KPC9saT4KPGxpPjguMS4gICA8YSBocmVmPSIjcmZjLnJlZmVyZW5j ZXMuMSI+Tm9ybWF0aXZlIFJlZmVyZW5jZXM8L2E+CjwvbGk+CjxsaT44LjIu ICAgPGEgaHJlZj0iI3JmYy5yZWZlcmVuY2VzLjIiPkluZm9ybWF0aXZlIFJl ZmVyZW5jZXM8L2E+CjwvbGk+CjxsaT5BcHBlbmRpeCBBLiAgIDxhIGhyZWY9 IiNyZmMuYXBwZW5kaXguQXBwZW5kaXglMjBBIj5BY2tub3dsZWdlbWVudHM8 L2E+CjwvbGk+CjxsaT5BcHBlbmRpeCBCLiAgIDxhIGhyZWY9IiNyZmMuYXBw ZW5kaXguQXBwZW5kaXglMjBCIj5Eb2N1bWVudCBIaXN0b3J5PC9hPgo8L2xp Pgo8bGk+PGEgaHJlZj0iI3JmYy5hdXRob3JzIj5BdXRob3JzJyBBZGRyZXNz ZXM8L2E+CjwvbGk+CgoKICA8L3VsPgoKICA8aDEgaWQ9InJmYy5zZWN0aW9u LjEiPgo8YSBocmVmPSIjcmZjLnNlY3Rpb24uMSI+MS48L2E+IEludHJvZHVj dGlvbjwvaDE+CjxwIGlkPSJyZmMuc2VjdGlvbi4xLnAuMSI+T0F1dGggMS4w YSA8YSBocmVmPSIjUkZDNTg0OSI+W1JGQzU4NDldPC9hPiBhbmQgT0F1dGgg Mi4wIDxhIGhyZWY9IiNSRkM2NzQ5Ij5bUkZDNjc0OV08L2E+IGFyZSBwcm90 b2NvbCBmcmFtZXdvcmtzIHRoYXQgZW5hYmxlIGEgdGhpcmQtcGFydHkgYXBw bGljYXRpb24gdG8gb2J0YWluIGxpbWl0ZWQgYWNjZXNzIHRvIGEgcHJvdGVj dGVkIHJlc291cmNlLCBlaXRoZXIgb24gYmVoYWxmIG9mIGEgcmVzb3VyY2Ug b3duZXIgYnkgb3JjaGVzdHJhdGluZyBhbiBhcHByb3ZhbCBpbnRlcmFjdGlv biwgb3IgYnkgYWxsb3dpbmcgdGhlIHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9u IHRvIG9idGFpbiBhY2Nlc3Mgb24gaXRzIG93biBiZWhhbGYuIDwvcD4KPHAg aWQ9InJmYy5zZWN0aW9uLjEucC4yIj5UaGUgY29yZSBPQXV0aCAyLjAgc3Bl Y2lmaWNhdGlvbiA8YSBocmVmPSIjUkZDNjc0OSI+W1JGQzY3NDldPC9hPiBz cGVjaWZpZXMgdGhlIGludGVyYWN0aW9uIGJldHdlZW4gdGhlIE9BdXRoIGNs aWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyOyBpdCBkb2VzIG5v dCBkZWZpbmUgdGhlIGludGVyYWN0aW9uIGJldHdlZW4gdGhlIE9BdXRoIGNs aWVudCBhbmQgdGhlIHJlc291cmNlIHNlcnZlciBmb3IgdGhlIGFjY2VzcyB0 byBhIHByb3RlY3RlZCByZXNvdXJjZSB1c2luZyBhbiBBY2Nlc3MgVG9rZW4u ICBJbnN0ZWFkLCB0aGUgT0F1dGggY2xpZW50IHRvIHJlc291cmNlIHNlcnZl ciBpbnRlcmFjdGlvbiBpcyBkZXNjcmliZWQgaW4gc2VwYXJhdGUgc3BlY2lm aWNhdGlvbnMsIHN1Y2ggYXMgdGhlIGJlYXJlciB0b2tlbiBzcGVjaWZpY2F0 aW9uIDxhIGhyZWY9IiNSRkM2NzUwIj5bUkZDNjc1MF08L2E+IGFuZCB0aGUg TUFDIFRva2VuIHNwZWNpZmljYXRpb24gPGEgaHJlZj0iI0ktRC5pZXRmLW9h dXRoLXYyLWh0dHAtbWFjIj5bSS1ELmlldGYtb2F1dGgtdjItaHR0cC1tYWNd PC9hPi4gT0F1dGggMS4wYSBpbmNsdWRlZCB0aGUgcHJvdG9jb2wgc3BlY2lm aWNhdGlvbiBmb3IgdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgT0F1 dGggY2xpZW50IGFuZCB0aGUgcmVzb3VyY2Ugc2VydmVyIGluIDxhIGhyZWY9 IiNSRkM1ODQ5Ij5bUkZDNTg0OV08L2E+LiAgPC9wPgo8cCBpZD0icmZjLnNl Y3Rpb24uMS5wLjMiPlRoZSBtYWluIHVzZSBjYXNlcyBmb3IgT0F1dGggMi4w IGFuZCBPQXV0aCAxLjBhIGhhdmUgc28gZmFyIGZvY3VzZWQgb24gYW4gSFRU UC1iYXNlZCA8YSBocmVmPSIjUkZDMjYxNiI+W1JGQzI2MTZdPC9hPiBlbnZp cm9ubWVudCBvbmx5LiAgVGhpcyBkb2N1bWVudCBpbnRlZ3JhdGVzIE9BdXRo IDEuMGEgYW5kIE9BdXRoIDIuMCBpbnRvIG5vbi1IVFRQLWJhc2VkIGFwcGxp Y2F0aW9ucyB1c2luZyB0aGUgaW50ZWdyYXRpb24gaW50byBTQVNMLiAgSGVu Y2UsIHRoaXMgZG9jdW1lbnQgIHRha2VzIGFkdmFudGFnZSBvZiB0aGUgT0F1 dGggcHJvdG9jb2wgYW5kIGl0cyBkZXBsb3ltZW50IGJhc2UgdG8gcHJvdmlk ZSBhIHdheSB0byB1c2UgdGhlIFNpbXBsZSBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJpdHkgTGF5ZXIgKFNBU0wpIDxhIGhyZWY9IiNSRkM0NDIyIj5bUkZD NDQyMl08L2E+IHRvIGdhaW4gYWNjZXNzIHRvIHJlc291cmNlcyB3aGVuIHVz aW5nIG5vbi1IVFRQLWJhc2VkIHByb3RvY29scywgc3VjaCBhcyB0aGUgSW50 ZXJuZXQgTWVzc2FnZSBBY2Nlc3MgUHJvdG9jb2wgKElNQVApIDxhIGhyZWY9 IiNSRkMzNTAxIj5bUkZDMzUwMV08L2E+IGFuZCB0aGUgU2ltcGxlIE1haWwg VHJhbnNmZXIgUHJvdG9jb2wgKFNNVFApIDxhIGhyZWY9IiNSRkM1MzIxIj5b UkZDNTMyMV08L2E+LCB3aGljaCBpcyB3aGF0IHRoaXMgbWVtbyB1c2VzIGlu IHRoZSBleGFtcGxlcy48L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi4xLnAuNCI+ VG8gaWxsdXN0cmF0ZSB0aGUgaW1wYWN0IG9mIGludGVncmF0aW5nIHRoaXMg c3BlY2lmaWNhdGlvbiBpbnRvIGFuIE9BdXRoLWVuYWJsZWQgYXBwbGljYXRp b24gZW52aXJvbm1lbnQgPGEgaHJlZj0iI292ZXJ2aWV3Ij5GaWd1cmUgMTwv YT4gc2hvd3MgdGhlIGFic3RyYWN0IG1lc3NhZ2UgZmxvdyBvZiBPQXV0aCAy LjAgPGEgaHJlZj0iI1JGQzY3NDkiPltSRkM2NzQ5XTwvYT4uIEFzIGluZGlj YXRlZCBpbiB0aGUgZmlndXJlLCB0aGlzIGRvY3VtZW50IGltcGFjdHMgdGhl IGV4Y2hhbmdlIG9mIG1lc3NhZ2VzIChFKSBhbmQgKEYpIHNpbmNlIFNBU0wg aXMgdXNlZCBmb3IgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFu ZCB0aGUgcmVzb3VyY2Ugc2VydmVyIGluc3RlYWQgb2YgSFRUUC48L3A+Cjxk aXYgaWQ9IiNyZmMuZmlndXJlLjEiPjwvZGl2Pgo8ZGl2IGlkPSIjb3ZlcnZp ZXciPjwvZGl2Pgo8cHJlPgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0rCiAgICst LS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tLSsgIHwKICAgfCAgICAgICAgfC0tKEEpLS0gQXV0aG9y aXphdGlvbiBSZXF1ZXN0IC0tLSZndDt8ICAgUmVzb3VyY2UgICAgfCAgfAog ICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgIE93bmVyICAgICB8ICB8UGxhaW4KICAgfCAgICAgICAgfCZsdDst KEIpLS0tLS0tIEFjY2VzcyBHcmFudCAtLS0tLS0tLS18ICAgICAgICAgICAg ICAgfCAgfE9BdXRoCiAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsgIHwyLjAKICAgfCAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAKICAgfCAgICAgICAgfCAgICAgICAgIENsaWVu dCBDcmVkZW50aWFscyAmYW1wOyAgICAgKy0tLS0tLS0tLS0tLS0tLSsgIHwK ICAgfCAgICAgICAgfC0tKEMpLS0tLS0tIEFjY2VzcyBHcmFudCAtLS0tLS0t LSZndDt8IEF1dGhvcml6YXRpb24gfCAgfAogICB8IENsaWVudCB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIFNlcnZlciAgICB8 ICB8CiAgIHwgICAgICAgIHwmbHQ7LShEKS0tLS0tLSBBY2Nlc3MgVG9rZW4g LS0tLS0tLS0tfCAgICAgICAgICAgICAgIHwgIHwKICAgfCAgICAgICAgfCAg ICAgICh3LyBPcHRpb25hbCBSZWZyZXNoIFRva2VuKSArLS0tLS0tLS0tLS0t LS0tKyAgfAogICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0rCiAgIHwgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLS0tLSsKICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgfAogICB8ICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICB8ICB8T0F1dGgKICAgfCAgICAgICAgfC0tKEUpLS0tLS0tIEFjY2Vz cyBUb2tlbiAtLS0tLS0tLSZndDt8ICAgIFJlc291cmNlICAgfCAgfG92ZXIK ICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICBTZXJ2ZXIgICAgfCAgfFNBU0wKICAgfCAgICAgICAgfCZsdDst KEYpLS0tLSBQcm90ZWN0ZWQgUmVzb3VyY2UgLS0tLS18ICAgICAgICAgICAg ICAgfCAgfAogICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICB8CiAgICstLS0tLS0tLSsg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLSsgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tKwo8L3ByZT4KPHA+PC9w Pgo8cCBpZD0icmZjLnNlY3Rpb24uMS5wLjYiPlRoZSBTaW1wbGUgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyaXR5IExheWVyIChTQVNMKSBpcyBhIGZyYW1l d29yayBmb3IgcHJvdmlkaW5nIGF1dGhlbnRpY2F0aW9uIGFuZCBkYXRhIHNl Y3VyaXR5IHNlcnZpY2VzIGluIGNvbm5lY3Rpb24tb3JpZW50ZWQgcHJvdG9j b2xzIHZpYSByZXBsYWNlYWJsZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21z LiAgSXQgcHJvdmlkZXMgYSBzdHJ1Y3R1cmVkIGludGVyZmFjZSBiZXR3ZWVu IHByb3RvY29scyBhbmQgbWVjaGFuaXNtcy4gIFRoZSByZXN1bHRpbmcgZnJh bWV3b3JrIGFsbG93cyBuZXcgcHJvdG9jb2xzIHRvIHJldXNlIGV4aXN0aW5n IGF1dGhlbnRpY2F0aW9uIHByb3RvY29scyBhbmQgYWxsb3dzIG9sZCBwcm90 b2NvbHMgdG8gbWFrZSB1c2Ugb2YgbmV3IGF1dGhlbnRpY2F0aW9uIG1lY2hh bmlzbXMuICBUaGUgZnJhbWV3b3JrIGFsc28gcHJvdmlkZXMgYSBwcm90b2Nv bCBmb3Igc2VjdXJpbmcgc3Vic2VxdWVudCBwcm90b2NvbCBleGNoYW5nZXMg d2l0aGluIGEgZGF0YSBzZWN1cml0eSBsYXllci48L3A+CjxwIGlkPSJyZmMu c2VjdGlvbi4xLnAuNyI+V2hlbiBPQXV0aCBpcyBpbnRlZ3JhdGVkIGludG8g U0FTTCB0aGUgaGlnaC1sZXZlbCBzdGVwcyBhcmUgYXMgZm9sbG93czogPC9w PgoKPHVsIGNsYXNzPSJlbXB0eSI+CjxsaT4oQSkgIFRoZSBjbGllbnQgcmVx dWVzdHMgYXV0aG9yaXphdGlvbiBmcm9tIHRoZSByZXNvdXJjZSBvd25lci4g IFRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgY2FuIGJlIG1hZGUgZGlyZWN0 bHkgdG8gdGhlIHJlc291cmNlIG93bmVyIChhcyBzaG93biksIG9yIHByZWZl cmFibHkgaW5kaXJlY3RseSB2aWEgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IGFzIGFuIGludGVybWVkaWFyeS48L2xpPgo8bGk+KEIpICBUaGUgY2xpZW50 IHJlY2VpdmVzIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgd2hpY2ggaXMgYSBj cmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBh dXRob3JpemF0aW9uLCBleHByZXNzZWQgdXNpbmcgb25lIG9mIG91ciBncmFu dCB0eXBlcyBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBvciB1c2lu ZyBhbiBleHRlbnNpb24gZ3JhbnQgdHlwZS4gIFRoZSBhdXRob3JpemF0aW9u IGdyYW50IHR5cGUgZGVwZW5kcyBvbiB0aGUgbWV0aG9kIHVzZWQgYnkgdGhl IGNsaWVudCB0byByZXF1ZXN0IGF1dGhvcml6YXRpb24gYW5kIHRoZSB0eXBl cyBzdXBwb3J0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLjwvbGk+ CjxsaT4oQykgIFRoZSBjbGllbnQgcmVxdWVzdHMgYW4gYWNjZXNzIHRva2Vu IGJ5IGF1dGhlbnRpY2F0aW5nIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIGFuZCBwcmVzZW50aW5nIHRoZSBhdXRob3JpemF0aW9uIGdyYW50Ljwv bGk+CjxsaT4oRCkgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50 aWNhdGVzIHRoZSBjbGllbnQgYW5kIHZhbGlkYXRlcyB0aGUgYXV0aG9yaXph dGlvbiBncmFudCwgYW5kIGlmIHZhbGlkIGlzc3VlcyBhbiBhY2Nlc3MgdG9r ZW4uPC9saT4KPGxpPihFKSAgVGhlIGNsaWVudCByZXF1ZXN0cyB0aGUgcHJv dGVjdGVkIHJlc291cmNlIGZyb20gdGhlIHJlc291cmNlIHNlcnZlciBhbmQg YXV0aGVudGljYXRlcyBieSBwcmVzZW50aW5nIHRoZSBhY2Nlc3MgdG9rZW4u PC9saT4KPGxpPihGKSAgVGhlIHJlc291cmNlIHNlcnZlciB2YWxpZGF0ZXMg dGhlIGFjY2VzcyB0b2tlbiwgYW5kIGlmIHZhbGlkLCBpbmRpY2F0ZXMgYSBz dWNjZXNzZnVsIGF1dGhlbnRpY2F0aW9uLjwvbGk+CjwvdWw+Cgo8cD4gPC9w Pgo8cCBpZD0icmZjLnNlY3Rpb24uMS5wLjgiPkFnYWluLCBzdGVwcyAoRSkg YW5kIChGKSBhcmUgbm90IGRlZmluZWQgaW4gPGEgaHJlZj0iI1JGQzY3NDki PltSRkM2NzQ5XTwvYT4gKGJ1dCBhcmUgZGVzY3JpYmVkIGluLCBmb3IgZXhh bXBsZSwgPGEgaHJlZj0iI1JGQzY3NTAiPltSRkM2NzUwXTwvYT4gZm9yIHRo ZSBPQXV0aCBCZWFyZXIgVG9rZW4gaW5zdGVhZCkgYW5kIGFyZSB0aGUgbWFp biBmdW5jdGlvbmFsaXR5IHNwZWNpZmllZCB3aXRoaW4gdGhpcyBkb2N1bWVu dC4gQ29uc2VxdWVudGx5LCB0aGUgbWVzc2FnZSBleGNoYW5nZSBzaG93biBp biA8YSBocmVmPSIjb3ZlcnZpZXciPkZpZ3VyZSAxPC9hPiBpcyB0aGUgcmVz dWx0IG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gVGhlIGNsaWVudCB3aWxsIGdl bmVyYWxseSBuZWVkIHRvIGRldGVybWluZSB0aGUgYXV0aGVudGljYXRpb24g ZW5kcG9pbnRzIChhbmQgcGVyaGFwcyB0aGUgc2VydmljZSBlbmRwb2ludHMp IGJlZm9yZSB0aGUgT0F1dGggMi4wIHByb3RvY29sIGV4Y2hhbmdlIG1lc3Nh Z2VzIGluIHN0ZXBzIChBKS0oRCkgYXJlIGV4ZWN1dGVkLiAgVGhlIGRpc2Nv dmVyeSBvZiB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIGF1dGhvcml6YXRpb24g c2VydmVyIGVuZHBvaW50cyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlz IHNwZWNpZmljYXRpb24uICBUaGUgY2xpZW50IG11c3QgZGlzY292ZXIgdGhv c2UgZW5kcG9pbnRzIHVzaW5nIGEgZGlzY292ZXJ5IG1lY2hhbmlzbXMsIHN1 Y2ggYXMgV2ViZmluZ2VyIHVzaW5nIGhvc3QtbWV0YSA8YSBocmVmPSIjUkZD NzAzMyI+W1JGQzcwMzNdPC9hPi4gIEluIGJhbmQgZGlzY292ZXJ5IGlzIG5v dCB0ZW5hYmxlIGlmIGNsaWVudHMgc3VwcG9ydCB0aGUgT0F1dGggMi4wIHBh c3N3b3JkIGdyYW50LiBPbmNlIGNyZWRlbnRpYWxzIGFyZSBvYnRhaW5lZCB0 aGUgY2xpZW50IHByb2NlZWRzIHRvIHN0ZXBzIChFKSBhbmQgKEYpIGRlZmlu ZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLiAgPC9wPgo8cCBpZD0icmZjLnNl Y3Rpb24uMS5wLjkiPk9BdXRoIDEuMCBmb2xsb3dzIGEgc2ltaWxhciBtb2Rl bCBidXQgdXNlcyBhIGRpZmZlcmVudCB0ZXJtaW5vbG9neSBhbmQgZG9lcyBu b3Qgc2VwYXJhdGUgdGhlIHJlc291cmNlIHNlcnZlciBmcm9tIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlci48L3A+CjxoMSBpZD0icmZjLnNlY3Rpb24uMiI+ CjxhIGhyZWY9IiNyZmMuc2VjdGlvbi4yIj4yLjwvYT4gPGEgaHJlZj0iI3Rl cm1pbm9sb2d5IiBpZD0idGVybWlub2xvZ3kiPlRlcm1pbm9sb2d5PC9hPgo8 L2gxPgo8cCBpZD0icmZjLnNlY3Rpb24uMi5wLjEiPlRoZSBrZXkgd29yZHMg Ik1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hB TEwgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVE IiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJl IHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiA8YSBocmVmPSIj UkZDMjExOSI+W1JGQzIxMTldPC9hPi48L3A+CjxwIGlkPSJyZmMuc2VjdGlv bi4yLnAuMiI+VGhlIHJlYWRlciBpcyBhc3N1bWVkIHRvIGJlIGZhbWlsaWFy IHdpdGggdGhlIHRlcm1zIHVzZWQgaW4gdGhlIE9BdXRoIDIuMCBzcGVjaWZp Y2F0aW9uIDxhIGhyZWY9IiNSRkM2NzQ5Ij5bUkZDNjc0OV08L2E+IGFuZCBT QVNMIDxhIGhyZWY9IiNSRkM0NDIyIj5bUkZDNDQyMl08L2E+LjwvcD4KPHAg aWQ9InJmYy5zZWN0aW9uLjIucC4zIj5JbiBleGFtcGxlcywgIkM6IiBhbmQg IlM6IiBpbmRpY2F0ZSBsaW5lcyBzZW50IGJ5IHRoZSBjbGllbnQgYW5kIHNl cnZlciByZXNwZWN0aXZlbHkuIExpbmUgYnJlYWtzIGhhdmUgYmVlbiBpbnNl cnRlZCBmb3IgcmVhZGFiaWxpdHkuPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24u Mi5wLjQiPk5vdGUgdGhhdCB0aGUgSU1BUCBTQVNMIHNwZWNpZmljYXRpb24g cmVxdWlyZXMgYmFzZTY0IGVuY29kaW5nLCBzZWUgU2VjdGlvbiA0IG9mIDxh IGhyZWY9IiNSRkM0NjQ4Ij5bUkZDNDY0OF08L2E+LCBub3QgdGhpcyBtZW1v LjwvcD4KPGgxIGlkPSJyZmMuc2VjdGlvbi4zIj4KPGEgaHJlZj0iI3JmYy5z ZWN0aW9uLjMiPjMuPC9hPiA8YSBocmVmPSIjU0FTTC1PQVVUSCIgaWQ9IlNB U0wtT0FVVEgiPk9BdXRoIFNBU0wgTWVjaGFuaXNtIFNwZWNpZmljYXRpb25z PC9hPgo8L2gxPgo8cCBpZD0icmZjLnNlY3Rpb24uMy5wLjEiPlNBU0wgaXMg dXNlZCBhcyBhbiBhdXRoZW50aWNhdGlvbiBmcmFtZXdvcmsgaW4gYSB2YXJp ZXR5IG9mIGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29scy4gVGhpcyBkb2N1 bWVudCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcgU0FTTCBtZWNoYW5pc21zIGZv ciB1c2FnZSB3aXRoIE9BdXRoOiA8L3A+Cgo8dWwgY2xhc3M9ImVtcHR5Ij48 bGk+CjxkbD4KPGR0Pk9BVVRIQkVBUkVSOjwvZHQ+CjxkZCBzdHlsZT0ibWFy Z2luLWxlZnQ6IDgiPk9BdXRoIDIuMCBiZWFyZXIgdG9rZW5zLCBhcyBkZXNj cmliZWQgaW4gPGEgaHJlZj0iI1JGQzY3NTAiPltSRkM2NzUwXTwvYT4uIFJG QyA2NzUwIHVzZXMgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIHRv IHNlY3VyZSB0aGUgcHJvdG9jb2wgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUg Y2xpZW50IGFuZCB0aGUgcmVzb3VyY2Ugc2VydmVyLjwvZGQ+CjxkdD5PQVVU SDEwQTo8L2R0Pgo8ZGQgc3R5bGU9Im1hcmdpbi1sZWZ0OiA4Ij5PQXV0aCAx LjBhIE1BQyB0b2tlbnMgKHVzaW5nIHRoZSBITUFDLVNIQTEga2V5ZWQgbWVz c2FnZSBkaWdlc3QpLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjQuMiBv ZiA8YSBocmVmPSIjUkZDNTg0OSI+W1JGQzU4NDldPC9hPi4gIDwvZGQ+Cjwv ZGw+CjxwPiA8L3A+CjwvbGk+PC91bD4KCjxwPiBOZXcgZXh0ZW5zaW9ucyBt YXkgYmUgZGVmaW5lZCB0byBhZGQgYWRkaXRpb25hbCBPQXV0aCBBY2Nlc3Mg VG9rZW4gVHlwZXMuIFN1Y2ggYSBuZXcgU0FTTCBPQXV0aCBtZWNoYW5pc20g Y2FuIGJlIGFkZGVkIGJ5IHNpbXBseSByZWdpc3RlcmluZyB0aGUgbmV3IG5h bWUocykgYW5kIGNpdGluZyB0aGlzIHNwZWNpZmljYXRpb24gZm9yIHRoZSBm dXJ0aGVyIGRlZmluaXRpb24uICA8L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi4z LnAuMiI+VGhlc2UgbWVjaGFuaXNtcyBhcmUgY2xpZW50IGluaXRpYXRlZCBh bmQgbG9jay1zdGVwLCB0aGUgc2VydmVyIGFsd2F5cyByZXBseWluZyB0byBh IGNsaWVudCBtZXNzYWdlLiAgSW4gdGhlIGNhc2Ugd2hlcmUgdGhlIGNsaWVu dCBoYXMgYW5kIGNvcnJlY3RseSB1c2VzIGEgdmFsaWQgdG9rZW4gdGhlIGZs b3cgaXM6IDwvcD4KCjxvbD4KPGxpPkNsaWVudCBzZW5kcyBhIHZhbGlkIGFu ZCBjb3JyZWN0IGluaXRpYWwgY2xpZW50IHJlc3BvbnNlLiAgPC9saT4KPGxp PlNlcnZlciByZXNwb25kcyB3aXRoIGEgc3VjY2Vzc2Z1bCBhdXRoZW50aWNh dGlvbi4gIDwvbGk+Cjwvb2w+Cgo8cD4gSW4gdGhlIGNhc2Ugd2hlcmUgYXV0 aG9yaXphdGlvbiBmYWlscyB0aGUgc2VydmVyIHNlbmRzIGFuIGVycm9yIHJl c3VsdCwgdGhlbiBjbGllbnQgTVVTVCB0aGVuIHNlbmQgYW4gYWRkaXRpb25h bCBtZXNzYWdlIHRvIHRoZSBzZXJ2ZXIgaW4gb3JkZXIgdG8gYWxsb3cgdGhl IHNlcnZlciB0byBmaW5pc2ggdGhlIGV4Y2hhbmdlLiAgU29tZSBwcm90b2Nv bHMgYW5kIGNvbW1vbiBTQVNMIGltcGxlbWVudGF0aW9ucyBkbyBub3Qgc3Vw cG9ydCBib3RoIHNlbmRpbmcgYSBTQVNMIG1lc3NhZ2UgYW5kIGZpbmFsaXpp bmcgYSBTQVNMIG5lZ290aWF0aW9uLCB0aGUgYWRkaXRpb25hbCBjbGllbnQg bWVzc2FnZSBpbiB0aGUgZXJyb3IgY2FzZSBkZWFscyB3aXRoIHRoaXMgcHJv YmxlbS4gIFRoaXMgZXhjaGFuZ2UgaXM6IDwvcD4KCjxvbD4KPGxpPkNsaWVu dCBzZW5kcyBhbiBpbnZhbGlkIGluaXRpYWwgY2xpZW50IHJlc3BvbnNlLjwv bGk+CjxsaT5TZXJ2ZXIgcmVzcG9uZHMgd2l0aCBhbiBlcnJvciBtZXNzYWdl LiA8L2xpPgo8bGk+Q2xpZW50IHNlbmRzIGEgZHVtbXkgY2xpZW50IHJlc3Bv bnNlLjwvbGk+CjxsaT5TZXJ2ZXIgZmFpbHMgdGhlIGF1dGhlbnRpY2F0aW9u LjwvbGk+Cjwvb2w+Cgo8cD4gPC9wPgo8aDEgaWQ9InJmYy5zZWN0aW9uLjMu MSI+CjxhIGhyZWY9IiNyZmMuc2VjdGlvbi4zLjEiPjMuMS48L2E+IEluaXRp YWwgQ2xpZW50IFJlc3BvbnNlPC9oMT4KPHAgaWQ9InJmYy5zZWN0aW9uLjMu MS5wLjEiPkNsaWVudCByZXNwb25zZXMgYXJlIGEgR1MyIDxhIGhyZWY9IiNS RkM1ODAxIj5bUkZDNTgwMV08L2E+IGhlYWRlciBmb2xsb3dlZCBieSBhIGtl eS92YWx1ZSBwYWlyIHNlcXVlbmNlLCBvciBtYXkgYmUgZW1wdHkuIFRoZSBn czItaGVhZGVyIGlzIGRlZmluZWQgaGVyZSBmb3IgY29tcGF0aWJpbGl0eSB3 aXRoIEdTMiBpZiBhIEdTMiBtZWNoYW5pc20gaXMgZm9ybWFsbHkgZGVmaW5l ZCwgYnV0IHRoaXMgZG9jdW1lbnQgZG9lcyBub3QgZGVmaW5lIG9uZS4gIFRo ZXNlIGtleS92YWx1ZSBwYWlycyBjYXJyeSB0aGUgZXF1aXZhbGVudCB2YWx1 ZXMgZnJvbSBhbiBIVFRQIGNvbnRleHQgaW4gb3JkZXIgdG8gYmUgYWJsZSB0 byBjb21wbGV0ZSBhbiBPQXV0aCBzdHlsZSBIVFRQIGF1dGhvcml6YXRpb24u ICBVbmtub3duIGtleS92YWx1ZSBwYWlycyBNVVNUIGJlIGlnbm9yZWQgYnkg dGhlIHNlcnZlci4gVGhlIEFCTkYgPGEgaHJlZj0iI1JGQzUyMzQiPltSRkM1 MjM0XTwvYT4gc3ludGF4IGlzOiA8L3A+CjxkaXYgaWQ9IiNyZmMuZmlndXJl LjIiPjwvZGl2Pgo8cHJlPgogICAgICAgICAgICAKICBrdnNlcCAgICAgICAg ICA9ICV4MDEKICBrZXkgICAgICAgICAgICA9IDEqKEFMUEhBIC8gIiwiKQog IHZhbHVlICAgICAgICAgID0gKihWQ0hBUiAvIFNQIC8gSFRBQiAvIENSIC8g TEYgKQogIGt2cGFpciAgICAgICAgID0ga2V5ICI9IiB2YWx1ZSBrdnNlcAo7 O2dzMi1oZWFkZXIgICAgID0gU2VlIFJGQyA1ODAxCiAgY2xpZW50X3Jlc3Ag ICAgPSAoZ3MyLWhlYWRlciBrdnNlcCAwKmt2cGFpciBrdnNlcCkgLyBrdnNl cAo8L3ByZT4KPHA+PC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uMy4xLnAuMyI+ VGhlIEdTMiBoZWFkZXIgTVVTVCBpbmNsZGUgdGhlIHVzZXIgbmFtZSBhc29j aWF0ZWQgd2l0aCB0aGUgcmVzb3VyY2UgYmVpbmcgYWNjZXNzZWQsIHRoZSAi YXV0aHppZCIuICA8L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi4zLjEucC40Ij5U aGUgZm9sbG93aW5nIGtleS92YWx1ZSBwYWlycyBhcmUgZGVmaW5lZCBpbiB0 aGUgY2xpZW50IHJlc3BvbnNlOiA8L3A+CjxwPjwvcD4KCjx1bCBjbGFzcz0i ZW1wdHkiPjxsaT4KPGRsPgo8ZHQ+YXV0aCAoUkVRVUlSRUQpOjwvZHQ+Cjxk ZCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDgiPlRoZSBwYXlsb2FkIG9mIHRoZSBI VFRQIEF1dGhvcml6YXRpb24gaGVhZGVyIGZvciBhbiBlcXVpdmFsZW50IEhU VFAgT0F1dGggYXV0aG9yaXphdGlvbi48L2RkPgo8ZHQ+aG9zdDo8L2R0Pgo8 ZGQgc3R5bGU9Im1hcmdpbi1sZWZ0OiA4Ij5Db250YWlucyB0aGUgaG9zdCBu YW1lIHRvIHdoaWNoIHRoZSBjbGllbnQgY29ubmVjdGVkLjwvZGQ+CjxkdD5w b3J0OjwvZHQ+CjxkZCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDgiPkNvbnRhaW5z IHRoZSBwb3J0IG51bWJlciByZXByZXNlbnRlZCBhcyBhIGRlY2ltYWwgcG9z aXRpdmUgaW50ZWdlciBzdHJpbmcgd2l0aG91dCBsZWFkaW5nIHplcm9zIHRv IHdoaWNoIHRoZSBjbGllbnQgY29ubmVjdGVkLjwvZGQ+CjxkdD5xczo8L2R0 Pgo8ZGQgc3R5bGU9Im1hcmdpbi1sZWZ0OiA4Ij5UaGUgSFRUUCBxdWVyeSBz dHJpbmcuICBUaGlzIGlzIHJlc2VydmVkIGZvciBmdXR1cmUgdXNlLCB0aGUg Y2xpZW50IFNIT1VEIE5PVCBzZW5kIGl0LCBhbmQgaGFzIHRoZSBkZWZhdWx0 IHZhbHVlIG9mICIiLiAgPC9kZD4KPC9kbD4KPHA+IDwvcD4KPC9saT48L3Vs PgoKPHA+IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLjMuMS5wLjYiPkZvciBP QXV0aCB0b2tlbiB0eXBlcyB0aGF0IHVzZSBrZXllZCBtZXNzYWdlIGRpZ2Vz dHMgdGhlIGNsaWVudCBNVVNUIHNlbmQgaG9zdCBhbmQgcG9ydCBudW1iZXIg a2V5L3ZhbHVlcywgYW5kIHRoZSBzZXJ2ZXIgTVVTVCBmYWlsIGFuIGF1dGhv cml6YXRpb24gcmVxdWVzdCByZXF1aXJpbmcga2V5ZWQgbWVzc2FnZSBkaWdl c3RzIHRoYXQgZG8gbm90IGhhdmUgaG9zdCBhbmQgcG9ydCB2YWx1ZXMuICAg SW4gT0F1dGggMS4wYSBmb3IgZXhhbXBsZSwgdGhlIHNvLWNhbGxlZCAic2ln bmF0dXJlIGJhc2Ugc3RyaW5nIGNhbGN1bGF0aW9uIiBpbmNsdWRlcyB0aGUg cmVjb25zdHJ1Y3RlZCBIVFRQIFVSTC4gIDwvcD4KPGgxIGlkPSJyZmMuc2Vj dGlvbi4zLjEuMSI+CjxhIGhyZWY9IiNyZmMuc2VjdGlvbi4zLjEuMSI+My4x LjEuPC9hPiBSZXNlcnZlZCBLZXkvVmFsdWVzPC9oMT4KPHAgaWQ9InJmYy5z ZWN0aW9uLjMuMS4xLnAuMSI+SW4gdGhlc2UgbWVjaGFuaXNtcyB2YWx1ZXMg Zm9yIHBhdGgsIHF1ZXJ5IHN0cmluZyBhbmQgcG9zdCBib2R5IGFyZSBhc3Np Z25lZCBkZWZhdWx0IHZhbHVlcy4gIE9BdXRoIGF1dGhvcml6YXRpb24gc2No ZW1lcyBNQVkgZGVmaW5lIHVzYWdlIG9mIHRoZXNlIGluIHRoZSBTQVNMIGNv bnRleHQgYW5kIGV4dGVuZCB0aGlzIHNwZWNpZmljYXRpb24uICBGb3IgT0F1 dGggQWNjZXNzIFRva2VuIFR5cGVzIHRoYXQgdXNlIHJlcXVlc3Qga2V5ZWQg bWVzc2FnZSBkaWdlc3QgdGhlIGRlZmF1bHQgdmFsdWVzIE1VU1QgYmUgdXNl ZCB1bmxlc3MgZXhwbGljaXQgdmFsdWVzIGFyZSBwcm92aWRlZCBpbiB0aGUg Y2xpZW50IHJlc3BvbnNlLiAgVGhlIGZvbGxvd2luZyBrZXkgdmFsdWVzIGFy ZSByZXNlcnZlZCBmb3IgZnV0dXJlIHVzZTogPC9wPgoKPHVsIGNsYXNzPSJl bXB0eSI+PGxpPgo8ZGw+CjxkdD5tdGhkIChSRVNFUlZFRCk6PC9kdD4KPGRk IHN0eWxlPSJtYXJnaW4tbGVmdDogOCI+SFRUUCBtZXRob2QsIHRoZSBkZWZh dWx0IHZhbHVlIGlzICJQT1NUIi4gIDwvZGQ+CjxkdD5wYXRoIChSRVNFUlZF RCk6PC9kdD4KPGRkIHN0eWxlPSJtYXJnaW4tbGVmdDogOCI+SFRUUCBwYXRo IGRhdGEsIHRoZSBkZWZhdWx0IHZhbHVlIGlzICIvIi4gIDwvZGQ+CjxkdD5w b3N0IChSRVNFUlZFRCk6PC9kdD4KPGRkIHN0eWxlPSJtYXJnaW4tbGVmdDog OCI+SFRUUCBwb3N0IGRhdGEsIHRoZSBkZWZhdWx0IHZhbHVlIGlzICIiLiAg PC9kZD4KPC9kbD4KPHA+IDwvcD4KPC9saT48L3VsPgoKPHA+IDwvcD4KPGgx IGlkPSJyZmMuc2VjdGlvbi4zLjIiPgo8YSBocmVmPSIjcmZjLnNlY3Rpb24u My4yIj4zLjIuPC9hPiBTZXJ2ZXIncyBSZXNwb25zZTwvaDE+CjxwIGlkPSJy ZmMuc2VjdGlvbi4zLjIucC4xIj5UaGUgc2VydmVyIHZhbGlkYXRlcyB0aGUg cmVzcG9uc2UgcGVyIHRoZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgT0F1dGgg QWNjZXNzIFRva2VuIFR5cGVzIHVzZWQuICBJZiB0aGUgT0F1dGggQWNjZXNz IFRva2VuIFR5cGUgdXRpbGl6ZXMgYSBrZXllZCBtZXNzYWdlIGRpZ2VzdCBv ZiB0aGUgcmVxdWVzdCBwYXJhbWV0ZXJzIHRoZW4gdGhlIGNsaWVudCBtdXN0 IHByb3ZpZGUgYSBjbGllbnQgcmVzcG9uc2UgdGhhdCBzYXRpc2ZpZXMgdGhl IGRhdGEgcmVxdWlyZW1lbnRzIGZvciB0aGUgc2NoZW1lIGluIHVzZS4gIDwv cD4KPHAgaWQ9InJmYy5zZWN0aW9uLjMuMi5wLjIiPlRoZSBzZXJ2ZXIgcmVz cG9uZHMgdG8gYSBzdWNjZXNzZnVsbHkgdmVyaWZpZWQgY2xpZW50IG1lc3Nh Z2UgYnkgY29tcGxldGluZyB0aGUgU0FTTCBuZWdvdGlhdGlvbi4gVGhlIGF1 dGhlbnRpY2F0ZWQgaWRlbnRpdHkgcmVwb3J0ZWQgYnkgdGhlIFNBU0wgbWVj aGFuaXNtIGlzIHRoZSBpZGVudGl0eSBzZWN1cmVseSBlc3RhYmxpc2hlZCBm b3IgdGhlIGNsaWVudCB3aXRoIHRoZSBPQXV0aCBjcmVkZW50aWFsLiAgVGhl IGFwcGxpY2F0aW9uLCBub3QgdGhlIFNBU0wgbWVjaGFuaXNtLCBiYXNlZCBv biBsb2NhbCBhY2Nlc3MgcG9saWN5IGRldGVybWluZXMgd2hldGhlciB0aGUg aWRlbnRpdHkgcmVwb3J0ZWQgYnkgdGhlIG1lY2hhbmlzbSBpcyBhbGxvd2Vk IGFjY2VzcyB0byB0aGUgcmVxdWVzdGVkIHJlc291cmNlLiAgTm90ZSB0aGF0 IHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGF1dGh6LWlkIGlzIHNwZWNpZmllZCBi eSB0aGUgU0FTTCBmcmFtZXdvcmsgPGEgaHJlZj0iI1JGQzQ0MjIiPltSRkM0 NDIyXTwvYT4uPC9wPgo8aDEgaWQ9InJmYy5zZWN0aW9uLjMuMi4xIj4KPGEg aHJlZj0iI3JmYy5zZWN0aW9uLjMuMi4xIj4zLjIuMS48L2E+IE9BdXRoIElk ZW50aWZpZXJzIGluIHRoZSBTQVNMIENvbnRleHQ8L2gxPgo8cCBpZD0icmZj LnNlY3Rpb24uMy4yLjEucC4xIj5JbiB0aGUgT0F1dGggZnJhbWV3b3JrIHRo ZSBjbGllbnQgbWF5IGJlIGF1dGhlbnRpY2F0ZWQgYnkgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIGFuZCB0aGUgcmVzb3VyY2Ugb3duZXIgaXMgYXV0aGVu dGljYXRlZCB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIE9BdXRoIGFj Y2VzcyB0b2tlbnMgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gYWJvdXQgdGhl IGF1dGhlbnRpY2F0aW9uIG9mIHRoZSByZXNvdXJjZSBvd25lciBhbmQgYWJv dXQgdGhlIGNsaWVudCBhbmQgbWF5IHRoZXJlZm9yZSBtYWtlIHRoaXMgaW5m b3JtYXRpb24gYWNjZXNzaWJsZSB0byB0aGUgcmVzb3VyY2Ugc2VydmVyLjwv cD4KPHAgaWQ9InJmYy5zZWN0aW9uLjMuMi4xLnAuMiI+SWYgYm90aCBpZGVu dGlmaWVycyBhcmUgbmVlZGVkIGJ5IGFuIGFwcGxpY2F0aW9uIHRoZSBkZXZl bG9wZXIgd2lsbCBuZWVkIHRvIHByb3ZpZGUgYSB3YXkgdG8gY29tbXVuaWNh dGUgdGhhdCBmcm9tIHRoZSBTQVNMIG1lY2hhbmlzbSBiYWNrIHRvIHRoZSBh cHBsaWNhdGlvbi4gIDwvcD4KPGgxIGlkPSJyZmMuc2VjdGlvbi4zLjIuMiI+ CjxhIGhyZWY9IiNyZmMuc2VjdGlvbi4zLjIuMiI+My4yLjIuPC9hPiBTZXJ2 ZXIgUmVzcG9uc2UgdG8gRmFpbGVkIEF1dGhlbnRpY2F0aW9uPC9oMT4KPHAg aWQ9InJmYy5zZWN0aW9uLjMuMi4yLnAuMSI+Rm9yIGEgZmFpbGVkIGF1dGhl bnRpY2F0aW9uIHRoZSBzZXJ2ZXIgcmV0dXJucyBhIEpTT04gPGEgaHJlZj0i I1JGQzQ2MjciPltSRkM0NjI3XTwvYT4gZm9ybWF0dGVkIGVycm9yIHJlc3Vs dCwgYW5kIGZhaWxzIHRoZSBhdXRoZW50aWNhdGlvbi4gIFRoZSBlcnJvciBy ZXN1bHQgY29uc2lzdHMgb2YgdGhlIGZvbGxvd2luZyB2YWx1ZXM6IDwvcD4K Cjx1bCBjbGFzcz0iZW1wdHkiPjxsaT4KPGRsPgo8ZHQ+c3RhdHVzIChSRVFV SVJFRCk6PC9kdD4KPGRkIHN0eWxlPSJtYXJnaW4tbGVmdDogOCI+VGhlIGF1 dGhvcml6YXRpb24gZXJyb3IgY29kZS4gVmFsaWQgZXJyb3IgY29kZXMgYXJl IGRlZmluZWQgaW4gdGhlIElBTkEgIk9BdXRoIEV4dGVuc2lvbnMgRXJyb3Ig UmVnaXN0cnkiIHNwZWNpZmllZCBpbiB0aGUgT0F1dGggMiBjb3JlIHNwZWNp ZmljYXRpb24uICA8L2RkPgo8ZHQ+c2NvcGUgKE9QVElPTkFMKTo8L2R0Pgo8 ZGQgc3R5bGU9Im1hcmdpbi1sZWZ0OiA4Ij5BbiBPQXV0aCBzY29wZSB3aGlj aCBpcyB2YWxpZCB0byBhY2Nlc3MgdGhlIHNlcnZpY2UuICBUaGlzIG1heSBi ZSBlbXB0eSB3aGljaCBpbXBsaWVzIHRoYXQgdW5zY29wZWQgdG9rZW5zIGFy ZSByZXF1aXJlZCwgb3IgYSBzY29wZSB2YWx1ZS4gIElmIGEgc2NvcGUgaXMg c3BlY2lmaWVkIHRoZW4gYSBzaW5nbGUgc2NvcGUgaXMgcHJlZmVycmVkLCB1 c2Ugb2YgYSBzcGFjZSBzZXBhcmF0ZWQgbGlzdCBvZiBzY29wZXMgaXMgTk9U IFJFQ09NTUVOREVELiAgPC9kZD4KPC9kbD4KPHA+IDwvcD4KPC9saT48L3Vs PgoKPHA+IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLjMuMi4yLnAuMiI+SWYg dGhlIHJlc291cmNlIHNlcnZlciBwcm92aWRlcyBhIHNjb3BlIHRoZW4gdGhl IGNsaWVudCBNVVNUIGFsd2F5cyByZXF1ZXN0IHNjb3BlZCB0b2tlbnMgZnJv bSB0aGUgdG9rZW4gZW5kcG9pbnQuICBJZiB0aGUgcmVzb3VyY2Ugc2VydmVy IHByb3ZpZGVzIG5vIHNjb3BlIHRvIHRoZSBjbGllbnQgdGhlbiB0aGUgY2xp ZW50IFNIT1VMRCBwcmVzdW1lIGFuIGVtcHR5IHNjb3BlICh1bnNjb3BlZCB0 b2tlbikgaXMgbmVlZGVkLjwvcD4KPGgxIGlkPSJyZmMuc2VjdGlvbi4zLjIu MyI+CjxhIGhyZWY9IiNyZmMuc2VjdGlvbi4zLjIuMyI+My4yLjMuPC9hPiBD b21wbGV0aW5nIGFuIEVycm9yIE1lc3NhZ2UgU2VxdWVuY2U8L2gxPgo8cCBp ZD0icmZjLnNlY3Rpb24uMy4yLjMucC4xIj5TZWN0aW9uIDMuNiBvZiA8YSBo cmVmPSIjUkZDNDQyMiI+W1JGQzQ0MjJdPC9hPiBleHBsaWNpdGx5IHByb2hp Yml0cyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGluIGFuIHVuc3VjY2Vzc2Z1 bCBhdXRoZW50aWNhdGlvbiBvdXRjb21lLiAgVGhlcmVmb3JlLCB0aGUgZXJy b3IgbWVzc2FnZSBpcyBzZW50IGluIGEgbm9ybWFsIG1lc3NhZ2UuICBUaGUg Y2xpZW50IE1VU1QgdGhlbiBzZW5kIGFuIGFkZGl0aW9uYWwgY2xpZW50IHJl c3BvbnNlIGNvbnNpc3Rpbmcgb2YgYSBzaW5nbGUgJXgwMSAoY29udHJvbCBB KSBjaGFyYWN0ZXIgdG8gdGhlIHNlcnZlciBpbiBvcmRlciB0byBhbGxvdyB0 aGUgc2VydmVyIHRvIGZpbmlzaCB0aGUgZXhjaGFuZ2UuICA8L3A+CjxoMSBp ZD0icmZjLnNlY3Rpb24uMy4zIj4KPGEgaHJlZj0iI3JmYy5zZWN0aW9uLjMu MyI+My4zLjwvYT4gPGEgaHJlZj0iI2tleWVkLWRpZ2VzdHMiIGlkPSJrZXll ZC1kaWdlc3RzIj5PQXV0aCBBY2Nlc3MgVG9rZW4gVHlwZXMgdXNpbmcgS2V5 ZWQgTWVzc2FnZSBEaWdlc3RzPC9hPgo8L2gxPgo8cCBpZD0icmZjLnNlY3Rp b24uMy4zLnAuMSI+T0F1dGggQWNjZXNzIFRva2VuIFR5cGVzIG1heSB1c2Ug a2V5ZWQgbWVzc2FnZSBkaWdlc3RzIGFuZCB0aGUgY2xpZW50IGFuZCB0aGUg cmVzb3VyY2Ugc2VydmVyIG1heSBuZWVkIHRvIHBlcmZvcm0gYSBjcnlwdG9n cmFwaGljIGNvbXB1dGF0aW9uIGZvciBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBh bmQgZGF0YSBvcmlnaW4gYXV0aGVudGljYXRpb24uPC9wPgo8cCBpZD0icmZj LnNlY3Rpb24uMy4zLnAuMiI+T0F1dGggaXMgZGVzaWduZWQgZm9yIGFjY2Vz cyB0byByZXNvdXJjZXMgaWRlbnRpZmllZCBieSBVUklzLiAgU0FTTCBpcyBk ZXNpZ25lZCBmb3IgdXNlciBhdXRoZW50aWNhdGlvbiwgYW5kIGhhcyBubyBm YWNpbGl0eSBmb3IgbW9yZSBmaW5lLWdyYWluZWQgYWNjZXNzIGNvbnRyb2wu ICBJbiB0aGlzIHNwZWNpZmljYXRpb24gd2UgcmVxdWlyZSBvciBkZWZpbmUg ZGVmYXVsdCB2YWx1ZXMgZm9yIHRoZSBkYXRhIGVsZW1lbnRzIGZyb20gYW4g SFRUUCByZXF1ZXN0IHdoaWNoIGFsbG93IHRoZSBzaWduYXR1cmUgYmFzZSBz dHJpbmcgdG8gYmUgY29uc3RydWN0ZWQgcHJvcGVybHkuICBUaGUgZGVmYXVs dCBIVFRQIHBhdGggaXMgIi8iIGFuZCB0aGUgZGVmYXVsdCBwb3N0IGJvZHkg aXMgZW1wdHkuICBUaGVzZSBhdG9tcyBhcmUgZGVmaW5lZCBhcyBleHRlbnNp b24gcG9pbnRzIHNvIHRoYXQgbm8gY2hhbmdlcyBhcmUgbmVlZGVkIGlmIHRo ZXJlIGlzIGEgcmV2aXNpb24gb2YgU0FTTCB3aGljaCBzdXBwb3J0cyBtb3Jl IHNwZWNpZmljIHJlc291cmNlIGF1dGhvcml6YXRpb24sIGUuZy4sIElNQVAg YWNjZXNzIHRvIGEgc3BlY2lmaWMgZm9sZGVyIG9yIEZUUCBhY2Nlc3MgbGlt aXRlZCB0byBhIHNwZWNpZmljIGRpcmVjdG9yeS4gPC9wPgo8cCBpZD0icmZj LnNlY3Rpb24uMy4zLnAuMyI+VXNpbmcgdGhlIGV4YW1wbGUgaW4gdGhlIE9B dXRoIDEuMGEgc3BlY2lmaWNhdGlvbiBhcyBhIHN0YXJ0aW5nIHBvaW50LCBv biBhbiBJTUFQIHNlcnZlciBydW5uaW5nIG9uIHBvcnQgMTQzIGFuZCBnaXZl biB0aGUgT0F1dGggMS4wYSBzdHlsZSBhdXRob3JpemF0aW9uIHJlcXVlc3Qg KHdpdGggJXgwMSBzaG93biBhcyBeQSBhbmQgbGluZSBicmVha3MgYWRkZWQg Zm9yIHJlYWRhYmlsaXR5KSBiZWxvdzogPC9wPgo8ZGl2IGlkPSIjcmZjLmZp Z3VyZS4zIj48L2Rpdj4KPHByZT4KbixhPXVzZXJAZXhhbXBsZS5jb20sXkEK aG9zdD1leGFtcGxlLmNvbV5BCnBvcnQ9MTQzXkEKYXV0aD1PQXV0aCByZWFs bT0iRXhhbXBsZSIsCiAgICAgICAgICAgb2F1dGhfY29uc3VtZXJfa2V5PSI5 ZGpkajgyaDQ4ZGpzOWQyIiwKICAgICAgICAgICBvYXV0aF90b2tlbj0ia2tr OWQ3ZGgzazM5c2p2NyIsCiAgICAgICAgICAgb2F1dGhfc2lnbmF0dXJlX21l dGhvZD0iSE1BQy1TSEExIiwKICAgICAgICAgICBvYXV0aF90aW1lc3RhbXA9 IjEzNzEzMTIwMSIsCiAgICAgICAgICAgb2F1dGhfbm9uY2U9IjdkOGYzZTRh IiwKICAgICAgICAgICBvYXV0aF9zaWduYXR1cmU9IlRtOTBJR0VnY21WaGJD QnphV2R1WVhSMWNtVSUzRCJeQV5BCjwvcHJlPgo8cD48L3A+CjxwIGlkPSJy ZmMuc2VjdGlvbi4zLjMucC41Ij5UaGUgc2lnbmF0dXJlIGJhc2Ugc3RyaW5n IHdvdWxkIGJlIGNvbnN0cnVjdGVkIHBlciB0aGUgT0F1dGggMS4wIHNwZWNp ZmljYXRpb24gPGEgaHJlZj0iI1JGQzU4NDkiPltSRkM1ODQ5XTwvYT4gd2l0 aCB0aGUgZm9sbG93aW5nIHRoaW5ncyBub3RlZDogPC9wPgoKPHVsPgo8bGk+ VGhlIG1ldGhvZCB2YWx1ZSBpcyBkZWZhdWx0ZWQgdG8gUE9TVC48L2xpPgo8 bGk+VGhlIHNjaGVtZSBkZWZhdWx0cyB0byBiZSAiaHR0cCIsIGFuZCBhbnkg cG9ydCBudW1iZXIgb3RoZXIgdGhhbiA4MCBpcyBpbmNsdWRlZC48L2xpPgo8 bGk+VGhlIHBhdGggZGVmYXVsdHMgdG8gIi8iLjwvbGk+CjxsaT5UaGUgcXVl cnkgc3RyaW5nIGRlZmF1bHRzIHRvICIiLjwvbGk+CjwvdWw+Cgo8cD4gSW4g dGhpcyBleGFtcGxlIHRoZSBzaWduYXR1cmUgYmFzZSBzdHJpbmcgd2l0aCBs aW5lIGJyZWFrcyBhZGRlZCBmb3IgcmVhZGFiaWxpdHkgd291bGQgYmU6IDwv cD4KPGRpdiBpZD0iI3JmYy5maWd1cmUuNCI+PC9kaXY+CjxwcmU+ClBPU1Qm YW1wO2h0dHAlM0ElMkYlMkZleGFtcGxlLmNvbToxNDMlMkYmYW1wO29hdXRo X2NvbnN1bWVyX2tleSUzRDlkamRqODJoNAo4ZGpzOWQyJTI2b2F1dGhfbm9u Y2UlM0Q3ZDhmM2U0YSUyNm9hdXRoX3NpZ25hdHVyZV9tZXRob2QlM0RITUFD LVNICkExJTI2b2F1dGhfdGltZXN0YW1wJTNEMTM3MTMxMjAxJTI2b2F1dGhf dG9rZW4lM0Rra2s5ZDdkaDNrMzlzanY3CjwvcHJlPgo8cD48L3A+CjxoMSBp ZD0icmZjLnNlY3Rpb24uNCI+CjxhIGhyZWY9IiNyZmMuc2VjdGlvbi40Ij40 LjwvYT4gRXhhbXBsZXM8L2gxPgo8cCBpZD0icmZjLnNlY3Rpb24uNC5wLjEi PlRoZXNlIGV4YW1wbGVzIGlsbHVzdHJhdGUgZXhjaGFuZ2VzIGJldHdlZW4g YW4gSU1BUCBhbmQgU01UUCBjbGllbnRzIGFuZCBzZXJ2ZXJzLjwvcD4KPHAg aWQ9InJmYy5zZWN0aW9uLjQucC4yIj5Ob3RlIHRvIGltcGxlbWVudGVyczog IFRoZSBTQVNMIE9BdXRoIG1ldGhvZCBuYW1lcyBhcmUgY2FzZSBpbnNlbnNp dGl2ZS4gIE9uZSBleGFtcGxlIHVzZXMgIkJlYXJlciIgYnV0IHRoYXQgY291 bGQgYXMgZWFzaWx5IGJlICJiZWFyZXIiLCAiQkVBUkVSIiwgb3IgIkJlQXJF ciIuICA8L3A+CjxoMSBpZD0icmZjLnNlY3Rpb24uNC4xIj4KPGEgaHJlZj0i I3JmYy5zZWN0aW9uLjQuMSI+NC4xLjwvYT4gU3VjY2Vzc2Z1bCBCZWFyZXIg VG9rZW4gRXhjaGFuZ2U8L2gxPgo8cCBpZD0icmZjLnNlY3Rpb24uNC4xLnAu MSI+VGhpcyBleGFtcGxlIHNob3dzIGEgc3VjY2Vzc2Z1bCBPQXV0aCAyLjAg YmVhcmVyIHRva2VuIGV4Y2hhbmdlLiBOb3RlIHRoYXQgbGluZSBicmVha3Mg YXJlIGluc2VydGVkIGZvciByZWFkYWJpbGl0eSBhbmQgdGhlIHVuZGVybHlp bmcgVExTIGVzdGFibGlzaG1lbnQgaXMgbm90IHNob3duIGVpdGhlci48L3A+ CjxkaXYgaWQ9IiNyZmMuZmlndXJlLjUiPjwvZGl2Pgo8cHJlPgpTOiAqIE9L IElNQVA0cmV2MSBTZXJ2ZXIgUmVhZHkKQzogdDAgQ0FQQUJJTElUWQpTOiAq IENBUEFCSUxJVFkgSU1BUDRyZXYxIEFVVEg9T0FVVEhCRUFSRVIgU0FTTC1J UgpTOiB0MCBPSyBDb21wbGV0ZWQKQzogdDEgQVVUSEVOVElDQVRFIE9BVVRI QkVBUkVSIGJpeGhQWFZ6WlhKQVpYaGhiWEJzWlM1amIyMHNBV2h2YzNROWMy CiAgICAgIFZ5ZG1WeUxtVjRZVzF3YkdVdVkyOXRBWEJ2Y25ROU1UUXpBV0Yx ZEdnOVFtVmhjbVZ5SUhaR09XUm1kRFJ4YgogICAgICBWUmpNazUyWWpOU2JH TnJRbWhpU0ZKb1pHMXNlbVJIUlhWWk1qbDBRMmM5UFFFQgpTOiB0MSBPSyBT QVNMIGF1dGhlbnRpY2F0aW9uIHN1Y2NlZWRlZAo8L3ByZT4KPHA+PC9wPgo8 cCBpZD0icmZjLnNlY3Rpb24uNC4xLnAuMyI+QXMgcmVxdWlyZWQgYnkgSU1B UCA8YSBocmVmPSIjUkZDMzUwMSI+W1JGQzM1MDFdPC9hPiwgdGhlIHBheWxv YWRzIGFyZSBiYXNlNjQtZW5jb2RlZC4gVGhlIGRlY29kZWQgaW5pdGlhbCBj bGllbnQgcmVzcG9uc2UgKHdpdGggJXgwMSByZXByZXNlbnRlZCBhcyBeQSBh bmQgbG9uZyBsaW5lcyB3cmFwcGVkIGZvciByZWFkYWJpbGl0eSkgaXM6IDwv cD4KPGRpdiBpZD0iI3JmYy5maWd1cmUuNiI+PC9kaXY+CjxwcmU+Cm4sYT11 c2VyQGV4YW1wbGUuY29tLF5BaG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb21eQXBv cnQ9MTQzXkEKYXV0aD1CZWFyZXIgdkY5ZGZ0NHFtVGMyTnZiM1JsY2tCaGJI UmhkbWx6ZEdFdVkyOXRDZz09XkFeQQo8L3ByZT4KPHA+PC9wPgo8cCBpZD0i cmZjLnNlY3Rpb24uNC4xLnAuNSI+VGhlIHNhbWUgY3JlZGVudGlhbCB1c2Vk IGluIGFuIFNNVFAgZXhjaGFuZ2UgaXMgc2hvd24gYmVsb3cuICBOb3RlIHRo YXQgbGluZSBicmVha3MgYXJlIGluc2VydGVkIGZvciByZWFkYWJpbGl0eSwg YW5kIHRoYXQgdGhlIFNNVFAgcHJvdG9jb2wgdGVybWluYXRlcyBsaW5lcyB3 aXRoIENSIGFuZCBMRiBjaGFyYWN0ZXJzIChBU0NJSSB2YWx1ZXMgMHgwRCBh bmQgMHgwQSksIHRoZXNlIGFyZSBub3QgZGlzcGxheWVkIGV4cGxpY2l0bHkg aW4gdGhlIGV4YW1wbGUuPC9wPgo8ZGl2IGlkPSIjcmZjLmZpZ3VyZS43Ij48 L2Rpdj4KPHByZT4KW2Nvbm5lY3Rpb24gYmVnaW5zXQpTOiAyMjAgbXguZXhh bXBsZS5jb20gRVNNVFAgMTJzbTIwOTU2MDNma3MuOQpDOiBFSExPIHNlbmRl ci5leGFtcGxlLmNvbQpTOiAyNTAtbXguZXhhbXBsZS5jb20gYXQgeW91ciBz ZXJ2aWNlLFsxNzIuMzEuMTM1LjQ3XQpTOiAyNTAtU0laRSAzNTY1MTU4NApT OiAyNTAtOEJJVE1JTUUKUzogMjUwLUFVVEggTE9HSU4gUExBSU4gT0FVVEhC RUFSRVIKUzogMjUwLUVOSEFOQ0VEU1RBVFVTQ09ERVMKUzogMjUwIFBJUEVM SU5JTkcKQzogdDEgQVVUSEVOVElDQVRFIE9BVVRIQkVBUkVSIGJpeGhQWFZ6 WlhKQVpYaGhiWEJzWlM1amIyMHNBV2h2YzNROWMKICAgICAgMlZ5ZG1WeUxt VjRZVzF3YkdVdVkyOXRBWEJ2Y25ROU1UUXpBV0YxZEdnOVFtVmhjbVZ5SUha R09XUm1kRFIKICAgICAgeGJWUmpNazUyWWpOU2JHTnJRbWhpU0ZKb1pHMXNl bVJIUlhWWk1qbDBRMmM5UFFFQgpTOiAyMzUgQXV0aGVudGljYXRpb24gc3Vj Y2Vzc2Z1bC4KW2Nvbm5lY3Rpb24gY29udGludWVzLi4uXQogICAgICAgICAg ICA8L3ByZT4KPHA+PC9wPgo8aDEgaWQ9InJmYy5zZWN0aW9uLjQuMiI+Cjxh IGhyZWY9IiNyZmMuc2VjdGlvbi40LjIiPjQuMi48L2E+IFN1Y2Nlc3NmdWwg T0F1dGggMS4wYSBUb2tlbiBFeGNoYW5nZTwvaDE+CjxwIGlkPSJyZmMuc2Vj dGlvbi40LjIucC4xIj5UaGlzIGV4YW1wbGUgc2hvd3MgYSBzdWNjZXNzZnVs IE9BdXRoIDEuMGEgIHRva2VuIGV4Y2hhbmdlLiBOb3RlIHRoYXQgbGluZSBi cmVha3MgYXJlIGluc2VydGVkIGZvciByZWFkYWJpbGl0eSBhbmQgdGhlIHVu ZGVybHlpbmcgVExTIGVzdGFibGlzaG1lbnQgaXMgbm90IHNob3duLiAgU2ln bmF0dXJlIGNvbXB1dGF0aW9uIGlzIGRpc2N1c3NlZCBpbiA8YSBocmVmPSIj a2V5ZWQtZGlnZXN0cyI+U2VjdGlvbiAzLjM8L2E+LjwvcD4KPGRpdiBpZD0i I3JmYy5maWd1cmUuOCI+PC9kaXY+CjxwcmU+ClM6ICogT0sgSU1BUDRyZXYx IFNlcnZlciBSZWFkeQpDOiB0MCBDQVBBQklMSVRZClM6ICogQ0FQQUJJTElU WSBJTUFQNHJldjEgQVVUSD1PQVVUSEJFQVJFUiBPQVVUSDEwQSBTQVNMLUlS ClM6IHQwIE9LIENvbXBsZXRlZApDOiB0MSBBVVRIRU5USUNBVEUgT0FVVEgx MEEgYml4aFBYVnpaWEpBWlhoaGJYQnNaUzVqYjIwc0FXaHZjM1E5WlhoaGIK ICAgICAgWEJzWlM1amIyMEJjRzl5ZEQweE5ETUJZWFYwYUQxUFFYVjBhQ0J5 WldGc2JUMGlSWGhoYlhCc1pTSXNiMkYxCiAgICAgIGRHaGZZMjl1YzNWdFpY SmZhMlY1UFNJNVpHcGthamd5YURRNFpHcHpPV1F5SWl4dllYVjBhRjkwYjJ0 bGJqMAogICAgICBpYTJ0ck9XUTNaR2d6YXpNNWMycDJOeUlzYjJGMWRHaGZj MmxuYm1GMGRYSmxYMjFsZEdodlpEMGlTRTFCUXkKICAgICAgMVRTRUV4SWl4 dllYVjBhRjkwYVcxbGMzUmhiWEE5SWpFek56RXpNVEl3TVNJc2IyRjFkR2hm Ym05dVkyVTlJCiAgICAgIGpka09HWXpaVFJoSWl4dllYVjBhRjl6YVdkdVlY UjFjbVU5SWxSdE9UQkpSMFZuWTIxV2FHSkRRbnBoVjJSMQogICAgICBXVmhT TVdOdFZTVXpSQ0lCQVE9PQpTOiB0MSBPSyBTQVNMIGF1dGhlbnRpY2F0aW9u IHN1Y2NlZWRlZAo8L3ByZT4KPHA+PC9wPgo8cCBpZD0icmZjLnNlY3Rpb24u NC4yLnAuMyI+QXMgcmVxdWlyZWQgYnkgSU1BUCA8YSBocmVmPSIjUkZDMzUw MSI+W1JGQzM1MDFdPC9hPiwgdGhlIHBheWxvYWRzIGFyZSBiYXNlNjQtZW5j b2RlZC4gVGhlIGRlY29kZWQgaW5pdGlhbCBjbGllbnQgcmVzcG9uc2UgKHdp dGggJXgwMSByZXByZXNlbnRlZCBhcyBeQSBhbmQgbG9uZyBsaW5lcyB3cmFw cGVkIGZvciByZWFkYWJpbGl0eSkgaXM6IDwvcD4KPGRpdiBpZD0iI3JmYy5m aWd1cmUuOSI+PC9kaXY+CjxwcmU+Cm4sYT11c2VyQGV4YW1wbGUuY29tLF5B Cmhvc3Q9ZXhhbXBsZS5jb21eQQpwb3J0PTE0M15BCmF1dGg9T0F1dGggcmVh bG09IkV4YW1wbGUiLAogICAgICAgICAgIG9hdXRoX2NvbnN1bWVyX2tleT0i OWRqZGo4Mmg0OGRqczlkMiIsCiAgICAgICAgICAgb2F1dGhfdG9rZW49Imtr azlkN2RoM2szOXNqdjciLAogICAgICAgICAgIG9hdXRoX3NpZ25hdHVyZV9t ZXRob2Q9IkhNQUMtU0hBMSIsCiAgICAgICAgICAgb2F1dGhfdGltZXN0YW1w PSIxMzcxMzEyMDEiLAogICAgICAgICAgIG9hdXRoX25vbmNlPSI3ZDhmM2U0 YSIsCiAgICAgICAgICAgb2F1dGhfc2lnbmF0dXJlPSJUbTkwSUdFZ2NtVmhi Q0J6YVdkdVlYUjFjbVUlM0QiXkFeQTwvcHJlPgo8cD48L3A+CjxoMSBpZD0i cmZjLnNlY3Rpb24uNC4zIj4KPGEgaHJlZj0iI3JmYy5zZWN0aW9uLjQuMyI+ NC4zLjwvYT4gRmFpbGVkIEV4Y2hhbmdlPC9oMT4KPHAgaWQ9InJmYy5zZWN0 aW9uLjQuMy5wLjEiPlRoaXMgZXhhbXBsZSBzaG93cyBhIGZhaWxlZCBleGNo YW5nZSBiZWNhdXNlIG9mIHRoZSBlbXB0eSBBdXRob3JpemF0aW9uIGhlYWRl ciwgd2hpY2ggaXMgaG93IGEgY2xpZW50IGNhbiBxdWVyeSBmb3IgdGhlIG5l ZWRlZCBzY29wZS4gTm90ZSB0aGF0IGxpbmUgYnJlYWtzIGFyZSBpbnNlcnRl ZCBmb3IgcmVhZGFiaWxpdHkuPC9wPgo8ZGl2IGlkPSIjcmZjLmZpZ3VyZS4x MCI+PC9kaXY+CjxwcmU+ClM6ICogQ0FQQUJJTElUWSBJTUFQNHJldjEgQVVU SD1PQVVUSEJFQVJFUiBTQVNMLUlSIElNQVA0cmV2MSBTZXJ2ZXIgCiAgICAg UmVhZHkgClM6IHQwIE9LIENvbXBsZXRlZCAKQzogdDEgQVVUSEVOVElDQVRF IE9BVVRIQkVBUkVSIGJpeGhQWFZ6WlhKQVpYaGhiWEJzWlM1amIyMHNBVwog ICAgICBodmMzUTljMlZ5ZG1WeUxtVjRZVzF3YkdVdVkyOXRBWEJ2Y25ROU1U UXpBV0YxZEdnOUFRRT0KUzogKyBld29pYzNSaGRIVnpJam9pTkRBeElnb2lj Mk52Y0dVaU9pSmxlR0Z0Y0d4bFgzTmpiM0JsSWdwOQpDOiArIEFRPT0KUzog dDEgTk8gU0FTTCBhdXRoZW50aWNhdGlvbiBmYWlsZWQKPC9wcmU+CjxwPjwv cD4KPHAgaWQ9InJmYy5zZWN0aW9uLjQuMy5wLjMiPlRoZSBkZWNvZGVkIGlu aXRpYWwgY2xpZW50IHJlc3BvbnNlIGlzOiA8L3A+CjxkaXYgaWQ9IiNyZmMu ZmlndXJlLjExIj48L2Rpdj4KPHByZT4KbixhPXVzZXJAZXhhbXBsZS5jb20s XkFob3N0PXNlcnZlci5leGFtcGxlLmNvbV5BCnBvcnQ9MTQzXkFhdXRoPV5B XkEKICAgICAgICAgICAgPC9wcmU+CjxwPjwvcD4KPHAgaWQ9InJmYy5zZWN0 aW9uLjQuMy5wLjUiPlRoZSBkZWNvZGVkIHNlcnZlciBlcnJvciByZXNwb25z ZSBpczogPC9wPgo8ZGl2IGlkPSIjcmZjLmZpZ3VyZS4xMiI+PC9kaXY+Cjxw cmU+CnsKInN0YXR1cyI6IjQwMSIsCiJzY29wZSI6ImV4YW1wbGVfc2NvcGUi Cn0KICAgICAgICAgICAgPC9wcmU+CjxwPjwvcD4KPHAgaWQ9InJmYy5zZWN0 aW9uLjQuMy5wLjciPlRoZSBjbGllbnQgcmVzcG9uZHMgd2l0aCB0aGUgcmVx dWlyZWQgZHVtbXkgcmVzcG9uc2UuICA8L3A+CjxoMSBpZD0icmZjLnNlY3Rp b24uNC40Ij4KPGEgaHJlZj0iI3JmYy5zZWN0aW9uLjQuNCI+NC40LjwvYT4g U01UUCBFeGFtcGxlIG9mIGEgRmFpbGVkIE5lZ290aWF0aW9uPC9oMT4KPHAg aWQ9InJmYy5zZWN0aW9uLjQuNC5wLjEiPlRoaXMgZXhhbXBsZSBzaG93cyBh biBhdXRob3JpemF0aW9uIGZhaWx1cmUgaW4gYW4gU01UUCBleGNoYW5nZS4g IE5vdGUgdGhhdCBsaW5lIGJyZWFrcyBhcmUgaW5zZXJ0ZWQgZm9yIHJlYWRh YmlsaXR5LCBhbmQgdGhhdCB0aGUgU01UUCBwcm90b2NvbCB0ZXJtaW5hdGVz IGxpbmVzIHdpdGggQ1IgYW5kIExGIGNoYXJhY3RlcnMgKEFTQ0lJIHZhbHVl cyAweDBEIGFuZCAweDBBKSwgdGhlc2UgYXJlIG5vdCBkaXNwbGF5ZWQgZXhw bGljaXRseSBpbiB0aGUgZXhhbXBsZS48L3A+CjxkaXYgaWQ9IiNyZmMuZmln dXJlLjEzIj48L2Rpdj4KPHByZT4KW2Nvbm5lY3Rpb24gYmVnaW5zXQpTOiAy MjAgbXguZXhhbXBsZS5jb20gRVNNVFAgMTJzbTIwOTU2MDNma3MuOQpDOiBF SExPIHNlbmRlci5leGFtcGxlLmNvbQpTOiAyNTAtbXguZXhhbXBsZS5jb20g YXQgeW91ciBzZXJ2aWNlLFsxNzIuMzEuMTM1LjQ3XQpTOiAyNTAtU0laRSAz NTY1MTU4NApTOiAyNTAtOEJJVE1JTUUKUzogMjUwLUFVVEggTE9HSU4gUExB SU4gT0FVVEhCRUFSRVIKUzogMjUwLUVOSEFOQ0VEU1RBVFVTQ09ERVMKUzog MjUwIFBJUEVMSU5JTkcKQzogQVVUSCBPQVVUSEJFQVJFUiBiaXgxYzJWeVBY TnZiV1YxYzJWeVFHVjRZVzF3YkdVdVkyOXRMQUZoZFhSb1BVSmxZWEpsCiAg ICAgICAgY2lCMlJqbGtablEwY1cxVVl6Sk9kbUl6VW14amEwSm9aRWhTYUdS dGJIcGtSMFYxV1RJNWRFTm5QVDBCQVE9PQpTOiAzMzQgZXlKemRHRjBkWE1p T2lJME1ERWlMQ0p6WTJobGJXVnpJam9pWW1WaGNtVnlJRzFoWXlJc0luTmpi M0JsSWpvaWEKICAgICAgIEhSMGNITTZMeTl0WVdsc0xtZHZiMmRzWlM1amIy MHZJbjBLCkM6IEFRPT0KUzogNTM1LTUuNy4xIFVzZXJuYW1lIGFuZCBQYXNz d29yZCBub3QgYWNjZXB0ZWQuIExlYXJuIG1vcmUgYXQKUzogNTM1IDUuNy4x IGh0dHA6Ly9zdXBwb3J0LmV4YW1wbGUuY29tL21haWwvb2F1dGgKW2Nvbm5l Y3Rpb24gY29udGludWVzLi4uXQogICAgICAgICAgICA8L3ByZT4KPHA+PC9w Pgo8cCBpZD0icmZjLnNlY3Rpb24uNC40LnAuMyI+VGhlIHNlcnZlciByZXR1 cm5lZCBhbiBlcnJvciBtZXNzYWdlIGluIHRoZSAzMzQgU0FTTCBtZXNzYWdl LCB0aGUgY2xpZW50IHJlc3BvbmRzIHdpdGggdGhlIHJlcXVpcmVkIGR1bW15 IHJlc3BvbnNlLCBhbmQgdGhlIHNlcnZlciBmaW5hbGl6ZXMgdGhlIG5lZ290 aWF0aW9uLiAgPC9wPgo8aDEgaWQ9InJmYy5zZWN0aW9uLjUiPgo8YSBocmVm PSIjcmZjLnNlY3Rpb24uNSI+NS48L2E+IFNlY3VyaXR5IENvbnNpZGVyYXRp b25zPC9oMT4KPHAgaWQ9InJmYy5zZWN0aW9uLjUucC4xIj5PQXV0aCAxLjBh IGFuZCBPQXV0aCAyIGFsbG93cyBmb3IgYSB2YXJpZXR5IG9mIGRlcGxveW1l bnQgc2NlbmFyaW9zLCBhbmQgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2Yg dGhlc2UgcHJvZmlsZXMgdmFyeS4gQXMgc2hvd24gaW4gPGEgaHJlZj0iI292 ZXJ2aWV3Ij5GaWd1cmUgMTwvYT4gdGhpcyBzcGVjaWZpY2F0aW9uIGlzIGFp bWVkIHRvIGJlIGludGVncmF0ZWQgaW50byBhIGxhcmdlciBPQXV0aCBkZXBs b3ltZW50LiBBcHBsaWNhdGlvbiBkZXZlbG9wZXJzIHRoZXJlZm9yZSBuZWVk IHRvIHVuZGVyc3RhbmQgdGhlIG5lZWRzIG9mIHRoZWlyIHNlY3VyaXR5IHJl cXVpcmVtZW50cyBiYXNlZCBvbiBhIHRocmVhdCBhc3Nlc3NtZW50IGJlZm9y ZSBzZWxlY3RpbmcgYSBzcGVjaWZpYyBTQVNMIE9BdXRoIG1lY2hhbmlzbS4g Rm9yIE9BdXRoIDIuMCBhIGRldGFpbGVkIHNlY3VyaXR5IGRvY3VtZW50IDxh IGhyZWY9IiNSRkM2ODE5Ij5bUkZDNjgxOV08L2E+IHByb3ZpZGVzIGd1aWRh bmNlIHRvIHNlbGVjdCB0aG9zZSBPQXV0aCAyLjAgY29tcG9uZW50cyB0aGF0 IGhlbHAgdG8gbWl0aWdhdGUgdGhyZWF0cyBmb3IgYSBnaXZlbiBkZXBsb3lt ZW50LiBGb3IgT0F1dGggMS4wYSBTZWN0aW9uIDQgb2YgUkZDIDU4NDkgPGEg aHJlZj0iI1JGQzU4NDkiPltSRkM1ODQ5XTwvYT4gcHJvdmlkZXMgZ3VpZGFu Y2Ugc3BlY2lmaWMgdG8gT0F1dGggMS4wLjwvcD4KPHAgaWQ9InJmYy5zZWN0 aW9uLjUucC4yIj5UaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0d28gU0FTTCAg TWVjaGFuaXNtcyBmb3IgT0F1dGggYW5kIGVhY2ggY29tZXMgd2l0aCBkaWZm ZXJlbnQgc2VjdXJpdHkgcHJvcGVydGllcy4gIDwvcD4KCjxkbD4KPGR0Pk9B VVRIQkVBUkVSOjwvZHQ+CjxkZCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDgiPlRo aXMgbWVjaGFuaXNtIGJvcnJvd3MgZnJvbSBPQXV0aCAyLjAgYmVhcmVyIHRv a2VucyA8YSBocmVmPSIjUkZDNjc1MCI+W1JGQzY3NTBdPC9hPi4gSXQgcmVs aWVzIG9uIHRoZSBhcHBsaWNhdGlvbiB1c2luZyBUTFMgdG8gcHJvdGVjdCB0 aGUgT0F1dGggMi4wIEJlYXJlciBUb2tlbiBleGNoYW5nZTsgd2l0aG91dCBU TFMgdXNhZ2UgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyIHRoaXMgbWV0aG9k IGlzIGNvbXBsZXRlbHkgaW5zZWN1cmUuIENvbnNlcXVlbnRseSwgVExTIE1V U1QgYmUgcHJvdmlkZWQgYnkgdGhlIGFwcGxpY2F0aW9uIHdoZW4gY2hvb3Np bmcgdGhpcyBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20uPC9kZD4KPGR0Pk9B VVRIMTBBOjwvZHQ+CjxkZCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDgiPlRoaXMg bWVjaGFuaXNtIHJlLXVzZXMgT0F1dGggMS4wYSBNQUMgdG9rZW5zICh1c2lu ZyB0aGUgSE1BQy1TSEExIGtleWVkIG1lc3NhZ2UgZGlnZXN0KSwgYXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24gMy40LjIgb2YgPGEgaHJlZj0iI1JGQzU4NDki PltSRkM1ODQ5XTwvYT4uIFRvIGNvbXB1dGUgdGhlIGtleWVkIG1lc3NhZ2Ug ZGlnZXN0IGluIHRoZSBzYW1lIHdheSB3YXMgaW4gUkZDIDU4MzkgdGhpcyBz cGVjaWZpY2F0aW9uIGNvbnZleXMgYWRkaXRpb25hbCBwYXJhbWV0ZXJzIGJl dHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlci4gVGhpcyBTQVNMIG1l Y2hhbmlzbSBvbmx5IHN1cHBvcnRzIGNsaWVudCBhdXRoZW50aWNhdGlvbi4g SWYgc2VydmVyLXNpZGUgYXV0aGVudGljYXRpb24gaXMgZGVzaXJlYWJsZSB0 aGVuIGl0IG11c3QgYmUgcHJvdmlkZWQgYnkgdGhlIGFwcGxpY2F0aW9uIHVu ZGVybmVhdGggdGhlIFNBU0wgbGF5ZXIuIFRoZSB1c2Ugb2YgVExTIGlzIHN0 cm9uZ2x5IFJFQ09NTUVOREVELiAgPC9kZD4KPC9kbD4KCjxwPiA8L3A+Cjxw IGlkPSJyZmMuc2VjdGlvbi41LnAuMyI+QWRkaXRpb25hbGx5LCB0aGUgZm9s bG93aW5nIGFzcGVjdHMgYXJlIHdvcnRoIHBvaW50aW5nIG91dDogPC9wPgoK PGRsPgo8ZHQ+QW4gYWNjZXNzIHRva2VuIGlzIG5vdCBlcXVpdmFsZW50IHRv IHRoZSB1c2VyJ3MgbG9uZyB0ZXJtIHBhc3N3b3JkLjwvZHQ+CjxkZCBzdHls ZT0ibWFyZ2luLWxlZnQ6IDgiPgo8YnI+PGJyPiBDYXJlIGhhcyB0byBiZSB0 YWtlbiB3aGVuIHRoZXNlIE9BdXRoIGNyZWRlbnRpYWxzIGFyZSB1c2VkIGZv ciBhY3Rpb25zIGxpa2UgY2hhbmdpbmcgcGFzc3dvcmRzIChhcyBpdCBpcyBw b3NzaWJsZSB3aXRoIHNvbWUgcHJvdG9jb2xzLCBlLmcuLCBYTVBQIDxhIGhy ZWY9IiNSRkM2MTIwIj5bUkZDNjEyMF08L2E+KS4gVGhlIHJlc291cmNlIHNl cnZlciBzaG91bGQgZW5zdXJlIHRoYXQgYWN0aW9ucyB0YWtlbiBpbiB0aGUg YXV0aGVudGljYXRlZCBjaGFubmVsIGFyZSBhcHByb3ByaWF0ZSB0byB0aGUg c3RyZW5ndGggb2YgdGhlIHByZXNlbnRlZCBjcmVkZW50aWFsLjwvZGQ+Cjxk dD5MaWZldGltZSBvZiB0aGUgYXBwbGlhdGlvbiBzZXNzaW9ucy48L2R0Pgo8 ZGQgc3R5bGU9Im1hcmdpbi1sZWZ0OiA4Ij4KPGJyPjxicj4gSXQgaXMgcG9z c2libGUgdGhhdCBTQVNMIHdpbGwgYmUgYXV0aGVudGljYXRpbmcgYSBjb25u ZWN0aW9uIGFuZCB0aGUgbGlmZSBvZiB0aGF0IGNvbm5lY3Rpb24gbWF5IG91 dGxhc3QgdGhlIGxpZmUgb2YgdGhlIGFjY2VzcyB0b2tlbiB1c2VkIHRvIGVz dGFibGlzaCBpdC4gIFRoaXMgaXMgYSBjb21tb24gcHJvYmxlbSBpbiBhcHBs aWNhdGlvbiBwcm90b2NvbHMgd2hlcmUgY29ubmVjdGlvbnMgYXJlIGxvbmct bGl2ZWQsIGFuZCBub3QgYSBwcm9ibGVtIHdpdGggdGhpcyBtZWNoYW5pc20g cGVyIHNlLiBSZXNvdXJjZSBzZXJ2ZXJzIG1heSB1bmlsYXRlcmFsbHkgZGlz Y29ubmVjdCBjbGllbnRzIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgYXBwbGlj YXRpb24gcHJvdG9jb2wuPC9kZD4KPGR0PkFjY2VzcyB0b2tlbnMgaGF2ZSBh IGxpZmV0aW1lLjwvZHQ+CjxkZCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDgiPgo8 YnI+PGJyPiBSZWR1Y2luZyB0aGUgbGlmZXRpbWUgb2YgYW4gYWNjZXNzIHRv a2VuIHByb3ZpZGVzIHNlY3VyaXR5IGJlbmVmaXRzIGFuZCBPQXV0aCAyLjAg aW50cm9kdWNlcyByZWZyZXNoIHRva2VucyB0byBvYnRhaW4gbmV3IGFjY2Vz cyB0b2tlbiBvbiB0aGUgZmx5IHdpdGhvdXQgYW55IG5lZWQgZm9yIGEgaHVt YW4gaW50ZXJhY3Rpb24uICBBZGRpdGlvbmFsbHksIGEgcHJldmlvdXNseSBv YnRhaW5lZCBhY2Nlc3MgdG9rZW4gbWF5IGJlIHJldm9rZWQgb3IgcmVuZGVy ZWQgaW52YWxpZCBhdCBhbnkgdGltZS4gVGhlIGNsaWVudCBtYXkgcmVxdWVz dCBhIG5ldyBhY2Nlc3MgdG9rZW4gZm9yIGVhY2ggY29ubmVjdGlvbiB0byBh IHJlc291cmNlIHNlcnZlciwgYnV0IGl0IFNIT1VMRCBjYWNoZSBhbmQgcmUt dXNlIHZhbGlkIGNyZWRlbnRpYWxzLjwvZGQ+CjwvZGw+Cgo8cD4gPC9wPgo8 aDEgaWQ9InJmYy5zZWN0aW9uLjYiPgo8YSBocmVmPSIjcmZjLnNlY3Rpb24u NiI+Ni48L2E+IEludGVybmF0aW9uYWxpemF0aW9uIENvbnNpZGVyYXRpb25z PC9oMT4KPHAgaWQ9InJmYy5zZWN0aW9uLjYucC4xIj5UaGUgaWRlbnRpZmVy IGFzc2VydGVkIGJ5IHRoZSBPQXV0aCBhdXRob3JpemF0aW9uIHNlcnZlciBh Ym91dCB0aGUgcmVzb3VyY2Ugb3duZXIgaW5zaWRlIHRoZSBhY2Nlc3MgdG9r ZW4gbWF5IGJlIGRpc3BsYXllZCB0byBhIGh1bWFuLiBGb3IgZXhhbXBsZSwg d2hlbiBTQVNMIGlzIHVzZWQgaW4gdGhlIGNvbnRleHQgb2YgSU1BUCB0aGUg cmVzb3VyY2Ugc2VydmVyIG1heSBhc3NlcnQgdGhlIHJlc291cmNlIG93bmVy J3MgZW1haWwgYWRkcmVzcyB0byB0aGUgSU1BUCBzZXJ2ZXIgZm9yIHVzYWdl IGluIGFuIGVtYWlsLWJhc2VkIGFwcGxpY2F0aW9uLiBUaGUgaWRlbnRpZmll ciBtYXkgdGhlcmVmb3JlIGNvbnRhaW4gaW50ZXJuYXRpb25hbGl6ZWQgY2hh cmFjdGVycyBhbmQgYW4gYXBwbGljYXRpb24gbmVlZHMgdG8gZW5zdXJlIHRo YXQgdGhlIG1hcHBpbmcgYmV0d2VlbiB0aGUgaWRlbnRpZmllciBwcm92aWRl ZCBieSBPQXV0aCBpcyBzdWl0YWJsZSBmb3IgdXNlIHdpdGggdGhlIGFwcGxp Y2F0aW9uIGxheWVyIHByb3RvY29sIFNBU0wgaXMgaW5jb3Jwb3JhdGVkIGlu dG8uPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uNi5wLjIiPkF0IHRoZSB0aW1l IG9mIHdyaXRpbmcgdGhlIHN0YW5kYXJkaXphdGlvbiBvZiB0aGUgdmFyaW91 cyBjbGFpbXMgaW4gdGhlIGFjY2VzcyB0b2tlbiAoaW4gSlNPTiBmb3JtYXQp IGlzIHN0aWxsIG9uZ29pbmcsIHNlZSA8YSBocmVmPSIjSS1ELmlldGYtb2F1 dGgtanNvbi13ZWItdG9rZW4iPltJLUQuaWV0Zi1vYXV0aC1qc29uLXdlYi10 b2tlbl08L2E+LiBPbmNlIGNvbXBsZXRlZCBpdCB3aWxsIHByb3ZpZGUgYSBz dGFuZGFyZGl6ZWQgZm9ybWF0IGZvciBleGNoYW5naW5nIGlkZW50aXR5IGlu Zm9ybWF0aW9uIGJldHdlZW4gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFu ZCB0aGUgcmVzb3VyY2Ugc2VydmVyLjwvcD4KPGgxIGlkPSJyZmMuc2VjdGlv bi43Ij4KPGEgaHJlZj0iI3JmYy5zZWN0aW9uLjciPjcuPC9hPiBJQU5BIENv bnNpZGVyYXRpb25zPC9oMT4KPGgxIGlkPSJyZmMuc2VjdGlvbi43LjEiPgo8 YSBocmVmPSIjcmZjLnNlY3Rpb24uNy4xIj43LjEuPC9hPiBTQVNMIFJlZ2lz dHJhdGlvbjwvaDE+CjxwIGlkPSJyZmMuc2VjdGlvbi43LjEucC4xIj5UaGUg SUFOQSBpcyByZXF1ZXN0ZWQgdG8gcmVnaXN0ZXIgdGhlIGZvbGxvd2luZyBT QVNMIHByb2ZpbGU6IDwvcD4KCjx1bCBjbGFzcz0iZW1wdHkiPgo8bGk+U0FT TCBtZWNoYW5pc20gcHJvZmlsZTogT0FVVEhCRUFSRVI8L2xpPgo8bGk+U2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnM6IFNlZSB0aGlzIGRvY3VtZW50PC9saT4K PGxpPlB1Ymxpc2hlZCBTcGVjaWZpY2F0aW9uOiBTZWUgdGhpcyBkb2N1bWVu dDwvbGk+CjxsaT5Gb3IgZnVydGhlciBpbmZvcm1hdGlvbjogQ29udGFjdCB0 aGUgYXV0aG9ycyBvZiB0aGlzIGRvY3VtZW50LjwvbGk+CjxsaT5Pd25lci9D aGFuZ2UgY29udHJvbGxlcjogdGhlIElFVEY8L2xpPgo8bGk+Tm90ZTogTm9u ZTwvbGk+CjwvdWw+Cgo8cD4gPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uNy4x LnAuMiI+VGhlIElBTkEgaXMgcmVxdWVzdGVkIHRvIHJlZ2lzdGVyIHRoZSBm b2xsb3dpbmcgU0FTTCBwcm9maWxlOiA8L3A+Cgo8dWwgY2xhc3M9ImVtcHR5 Ij4KPGxpPlNBU0wgbWVjaGFuaXNtIHByb2ZpbGU6IE9BVVRIMTBBPC9saT4K PGxpPlNlY3VyaXR5IENvbnNpZGVyYXRpb25zOiBTZWUgdGhpcyBkb2N1bWVu dDwvbGk+CjxsaT5QdWJsaXNoZWQgU3BlY2lmaWNhdGlvbjogU2VlIHRoaXMg ZG9jdW1lbnQ8L2xpPgo8bGk+Rm9yIGZ1cnRoZXIgaW5mb3JtYXRpb246IENv bnRhY3QgdGhlIGF1dGhvcnMgb2YgdGhpcyBkb2N1bWVudC48L2xpPgo8bGk+ T3duZXIvQ2hhbmdlIGNvbnRyb2xsZXI6IHRoZSBJRVRGPC9saT4KPGxpPk5v dGU6IE5vbmU8L2xpPgo8L3VsPgoKPHA+IDwvcD4KPGgxIGlkPSJyZmMucmVm ZXJlbmNlcyI+CjxhIGhyZWY9IiNyZmMucmVmZXJlbmNlcyI+OC48L2E+IFJl ZmVyZW5jZXM8L2gxPgo8aDEgaWQ9InJmYy5yZWZlcmVuY2VzLjEiPgo8YSBo cmVmPSIjcmZjLnJlZmVyZW5jZXMuMSI+OC4xLjwvYT4gTm9ybWF0aXZlIFJl ZmVyZW5jZXM8L2gxPgo8dGFibGU+PHRib2R5Pgo8dHI+Cjx0ZCBjbGFzcz0i cmVmZXJlbmNlIj48YiBpZD0iUkZDMjExOSI+W1JGQzIxMTldPC9iPjwvdGQ+ Cjx0ZCBjbGFzcz0idG9wIj4KPGEgaHJlZj0ibWFpbHRvOnNvYkBoYXJ2YXJk LmVkdSIgdGl0bGU9IkhhcnZhcmQgVW5pdmVyc2l0eSI+QnJhZG5lciwgUy48 L2E+LCAiPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj MjExOSI+S2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBS ZXF1aXJlbWVudCBMZXZlbHM8L2E+IiwgQkNQIDE0LCBSRkMgMjExOSwgTWFy Y2ggMTk5Ny48L3RkPgo8L3RyPgo8dHI+Cjx0ZCBjbGFzcz0icmVmZXJlbmNl Ij48YiBpZD0iUkZDMzE3NCI+W1JGQzMxNzRdPC9iPjwvdGQ+Cjx0ZCBjbGFz cz0idG9wIj4KPGE+RWFzdGxha2UsIEQuPC9hPiBhbmQgPGE+UC4gSm9uZXM8 L2E+LCAiPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj MzE3NCI+VVMgU2VjdXJlIEhhc2ggQWxnb3JpdGhtIDEgKFNIQTEpPC9hPiIs IFJGQyAzMTc0LCBTZXB0ZW1iZXIgMjAwMS48L3RkPgo8L3RyPgo8dHI+Cjx0 ZCBjbGFzcz0icmVmZXJlbmNlIj48YiBpZD0iUkZDNDQyMiI+W1JGQzQ0MjJd PC9iPjwvdGQ+Cjx0ZCBjbGFzcz0idG9wIj4KPGE+TWVsbmlrb3YsIEEuPC9h PiBhbmQgPGE+Sy4gWmVpbGVuZ2E8L2E+LCAiPGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNDQyMiI+U2ltcGxlIEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cml0eSBMYXllciAoU0FTTCk8L2E+IiwgUkZDIDQ0MjIs IEp1bmUgMjAwNi48L3RkPgo8L3RyPgo8dHI+Cjx0ZCBjbGFzcz0icmVmZXJl bmNlIj48YiBpZD0iUkZDNDYyNyI+W1JGQzQ2MjddPC9iPjwvdGQ+Cjx0ZCBj bGFzcz0idG9wIj4KPGE+Q3JvY2tmb3JkLCBELjwvYT4sICI8YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NjI3Ij5UaGUgYXBwbGlj YXRpb24vanNvbiBNZWRpYSBUeXBlIGZvciBKYXZhU2NyaXB0IE9iamVjdCBO b3RhdGlvbiAoSlNPTik8L2E+IiwgUkZDIDQ2MjcsIEp1bHkgMjAwNi48L3Rk Pgo8L3RyPgo8dHI+Cjx0ZCBjbGFzcz0icmVmZXJlbmNlIj48YiBpZD0iUkZD NTI0NiI+W1JGQzUyNDZdPC9iPjwvdGQ+Cjx0ZCBjbGFzcz0idG9wIj4KPGE+ RGllcmtzLCBULjwvYT4gYW5kIDxhPkUuIFJlc2NvcmxhPC9hPiwgIjxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyNDYiPlRoZSBU cmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykgUHJvdG9jb2wgVmVyc2lv biAxLjI8L2E+IiwgUkZDIDUyNDYsIEF1Z3VzdCAyMDA4LjwvdGQ+CjwvdHI+ Cjx0cj4KPHRkIGNsYXNzPSJyZWZlcmVuY2UiPjxiIGlkPSJSRkM1MjM0Ij5b UkZDNTIzNF08L2I+PC90ZD4KPHRkIGNsYXNzPSJ0b3AiPgo8YT5Dcm9ja2Vy LCBELjwvYT4gYW5kIDxhPlAuIE92ZXJlbGw8L2E+LCAiPGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTIzNCI+QXVnbWVudGVkIEJO RiBmb3IgU3ludGF4IFNwZWNpZmljYXRpb25zOiBBQk5GPC9hPiIsIFNURCA2 OCwgUkZDIDUyMzQsIEphbnVhcnkgMjAwOC48L3RkPgo8L3RyPgo8dHI+Cjx0 ZCBjbGFzcz0icmVmZXJlbmNlIj48YiBpZD0iUkZDNTg0OSI+W1JGQzU4NDld PC9iPjwvdGQ+Cjx0ZCBjbGFzcz0idG9wIj4KPGE+SGFtbWVyLUxhaGF2LCBF LjwvYT4sICI8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM1ODQ5Ij5UaGUgT0F1dGggMS4wIFByb3RvY29sPC9hPiIsIFJGQyA1ODQ5 LCBBcHJpbCAyMDEwLjwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGNsYXNzPSJyZWZl cmVuY2UiPjxiIGlkPSJSRkM1ODAxIj5bUkZDNTgwMV08L2I+PC90ZD4KPHRk IGNsYXNzPSJ0b3AiPgo8YT5Kb3NlZnNzb24sIFMuPC9hPiBhbmQgPGE+Ti4g V2lsbGlhbXM8L2E+LCAiPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNTgwMSI+VXNpbmcgR2VuZXJpYyBTZWN1cml0eSBTZXJ2aWNl IEFwcGxpY2F0aW9uIFByb2dyYW0gSW50ZXJmYWNlIChHU1MtQVBJKSBNZWNo YW5pc21zIGluIFNpbXBsZSBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJpdHkg TGF5ZXIgKFNBU0wpOiBUaGUgR1MyIE1lY2hhbmlzbSBGYW1pbHk8L2E+Iiwg UkZDIDU4MDEsIEp1bHkgMjAxMC48L3RkPgo8L3RyPgo8dHI+Cjx0ZCBjbGFz cz0icmVmZXJlbmNlIj48YiBpZD0iUkZDNDY0OCI+W1JGQzQ2NDhdPC9iPjwv dGQ+Cjx0ZCBjbGFzcz0idG9wIj4KPGE+Sm9zZWZzc29uLCBTLjwvYT4sICI8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NjQ4Ij5U aGUgQmFzZTE2LCBCYXNlMzIsIGFuZCBCYXNlNjQgRGF0YSBFbmNvZGluZ3M8 L2E+IiwgUkZDIDQ2NDgsIE9jdG9iZXIgMjAwNi48L3RkPgo8L3RyPgo8dHI+ Cjx0ZCBjbGFzcz0icmVmZXJlbmNlIj48YiBpZD0iUkZDNjc0OSI+W1JGQzY3 NDldPC9iPjwvdGQ+Cjx0ZCBjbGFzcz0idG9wIj4KPGE+SGFyZHQsIEQuPC9h PiwgIjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3 NDkiPlRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcms8L2E+ IiwgUkZDIDY3NDksIE9jdG9iZXIgMjAxMi48L3RkPgo8L3RyPgo8dHI+Cjx0 ZCBjbGFzcz0icmVmZXJlbmNlIj48YiBpZD0iUkZDNjc1MCI+W1JGQzY3NTBd PC9iPjwvdGQ+Cjx0ZCBjbGFzcz0idG9wIj4KPGE+Sm9uZXMsIE0uPC9hPiBh bmQgPGE+RC4gSGFyZHQ8L2E+LCAiPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNjc1MCI+VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0 aW9uIEZyYW1ld29yazogQmVhcmVyIFRva2VuIFVzYWdlPC9hPiIsIFJGQyA2 NzUwLCBPY3RvYmVyIDIwMTIuPC90ZD4KPC90cj4KPC90Ym9keT48L3RhYmxl Pgo8aDEgaWQ9InJmYy5yZWZlcmVuY2VzLjIiPgo8YSBocmVmPSIjcmZjLnJl ZmVyZW5jZXMuMiI+OC4yLjwvYT4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlczwv aDE+Cjx0YWJsZT48dGJvZHk+Cjx0cj4KPHRkIGNsYXNzPSJyZWZlcmVuY2Ui PjxiIGlkPSJSRkMyNjE2Ij5bUkZDMjYxNl08L2I+PC90ZD4KPHRkIGNsYXNz PSJ0b3AiPgo8YSBocmVmPSJtYWlsdG86ZmllbGRpbmdAaWNzLnVjaS5lZHUi IHRpdGxlPSJEZXBhcnRtZW50IG9mIEluZm9ybWF0aW9uIGFuZCBDb21wdXRl ciBTY2llbmNlIj5GaWVsZGluZywgUi48L2E+LCA8YSBocmVmPSJtYWlsdG86 amdAdzMub3JnIiB0aXRsZT0iV29ybGQgV2lkZSBXZWIgQ29uc29ydGl1bSI+ R2V0dHlzLCBKLjwvYT4sIDxhIGhyZWY9Im1haWx0bzptb2d1bEB3cmwuZGVj LmNvbSIgdGl0bGU9IkNvbXBhcSBDb21wdXRlciBDb3Jwb3JhdGlvbiI+TW9n dWwsIEouPC9hPiwgPGEgaHJlZj0ibWFpbHRvOmZyeXN0eWtAdzMub3JnIiB0 aXRsZT0iV29ybGQgV2lkZSBXZWIgQ29uc29ydGl1bSI+RnJ5c3R5aywgSC48 L2E+LCA8YSBocmVmPSJtYWlsdG86bWFzaW50ZXJAcGFyYy54ZXJveC5jb20i IHRpdGxlPSJYZXJveCBDb3Jwb3JhdGlvbiI+TWFzaW50ZXIsIEwuPC9hPiwg PGEgaHJlZj0ibWFpbHRvOnBhdWxsZUBtaWNyb3NvZnQuY29tIiB0aXRsZT0i TWljcm9zb2Z0IENvcnBvcmF0aW9uIj5MZWFjaCwgUC48L2E+IGFuZCA8YSBo cmVmPSJtYWlsdG86dGltYmxAdzMub3JnIiB0aXRsZT0iV29ybGQgV2lkZSBX ZWIgQ29uc29ydGl1bSI+VC4gQmVybmVycy1MZWU8L2E+LCAiPGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjYxNiI+SHlwZXJ0ZXh0 IFRyYW5zZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xPC9hPiIsIFJGQyAyNjE2 LCBKdW5lIDE5OTkuPC90ZD4KPC90cj4KPHRyPgo8dGQgY2xhc3M9InJlZmVy ZW5jZSI+PGIgaWQ9IlJGQzUzMjEiPltSRkM1MzIxXTwvYj48L3RkPgo8dGQg Y2xhc3M9InRvcCI+CjxhPktsZW5zaW4sIEouPC9hPiwgIjxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUzMjEiPlNpbXBsZSBNYWls IFRyYW5zZmVyIFByb3RvY29sPC9hPiIsIFJGQyA1MzIxLCBPY3RvYmVyIDIw MDguPC90ZD4KPC90cj4KPHRyPgo8dGQgY2xhc3M9InJlZmVyZW5jZSI+PGIg aWQ9IlJGQzM1MDEiPltSRkMzNTAxXTwvYj48L3RkPgo8dGQgY2xhc3M9InRv cCI+CjxhPkNyaXNwaW4sIE0uPC9hPiwgIjxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzM1MDEiPklOVEVSTkVUIE1FU1NBR0UgQUND RVNTIFBST1RPQ09MIC0gVkVSU0lPTiA0cmV2MTwvYT4iLCBSRkMgMzUwMSwg TWFyY2ggMjAwMy48L3RkPgo8L3RyPgo8dHI+Cjx0ZCBjbGFzcz0icmVmZXJl bmNlIj48YiBpZD0iUkZDNjEyMCI+W1JGQzYxMjBdPC9iPjwvdGQ+Cjx0ZCBj bGFzcz0idG9wIj4KPGE+U2FpbnQtQW5kcmUsIFAuPC9hPiwgIjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYxMjAiPkV4dGVuc2li bGUgTWVzc2FnaW5nIGFuZCBQcmVzZW5jZSBQcm90b2NvbCAoWE1QUCk6IENv cmU8L2E+IiwgUkZDIDYxMjAsIE1hcmNoIDIwMTEuPC90ZD4KPC90cj4KPHRy Pgo8dGQgY2xhc3M9InJlZmVyZW5jZSI+PGIgaWQ9IlJGQzcwMzMiPltSRkM3 MDMzXTwvYj48L3RkPgo8dGQgY2xhc3M9InRvcCI+CjxhPkpvbmVzLCBQLjwv YT4sIDxhPlNhbGd1ZWlybywgRy48L2E+LCA8YT5Kb25lcywgTS48L2E+IGFu ZCA8YT5KLiBTbWFycjwvYT4sICI8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM3MDMzIj5XZWJGaW5nZXI8L2E+IiwgUkZDIDcwMzMs IFNlcHRlbWJlciAyMDEzLjwvdGQ+CjwvdHI+Cjx0cj4KPHRkIGNsYXNzPSJy ZWZlcmVuY2UiPjxiIGlkPSJJLUQuaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tl biI+W0ktRC5pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuXTwvYj48L3RkPgo8 dGQgY2xhc3M9InRvcCI+CjxhPkpvbmVzLCBNPC9hPiwgPGE+QnJhZGxleSwg SjwvYT4gYW5kIDxhPk4gU2FraW11cmE8L2E+LCAiPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdl Yi10b2tlbi0xMyI+SlNPTiBXZWIgVG9rZW4gKEpXVCk8L2E+IiwgSW50ZXJu ZXQtRHJhZnQgZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0xMywg Tm92ZW1iZXIgMjAxMy48L3RkPgo8L3RyPgo8dHI+Cjx0ZCBjbGFzcz0icmVm ZXJlbmNlIj48YiBpZD0iSS1ELmlldGYtb2F1dGgtdjItaHR0cC1tYWMiPltJ LUQuaWV0Zi1vYXV0aC12Mi1odHRwLW1hY108L2I+PC90ZD4KPHRkIGNsYXNz PSJ0b3AiPgo8YT5IYW1tZXItTGFoYXYsIEU8L2E+LCAiPGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi1o dHRwLW1hYy0wMSI+SFRUUCBBdXRoZW50aWNhdGlvbjogTUFDIEFjY2VzcyBB dXRoZW50aWNhdGlvbjwvYT4iLCBJbnRlcm5ldC1EcmFmdCBkcmFmdC1pZXRm LW9hdXRoLXYyLWh0dHAtbWFjLTAxLCBGZWJydWFyeSAyMDEyLjwvdGQ+Cjwv dHI+Cjx0cj4KPHRkIGNsYXNzPSJyZWZlcmVuY2UiPjxiIGlkPSJSRkM2ODE5 Ij5bUkZDNjgxOV08L2I+PC90ZD4KPHRkIGNsYXNzPSJ0b3AiPgo8YT5Mb2Rk ZXJzdGVkdCwgVC48L2E+LCA8YT5NY0dsb2luLCBNLjwvYT4gYW5kIDxhPlAu IEh1bnQ8L2E+LCAiPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNjgxOSI+T0F1dGggMi4wIFRocmVhdCBNb2RlbCBhbmQgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnM8L2E+IiwgUkZDIDY4MTksIEphbnVhcnkgMjAx My48L3RkPgo8L3RyPgo8L3Rib2R5PjwvdGFibGU+CjxoMSBpZD0icmZjLmFw cGVuZGl4LkFwcGVuZGl4IEEiPgo8YSBocmVmPSIjcmZjLmFwcGVuZGl4LkFw cGVuZGl4JTIwQSI+QXBwZW5kaXggQS48L2E+IEFja25vd2xlZ2VtZW50czwv aDE+CjxwIGlkPSJyZmMuc2VjdGlvbi5BcHBlbmRpeCBBLnAuMSI+VGhlIGF1 dGhvcnMgd291bGQgbGlrZSB0byB0aGFuayB0aGUgbWVtYmVycyBvZiB0aGUg S2l0dGVuIHdvcmtpbmcgZ3JvdXAsIGFuZCBpbiBhZGRpdGlvbiBhbmQgc3Bl Y2lmaWNhbGx5OiBTaW1vbiBKb3NlZnNvbiwgVG9yc3RlbiBMb2RkZXJzdGFk dCwgUnlhbiBUcm9sbCwgQWxleGV5IE1lbG5pa292LCBKZWZmcmV5IEh1dHpl bG1hbiwgTmljbyBXaWxsaWFtcywgYW5kIE1hdHQgTWlsbGVyLiAgPC9wPgo8 cCBpZD0icmZjLnNlY3Rpb24uQXBwZW5kaXggQS5wLjIiPlRoaXMgZG9jdW1l bnQgd2FzIHByb2R1Y2VkIHVuZGVyIHRoZSBjaGFpcm1hbnNoaXAgb2YgQWxl eGV5IE1lbG5pa292LCBUb20gWXUsIFNoYXduIEVtZXJ5LCBKb3NoIEhvd2xl dHQsIFNhbSBIYXJ0bWFuLiAgVGhlIHN1cGVydmlzaW5nIGFyZWEgZGlyZWN0 b3Igd2FzIFN0ZXBoZW4gRmFycmVsbC4gIDwvcD4KPGgxIGlkPSJyZmMuYXBw ZW5kaXguQXBwZW5kaXggQiI+CjxhIGhyZWY9IiNyZmMuYXBwZW5kaXguQXBw ZW5kaXglMjBCIj5BcHBlbmRpeCBCLjwvYT4gRG9jdW1lbnQgSGlzdG9yeTwv aDE+CjxwIGlkPSJyZmMuc2VjdGlvbi5BcHBlbmRpeCBCLnAuMSI+W1sgdG8g YmUgcmVtb3ZlZCBieSBSRkMgZWRpdG9yIGJlZm9yZSBwdWJsaWNhdGlvbiBh cyBhbiBSRkMgXV0gPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uQXBwZW5kaXgg Qi5wLjIiPi0xNSA8L3A+CjxwPjwvcD4KCjx1bD4KPGxpPkxhc3QgY2FsbCBm ZWVkYWNrIG9uIHRoZSBHUzIgc3R1ZmYgYmVpbmcgcmlwcGVkIG91dCBjb21w bGV0ZWx5Li4gIDwvbGk+CjxsaT5SZW1vdmVkIHRoZSAidXNlciIgcGFyYW1l dGVyIGFuZCBwdXQgc3R1ZmYgYmFjayBpbnRvIHRoZSBnczItaGVhZGVyLiAg Q2FsbCBvdXQgdGhhdCB0aGUgYXV0aHppZCBtdXN0IGdvIGluIHRoZSBnczIt aGVhZGVyLiBWZXJ5IGNvbXBhcmFibGUgdG8gLTEwLiAgPC9saT4KPGxpPkFk ZGVkIGFuIE9BdXRoIDEuMEEgZXhhbXBsZSBleHBsaWNpdGx5LiAgPC9saT4K PC91bD4KCjxwPiA8L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi5BcHBlbmRpeCBC LnAuNCI+LTE0IDwvcD4KPHA+PC9wPgoKPHVsPgo8bGk+TGFzdCBjYWxsIGZl ZWRhY2sgb24gUkZDIGNpdGF0aW9ucyBuZWVkZWQsIHNtYWxsIGVkaXRvcmlh bC4gIDwvbGk+CjxsaT5BZGRlZCB0aGUgInVzZXIiIHBhcmFtZXRlciBiYWNr LCB3aGljaCB3YXMgcHVsbGVkIHdoZW4gd2Ugc3RhcnRlZCBkb3duIHRoZSBH UzIgcGF0aC4gIFNhbWUgbGFuZ3VhZ2UgYXMgLTAzLiAgPC9saT4KPGxpPkRl ZmluZWQgYSBzdHViIEdTMiBoZWFkZXIgdG8gbWFrZSBzdXJlIHRoYXQgd2hl biB0aGUgR1MyIGJyaWRlIGlzIGRlZmluZWQgZm9yIHRoaXMgdGhhdCBub3Ro aW5nIHdpbGwgYnJlYWsgd2hlbiBpdCBhY3R1YWxseSBzdGFydHMgdG8gZ2V0 IHBvcHVsYXRlZC4gIDwvbGk+CjwvdWw+Cgo8cD4gPC9wPgo8cCBpZD0icmZj LnNlY3Rpb24uQXBwZW5kaXggQi5wLjYiPi0xMyA8L3A+CjxwPjwvcD4KCjx1 bD48bGk+Q2hhbmdlZCBhZmZpbGlhdGlvbi4gIDwvbGk+PC91bD4KCjxwPiA8 L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi5BcHBlbmRpeCBCLnAuOCI+LTEyIDwv cD4KPHA+PC9wPgoKPHVsPjxsaT5SZW1vdmVkIC1QTFVTIGNvbXBvbmVudHMg ZnJvbSB0aGUgc3BlY2lmaWNhdGlvbi4gIDwvbGk+PC91bD4KCjxwPiA8L3A+ CjxwIGlkPSJyZmMuc2VjdGlvbi5BcHBlbmRpeCBCLnAuMTAiPi0xMSA8L3A+ CjxwPjwvcD4KCjx1bD4KPGxpPlJlbW92ZWQgR1NTLUFQSSBjb21wb25lbnRz IGZyb20gdGhlIHNwZWNpZmljYXRpb24uICA8L2xpPgo8bGk+VXBkYXRlZCBz ZWN1cml0eSBjb25zaWRlcmF0aW9uIHNlY3Rpb24uICA8L2xpPgo8L3VsPgoK PHA+IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLkFwcGVuZGl4IEIucC4xMiI+ LTEwIDwvcD4KPHA+PC9wPgoKPHVsPjxsaT5DbGFyaWZpY2F0aW9ucyB0aHJv dWdob3V0IHRoZSBkb2N1bWVudCBpbiByZXNwb25zZSB0byB0aGUgZmVlZGJh Y2sgZnJvbSBKZWZmcmV5IEh1dHplbG1hbi4gIDwvbGk+PC91bD4KCjxwPiA8 L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi5BcHBlbmRpeCBCLnAuMTQiPi0wOSA8 L3A+CjxwPjwvcD4KCjx1bD4KPGxpPkluY29ycG9yYXRlZCByZXZpZXcgYnkg QWxleGV5IGFuZCBIYW5uZXMuICA8L2xpPgo8bGk+Q2xhcmlmaWVkIHRoZSB0 aHJlZSBPQXV0aCBTQVNMIG1lY2hhbmlzbXMuICA8L2xpPgo8bGk+VXBkYXRl ZCByZWZlcmVuY2VzPC9saT4KPGxpPkV4dGVuZGVkIGFja25vd2xlZGdlbWVu dHM8L2xpPgo8L3VsPgoKPHA+IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9uLkFw cGVuZGl4IEIucC4xNiI+LTA4IDwvcD4KPHA+PC9wPgoKPHVsPgo8bGk+Rml4 ZWQgdGhlIGNoYW5uZWwgYmluZGluZyBleGFtcGxlcyBmb3IgcD0kY2J0eXBl IDwvbGk+CjxsaT5Nb3JlIHR1bmluZyBvZiB0aGUgYXV0aGNpZCBsYW5ndWFn ZSBhbmQgZWRpdGVkIGFuZCByZW5hbWVkIDMuMi4xLiAgPC9saT4KPC91bD4K CjxwPiA8L3A+CjxwIGlkPSJyZmMuc2VjdGlvbi5BcHBlbmRpeCBCLnAuMTgi Pi0wNyA8L3A+CjxwPjwvcD4KCjx1bD4KPGxpPlN0cnVjayB0aGUgTVVTVCBs YW5naWFnZSBmcm9tIGF1dGh6aWQuICA8L2xpPgo8bGk+CjwvdWw+Cgo8cD4g PC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uQXBwZW5kaXggQi5wLjIwIj4tMDYg PC9wPgo8cD48L3A+Cgo8dWw+CjxsaT5SZW1vdmVkIHRoZSB1c2VyIGZpZWxk LiAgRml4ZWQgdGhlIGV4YW1wbGVzIGFnYWluLiAgPC9saT4KPGxpPkFkZGVk IGNhbm9uaWNhbGl6YXRpb24gbGFuZ3VhZ2UuICA8L2xpPgo8bGk+CjwvdWw+ Cgo8cD4gPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uQXBwZW5kaXggQi5wLjIy Ij4tMDUgPC9wPgo8cD48L3A+Cgo8dWw+CjxsaT5GaXhlZCB0aGUgR1MyIGhl YWRlciBsYW5ndWFnZSBhZ2Fpbi4gIDwvbGk+CjxsaT5TZXBhcmF0ZWQgb3V0 IGRpZmZlcmVudCBPQXV0aCBzY2hlbWVzIGludG8gZGlmZmVyZW50IFNBU0wg bWVjaGFuaXNtcy4gIFRvb2sgb3V0IHRoZSBzY2hlbWUgaW4gdGhlIGVycm9y IHJldHVybi4gIFR1bmVkIHVwIHRoZSBJQU5BIHJlZ2lzdHJhdGlvbnMuICA8 L2xpPgo8bGk+QWRkZWQgdGhlIHVzZXIgZmllbGQgYmFjayBpbnRvIHRoZSBT QVNMIG1lc3NhZ2UuICA8L2xpPgo8bGk+Rml4ZWQgdGhlIGV4YW1wbGVzIChh Z2FpbikuICA8L2xpPgo8bGk+CjwvdWw+Cgo8cD4gPC9wPgo8cCBpZD0icmZj LnNlY3Rpb24uQXBwZW5kaXggQi5wLjI0Ij4tMDQgPC9wPgo8cD48L3A+Cgo8 dWw+CjxsaT5DaGFuZ2VkIHVzZXIgZmllbGQgdG8gYmUgY2FycmllZCBpbiB0 aGUgZ3MyLWhlYWRlciwgYW5kIG1hZGUgZ3MyIGhlYWRlciBleHBsaWNpdCBp biBhbGwgY2FzZXMuICA8L2xpPgo8bGk+Q29udmVydGVkIE1BQyBleGFtcGxl cyB0byBPQXV0aCAxLjBhLiAgTW92ZWQgTUFDIHRvIGFuIGluZm9ybWF0aXZl IHJlZmVyZW5jZS4gIDwvbGk+CjxsaT5DaGFuZ2VkIHRvIHNlbmRpbmcgYW4g ZW1wdHkgY2xpZW50IHJlc3BvbnNlIChzaW5nbGUgY29udHJvbC1BKSBhcyB0 aGUgc2Vjb25kIG1lc3NhZ2Ugb2YgYSBmYWlsZWQgc2VxdWVuY2UuICA8L2xp Pgo8bGk+Rml4ZWQgY2hhbm5lbCBiaW5kaW5nIHByb3NlIHRvIHJlZmVyIHRv IHRoZSBub3JtYXRpdmUgc3BlY3MgYW5kIHJlbW92ZWQgdGhlIGhhc2hpbmcg b2YgbGFyZ2UgY2hhbm5lbCBiaW5kaW5nIGRhdGEsIHdoaWNoIGJyb3VnaHQg bXJvZSBwcm9ibGVtcyB0aGFuIGl0IHNvbHZlZC4gIDwvbGk+CjxsaT5BZGRl ZCBhIFNNVFAgZXhhbXBsZXMgZm9yIEJlYXJlciB1c2UgY2FzZS4gIDwvbGk+ CjwvdWw+Cgo8cD4gPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24uQXBwZW5kaXgg Qi5wLjI2Ij4tMDMgPC9wPgo8cD48L3A+Cgo8dWw+CjxsaT5BZGRlZCB1c2Vy IGZpZWxkIGludG8gZXhhbXBsZXMgYW5kIGZpeGVkIGVncmVnaW91cyBlcnJv cnMgdGhlcmUgYXMgd2VsbC4gIDwvbGk+CjxsaT5BZGRlZCB0ZXh0IHJlbWlu ZGluZyBkZXZlbG9wZXJzIHRoYXQgQXV0aG9yaXphdGlvbiBzY2hlbWUgbmFt ZXMgYXJlIGNhc2UgaW5zZW5zaXRpdmUuICA8L2xpPgo8L3VsPgoKPHA+IDwv cD4KPHAgaWQ9InJmYy5zZWN0aW9uLkFwcGVuZGl4IEIucC4yOCI+LTAyIDwv cD4KPHA+PC9wPgoKPHVsPgo8bGk+QWRkZWQgdGhlIHVzZXIgZGF0YSBlbGVt ZW50IGJhY2sgaW4uICA8L2xpPgo8bGk+TWlub3IgZWRpdG9yaWFsIGNoYW5n ZXMuICA8L2xpPgo8L3VsPgoKPHA+IDwvcD4KPHAgaWQ9InJmYy5zZWN0aW9u LkFwcGVuZGl4IEIucC4zMCI+LTAxIDwvcD4KPHA+PC9wPgoKPHVsPgo8bGk+ UmlwcGluZyBvdXQgZGlzY292ZXJ5LiAgQ2hhbmdlZCB0byByZWZlciB0byBJ LUQuam9uZXMtYXBwc2F3Zy13ZWJmaW5nZXIgaW5zdGVhZCBvZiBXRiBhbmQg U1dEIG9sZGVyIGRyYWZ0cy4gIDwvbGk+CjxsaT5SZXBsYWNpbmcgSFRUUCBh cyB0aGUgbWVzc2FnZSBmb3JtYXQgYW5kIGFkanVzdGVkIGFsbCBleGFtcGxl cy4gIDwvbGk+CjwvdWw+Cgo8cD4gPC9wPgo8cCBpZD0icmZjLnNlY3Rpb24u QXBwZW5kaXggQi5wLjMyIj4tMDAgPC9wPgo8cD48L3A+Cgo8dWw+CjxsaT5S ZW5hbWVkIGRyYWZ0IGludG8gcHJvcGVyIElFVEYgbmFtaW5nIGZvcm1hdCBu b3cgdGhhdCBpdCdzIGFkb3B0ZWQuICA8L2xpPgo8bGk+TWlub3IgZml4ZXMu ICA8L2xpPgo8L3VsPgoKPHA+IDwvcD4KPGgxIGlkPSJyZmMuYXV0aG9ycyI+ PGEgaHJlZj0iI3JmYy5hdXRob3JzIj5BdXRob3JzJyBBZGRyZXNzZXM8L2E+ PC9oMT4KPGRpdiBjbGFzcz0iYXZvaWRicmVhayI+CiAgPGFkZHJlc3MgY2xh c3M9InZjYXJkIj4KCTxzcGFuIGNsYXNzPSJ2Y2FyZGxpbmUiPgoJICA8c3Bh biBjbGFzcz0iZm4iPldpbGxpYW0gTWlsbHM8L3NwYW4+IAoJICA8c3BhbiBj bGFzcz0ibiBoaWRkZW4iPgoJCTxzcGFuIGNsYXNzPSJmYW1pbHktbmFtZSI+ TWlsbHM8L3NwYW4+CgkgIDwvc3Bhbj4KCTwvc3Bhbj4KCTxzcGFuIGNsYXNz PSJvcmcgdmNhcmRsaW5lIj5ZYWhvbyEgSW5jLjwvc3Bhbj4KCTxzcGFuIGNs YXNzPSJhZHIiPgoJICAKCSAgPHNwYW4gY2xhc3M9InZjYXJkbGluZSI+CgkJ PHNwYW4gY2xhc3M9ImxvY2FsaXR5Ij48L3NwYW4+IAoJCTxzcGFuIGNsYXNz PSJyZWdpb24iPjwvc3Bhbj4KCQk8c3BhbiBjbGFzcz0iY29kZSI+PC9zcGFu PgoJICA8L3NwYW4+CgkgIDxzcGFuIGNsYXNzPSJjb3VudHJ5LW5hbWUgdmNh cmRsaW5lIj48L3NwYW4+Cgk8L3NwYW4+Cgk8c3BhbiBjbGFzcz0idmNhcmRs aW5lIj5FTWFpbDogPGEgaHJlZj0ibWFpbHRvOndtaWxsc185MjEwNUB5YWhv by5jb20lMjAiPndtaWxsc185MjEwNUB5YWhvby5jb20gPC9hPjwvc3Bhbj4K CiAgPC9hZGRyZXNzPgo8L2Rpdj48ZGl2IGNsYXNzPSJhdm9pZGJyZWFrIj4K ICA8YWRkcmVzcyBjbGFzcz0idmNhcmQiPgoJPHNwYW4gY2xhc3M9InZjYXJk bGluZSI+CgkgIDxzcGFuIGNsYXNzPSJmbiI+VGltIFNob3dhbHRlcjwvc3Bh bj4gCgkgIDxzcGFuIGNsYXNzPSJuIGhpZGRlbiI+CgkJPHNwYW4gY2xhc3M9 ImZhbWlseS1uYW1lIj5TaG93YWx0ZXI8L3NwYW4+CgkgIDwvc3Bhbj4KCTwv c3Bhbj4KCTxzcGFuIGNsYXNzPSJvcmcgdmNhcmRsaW5lIj48L3NwYW4+Cgk8 c3BhbiBjbGFzcz0iYWRyIj4KCSAgCgkgIDxzcGFuIGNsYXNzPSJ2Y2FyZGxp bmUiPgoJCTxzcGFuIGNsYXNzPSJsb2NhbGl0eSI+PC9zcGFuPiAKCQk8c3Bh biBjbGFzcz0icmVnaW9uIj48L3NwYW4+CgkJPHNwYW4gY2xhc3M9ImNvZGUi Pjwvc3Bhbj4KCSAgPC9zcGFuPgoJICA8c3BhbiBjbGFzcz0iY291bnRyeS1u YW1lIHZjYXJkbGluZSI+PC9zcGFuPgoJPC9zcGFuPgoJPHNwYW4gY2xhc3M9 InZjYXJkbGluZSI+RU1haWw6IDxhIGhyZWY9Im1haWx0bzp0anNAcHNhdXgu Y29tIj50anNAcHNhdXguY29tPC9hPjwvc3Bhbj4KCiAgPC9hZGRyZXNzPgo8 L2Rpdj48ZGl2IGNsYXNzPSJhdm9pZGJyZWFrIj4KICA8YWRkcmVzcyBjbGFz cz0idmNhcmQiPgoJPHNwYW4gY2xhc3M9InZjYXJkbGluZSI+CgkgIDxzcGFu IGNsYXNzPSJmbiI+SGFubmVzIFRzY2hvZmVuaWcgPC9zcGFuPiAKCSAgPHNw YW4gY2xhc3M9Im4gaGlkZGVuIj4KCQk8c3BhbiBjbGFzcz0iZmFtaWx5LW5h bWUiPlRzY2hvZmVuaWc8L3NwYW4+CgkgIDwvc3Bhbj4KCTwvc3Bhbj4KCTxz cGFuIGNsYXNzPSJvcmcgdmNhcmRsaW5lIj5BUk0gTHRkLjwvc3Bhbj4KCTxz cGFuIGNsYXNzPSJhZHIiPgoJICA8c3Bhbj4xMTAgRnVsYm91cm4gUmQ8L3Nw YW4+CgoJICA8c3BhbiBjbGFzcz0idmNhcmRsaW5lIj4KCQk8c3BhbiBjbGFz cz0ibG9jYWxpdHkiPkNhbWJyaWRnZTwvc3Bhbj4sICAKCQk8c3BhbiBjbGFz cz0icmVnaW9uIj48L3NwYW4+CgkJPHNwYW4gY2xhc3M9ImNvZGUiPkNCMSA5 TkogPC9zcGFuPgoJICA8L3NwYW4+CgkgIDxzcGFuIGNsYXNzPSJjb3VudHJ5 LW5hbWUgdmNhcmRsaW5lIj5HcmVhdCBCcml0YWluPC9zcGFuPgoJPC9zcGFu PgoJPHNwYW4gY2xhc3M9InZjYXJkbGluZSI+RU1haWw6IDxhIGhyZWY9Im1h aWx0bzpIYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0JTIwIj5IYW5uZXMudHNj aG9mZW5pZ0BnbXgubmV0IDwvYT48L3NwYW4+Cgo8c3BhbiBjbGFzcz0idmNh cmRsaW5lIj5VUkk6IDxhIGhyZWY9Imh0dHA6Ly93d3cudHNjaG9mZW5pZy5w cml2LmF0Ij5odHRwOi8vd3d3LnRzY2hvZmVuaWcucHJpdi5hdDwvYT48L3Nw YW4+CgogIDwvYWRkcmVzcz4KPC9kaXY+Cgo8L2JvZHk+CjwvaHRtbD4= --469468616-147888852-1394650561=:77489 Content-Type: text/plain; name="draft-ietf-kitten-sasl-oauth-15-raw.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-kitten-sasl-oauth-15-raw.txt" DQ0KDQ0KDQ0KS0lUVEVOICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFcuIE1pbGxzDQ0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFlhaG9vISBJbmMuDQ0KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gU2hv d2FsdGVyDQ0KRXhwaXJlczogU2VwdGVtYmVyIDExLCAyMDE0ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSC5ULiBUc2Nob2ZlbmlnDQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEFSTSBMdGQuDQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDEy LCAyMDE0DQ0KDQ0KICAgICAgICAgICAgICAgICAgIEEgc2V0IG9mIFNBU0wg TWVjaGFuaXNtcyBmb3IgT0F1dGgNDQogICAgICAgICAgICAgICAgICBkcmFm dC1pZXRmLWtpdHRlbi1zYXNsLW9hdXRoLTE1LnR4dA0NCg0NCkFic3RyYWN0 DQ0KDQ0KICAgT0F1dGggZW5hYmxlcyBhIHRoaXJkLXBhcnR5IGFwcGxpY2F0 aW9uIHRvIG9idGFpbiBsaW1pdGVkIGFjY2VzcyB0byBhDQ0KICAgcHJvdGVj dGVkIHJlc291cmNlLCBlaXRoZXIgb24gYmVoYWxmIG9mIGEgcmVzb3VyY2Ug b3duZXIgYnkNDQogICBvcmNoZXN0cmF0aW5nIGFuIGFwcHJvdmFsIGludGVy YWN0aW9uLCBvciBieSBhbGxvd2luZyB0aGUgdGhpcmQtcGFydHkNDQogICBh cHBsaWNhdGlvbiB0byBvYnRhaW4gYWNjZXNzIG9uIGl0cyBvd24gYmVoYWxm Lg0NCg0NCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBob3cgYW4gYXBwbGlj YXRpb24gY2xpZW50IHVzZXMgY3JlZGVudGlhbHMNDQogICBvYnRhaW5lZCB2 aWEgT0F1dGggb3ZlciB0aGUgU2ltcGxlIEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cml0eSBMYXllcg0NCiAgIChTQVNMKSB0byBhY2Nlc3MgYSBwcm90ZWN0 ZWQgcmVzb3VyY2UgYXQgYSByZXNvdXJjZSBzZXJ2ZS4gIFRoZXJlYnksDQ0K ICAgaXQgZW5hYmxlcyBzY2hlbWVzIGRlZmluZWQgd2l0aGluIHRoZSBPQXV0 aCBmcmFtZXdvcmsgZm9yIG5vbi1IVFRQLQ0NCiAgIGJhc2VkIGFwcGxpY2F0 aW9uIHByb3RvY29scy4NDQoNDQogICBDbGllbnRzIHR5cGljYWxseSBzdG9y ZSB0aGUgdXNlcidzIGxvbmctdGVybSBjcmVkZW50aWFsLiAgVGhpcyBkb2Vz LA0NCiAgIGhvd2V2ZXIsIGxlYWQgdG8gc2lnbmlmaWNhbnQgc2VjdXJpdHkg dnVsbmVyYWJpbGl0aWVzLCBmb3IgZXhhbXBsZSwNDQogICB3aGVuIHN1Y2gg YSBjcmVkZW50aWFsIGxlYWtzLiAgQSBzaWduaWZpY2FudCBiZW5lZml0IG9m IE9BdXRoIGZvcg0NCiAgIHVzYWdlIGluIHRob3NlIGNsaWVudHMgaXMgdGhh dCB0aGUgcGFzc3dvcmQgaXMgcmVwbGFjZWQgYnkgYSBzaGFyZWQNDQogICBz ZWNyZXQgd2l0aCBoaWdoZXIgZW50cm9weSwgaS5lLiwgdGhlIHRva2VuLiAg VG9rZW5zIHR5cGljYWxseQ0NCiAgIHByb3ZpZGUgbGltaXRlZCBhY2Nlc3Mg cmlnaHRzIGFuZCBjYW4gYmUgbWFuYWdlZCBhbmQgcmV2b2tlZA0NCiAgIHNl cGFyYXRlbHkgZnJvbSB0aGUgdXNlcidzIGxvbmctdGVybSBwYXNzd29yZC4N DQoNDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQ0KDQ0KICAgVGhpcyBJbnRlcm5l dC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRo IHRoZQ0NCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuDQ0K DQ0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBv ZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNDQogICBUYXNrIEZvcmNlIChJ RVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZQ0NCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0 cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtDQ0KICAgRHJhZnRz IGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3Vy cmVudC8uDQ0KDQ0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1 bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQ0KICAg YW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5 IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNDQogICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5j ZQ0NCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFz ICJ3b3JrIGluIHByb2dyZXNzLiINDQoNDQogICBUaGlzIEludGVybmV0LURy YWZ0IHdpbGwgZXhwaXJlIG9uIFNlcHRlbWJlciAxMSwgMjAxNC4NDQoNDQpD b3B5cmlnaHQgTm90aWNlDQ0KDQ0KICAgQ29weXJpZ2h0IChjKSAyMDE0IElF VEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQ0K ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQ0K DQ0KICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQg dGhlIElFVEYgVHJ1c3QncyBMZWdhbA0NCiAgIFByb3Zpc2lvbnMgUmVsYXRp bmcgdG8gSUVURiBEb2N1bWVudHMgKGh0dHA6Ly90cnVzdGVlLmlldGYub3Jn Lw0NCiAgIGxpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9m IHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuDQ0KICAgUGxlYXNlIHJl dmlldyB0aGVzZSBkb2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2Ny aWJlIHlvdXIgcmlnaHRzDQ0KICAgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJl c3BlY3QgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cw0NCiAg IGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdCBpbmNsdWRlIFNp bXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dA0NCiAgIGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDQuZSBvZiB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBh bmQgYXJlDQ0KICAgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcyBkZXNj cmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQ0KDQ0KVGFi bGUgb2YgQ29udGVudHMNDQoNDQogICAxLiAgSW50cm9kdWN0aW9uDQ0KICAg Mi4gIFRlcm1pbm9sb2d5DQ0KICAgMy4gIE9BdXRoIFNBU0wgTWVjaGFuaXNt IFNwZWNpZmljYXRpb25zDQ0KICAgICAzLjEuICBJbml0aWFsIENsaWVudCBS ZXNwb25zZQ0NCiAgICAgICAzLjEuMS4gIFJlc2VydmVkIEtleS9WYWx1ZXMN DQogICAgIDMuMi4gIFNlcnZlcidzIFJlc3BvbnNlDQ0KICAgICAgIDMuMi4x LiAgT0F1dGggSWRlbnRpZmllcnMgaW4gdGhlIFNBU0wgQ29udGV4dA0NCiAg ICAgICAzLjIuMi4gIFNlcnZlciBSZXNwb25zZSB0byBGYWlsZWQgQXV0aGVu dGljYXRpb24NDQogICAgICAgMy4yLjMuICBDb21wbGV0aW5nIGFuIEVycm9y IE1lc3NhZ2UgU2VxdWVuY2UNDQogICAgIDMuMy4gIE9BdXRoIEFjY2VzcyBU b2tlbiBUeXBlcyB1c2luZyBLZXllZCBNZXNzYWdlIERpZ2VzdHMNDQogICA0 LiAgRXhhbXBsZXMNDQogICAgIDQuMS4gIFN1Y2Nlc3NmdWwgQmVhcmVyIFRv a2VuIEV4Y2hhbmdlDQ0KICAgICA0LjIuICBTdWNjZXNzZnVsIE9BdXRoIDEu MGEgVG9rZW4gRXhjaGFuZ2UNDQogICAgIDQuMy4gIEZhaWxlZCBFeGNoYW5n ZQ0NCiAgICAgNC40LiAgU01UUCBFeGFtcGxlIG9mIGEgRmFpbGVkIE5lZ290 aWF0aW9uDQ0KICAgNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQ0KICAg Ni4gIEludGVybmF0aW9uYWxpemF0aW9uIENvbnNpZGVyYXRpb25zDQ0KICAg Ny4gIElBTkEgQ29uc2lkZXJhdGlvbnMNDQogICAgIDcuMS4gIFNBU0wgUmVn aXN0cmF0aW9uDQ0KICAgOC4gIFJlZmVyZW5jZXMNDQogICAgIDguMS4gIE5v cm1hdGl2ZSBSZWZlcmVuY2VzDQ0KICAgICA4LjIuICBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzDQ0KICAgQXBwZW5kaXggQS4gQWNrbm93bGVnZW1lbnRzDQ0K ICAgQXBwZW5kaXggQi4gRG9jdW1lbnQgSGlzdG9yeQ0NCiAgIEF1dGhvcnMn IEFkZHJlc3Nlcw0NCg0NCg0NCg0NCg0NCktJVFRFTiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBX LiBNaWxscw0NCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBZYWhvbyEgSW5jLg0NCkludGVu ZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFQuIFNob3dhbHRlcg0NCkV4cGlyZXM6IFNlcHRlbWJlciAx MSwgMjAxNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEguVC4gVHNj aG9mZW5pZw0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBUk0gTHRkLg0NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBNYXJjaCAxMiwgMjAxNA0NCg0NCiAgICAgICAgICAgICAgICAg ICBBIHNldCBvZiBTQVNMIE1lY2hhbmlzbXMgZm9yIE9BdXRoDQ0KICAgICAg ICAgICAgICAgICAgZHJhZnQtaWV0Zi1raXR0ZW4tc2FzbC1vYXV0aC0xNS50 eHQNDQoNDQpBYnN0cmFjdA0NCg0NCiAgIE9BdXRoIGVuYWJsZXMgYSB0aGly ZC1wYXJ0eSBhcHBsaWNhdGlvbiB0byBvYnRhaW4gbGltaXRlZCBhY2Nlc3Mg dG8gYQ0NCiAgIHByb3RlY3RlZCByZXNvdXJjZSwgZWl0aGVyIG9uIGJlaGFs ZiBvZiBhIHJlc291cmNlIG93bmVyIGJ5DQ0KICAgb3JjaGVzdHJhdGluZyBh biBhcHByb3ZhbCBpbnRlcmFjdGlvbiwgb3IgYnkgYWxsb3dpbmcgdGhlIHRo aXJkLXBhcnR5DQ0KICAgYXBwbGljYXRpb24gdG8gb2J0YWluIGFjY2VzcyBv biBpdHMgb3duIGJlaGFsZi4NDQoNDQogICBUaGlzIGRvY3VtZW50IGRlZmlu ZXMgaG93IGFuIGFwcGxpY2F0aW9uIGNsaWVudCB1c2VzIGNyZWRlbnRpYWxz DQ0KICAgb2J0YWluZWQgdmlhIE9BdXRoIG92ZXIgdGhlIFNpbXBsZSBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJpdHkgTGF5ZXINDQogICAoU0FTTCkgdG8g YWNjZXNzIGEgcHJvdGVjdGVkIHJlc291cmNlIGF0IGEgcmVzb3VyY2Ugc2Vy dmUuICBUaGVyZWJ5LA0NCiAgIGl0IGVuYWJsZXMgc2NoZW1lcyBkZWZpbmVk IHdpdGhpbiB0aGUgT0F1dGggZnJhbWV3b3JrIGZvciBub24tSFRUUC0NDQog ICBiYXNlZCBhcHBsaWNhdGlvbiBwcm90b2NvbHMuDQ0KDQ0KICAgQ2xpZW50 cyB0eXBpY2FsbHkgc3RvcmUgdGhlIHVzZXIncyBsb25nLXRlcm0gY3JlZGVu dGlhbC4gIFRoaXMgZG9lcywNDQogICBob3dldmVyLCBsZWFkIHRvIHNpZ25p ZmljYW50IHNlY3VyaXR5IHZ1bG5lcmFiaWxpdGllcywgZm9yIGV4YW1wbGUs DQ0KICAgd2hlbiBzdWNoIGEgY3JlZGVudGlhbCBsZWFrcy4gIEEgc2lnbmlm aWNhbnQgYmVuZWZpdCBvZiBPQXV0aCBmb3INDQogICB1c2FnZSBpbiB0aG9z ZSBjbGllbnRzIGlzIHRoYXQgdGhlIHBhc3N3b3JkIGlzIHJlcGxhY2VkIGJ5 IGEgc2hhcmVkDQ0KICAgc2VjcmV0IHdpdGggaGlnaGVyIGVudHJvcHksIGku ZS4sIHRoZSB0b2tlbi4gIFRva2VucyB0eXBpY2FsbHkNDQogICBwcm92aWRl IGxpbWl0ZWQgYWNjZXNzIHJpZ2h0cyBhbmQgY2FuIGJlIG1hbmFnZWQgYW5k IHJldm9rZWQNDQogICBzZXBhcmF0ZWx5IGZyb20gdGhlIHVzZXIncyBsb25n LXRlcm0gcGFzc3dvcmQuDQ0KDQ0KU3RhdHVzIG9mIHRoaXMgTWVtbw0NCg0N CiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwg Y29uZm9ybWFuY2Ugd2l0aCB0aGUNDQogICBwcm92aXNpb25zIG9mIEJDUCA3 OCBhbmQgQkNQIDc5Lg0NCg0NCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29y a2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQ0K ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBz IG1heSBhbHNvIGRpc3RyaWJ1dGUNDQogICB3b3JraW5nIGRvY3VtZW50cyBh cyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVy bmV0LQ0NCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLg0NCg0NCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Yg c2l4IG1vbnRocw0NCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQs IG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQ0KICAg dGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURy YWZ0cyBhcyByZWZlcmVuY2UNDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRo ZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQ0KDQ0KICAg VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBTZXB0ZW1iZXIg MTEsIDIwMTQuDQ0KDQ0KQ29weXJpZ2h0IE5vdGljZQ0NCg0NCiAgIENvcHly aWdodCAoYykgMjAxNCBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVu dGlmaWVkIGFzIHRoZQ0NCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmln aHRzIHJlc2VydmVkLg0NCg0NCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVj dCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwNDQogICBQ cm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzIChodHRwOi8v dHJ1c3RlZS5pZXRmLm9yZy8NDQogICBsaWNlbnNlLWluZm8pIGluIGVmZmVj dCBvbiB0aGUgZGF0ZSBvZiBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50 Lg0NCiAgIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzIGNhcmVmdWxs eSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cw0NCiAgIGFuZCByZXN0 cmljdGlvbnMgd2l0aCByZXNwZWN0IHRvIHRoaXMgZG9jdW1lbnQuICBDb2Rl IENvbXBvbmVudHMNDQogICBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50 IG11c3QgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQNDQog ICBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YgdGhlIFRydXN0IExl Z2FsIFByb3Zpc2lvbnMgYW5kIGFyZQ0NCiAgIHByb3ZpZGVkIHdpdGhvdXQg d2FycmFudHkgYXMgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBM aWNlbnNlLg0NCg0NCjEuICBJbnRyb2R1Y3Rpb24NDQoNDQogICBPQXV0aCAx LjBhIFtSRkM1ODQ5XSBhbmQgT0F1dGggMi4wIFtSRkM2NzQ5XSBhcmUgcHJv dG9jb2wgZnJhbWV3b3Jrcw0NCiAgIHRoYXQgZW5hYmxlIGEgdGhpcmQtcGFy dHkgYXBwbGljYXRpb24gdG8gb2J0YWluIGxpbWl0ZWQgYWNjZXNzIHRvIGEN DQogICBwcm90ZWN0ZWQgcmVzb3VyY2UsIGVpdGhlciBvbiBiZWhhbGYgb2Yg YSByZXNvdXJjZSBvd25lciBieQ0NCiAgIG9yY2hlc3RyYXRpbmcgYW4gYXBw cm92YWwgaW50ZXJhY3Rpb24sIG9yIGJ5IGFsbG93aW5nIHRoZSB0aGlyZC1w YXJ0eQ0NCiAgIGFwcGxpY2F0aW9uIHRvIG9idGFpbiBhY2Nlc3Mgb24gaXRz IG93biBiZWhhbGYuDQ0KDQ0KICAgVGhlIGNvcmUgT0F1dGggMi4wIHNwZWNp ZmljYXRpb24gW1JGQzY3NDldIHNwZWNpZmllcyB0aGUgaW50ZXJhY3Rpb24N DQogICBiZXR3ZWVuIHRoZSBPQXV0aCBjbGllbnQgYW5kIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlcjsgaXQgZG9lcyBub3QNDQogICBkZWZpbmUgdGhlIGlu dGVyYWN0aW9uIGJldHdlZW4gdGhlIE9BdXRoIGNsaWVudCBhbmQgdGhlIHJl c291cmNlDQ0KICAgc2VydmVyIGZvciB0aGUgYWNjZXNzIHRvIGEgcHJvdGVj dGVkIHJlc291cmNlIHVzaW5nIGFuIEFjY2VzcyBUb2tlbi4NDQogICBJbnN0 ZWFkLCB0aGUgT0F1dGggY2xpZW50IHRvIHJlc291cmNlIHNlcnZlciBpbnRl cmFjdGlvbiBpcyBkZXNjcmliZWQNDQogICBpbiBzZXBhcmF0ZSBzcGVjaWZp Y2F0aW9ucywgc3VjaCBhcyB0aGUgYmVhcmVyIHRva2VuIHNwZWNpZmljYXRp b24NDQogICBbUkZDNjc1MF0gYW5kIHRoZSBNQUMgVG9rZW4gc3BlY2lmaWNh dGlvbiBbSS1ELmlldGYtb2F1dGgtdjItaHR0cC0NDQogICBtYWNdLiAgT0F1 dGggMS4wYSBpbmNsdWRlZCB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBm b3IgdGhlDQ0KICAgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBPQXV0aCBj bGllbnQgYW5kIHRoZSByZXNvdXJjZSBzZXJ2ZXIgaW4NDQogICBbUkZDNTg0 OV0uDQ0KDQ0KICAgVGhlIG1haW4gdXNlIGNhc2VzIGZvciBPQXV0aCAyLjAg YW5kIE9BdXRoIDEuMGEgaGF2ZSBzbyBmYXIgZm9jdXNlZA0NCiAgIG9uIGFu IEhUVFAtYmFzZWQgW1JGQzI2MTZdIGVudmlyb25tZW50IG9ubHkuICBUaGlz IGRvY3VtZW50DQ0KICAgaW50ZWdyYXRlcyBPQXV0aCAxLjBhIGFuZCBPQXV0 aCAyLjAgaW50byBub24tSFRUUC1iYXNlZCBhcHBsaWNhdGlvbnMNDQogICB1 c2luZyB0aGUgaW50ZWdyYXRpb24gaW50byBTQVNMLiAgSGVuY2UsIHRoaXMg ZG9jdW1lbnQgIHRha2VzDQ0KICAgYWR2YW50YWdlIG9mIHRoZSBPQXV0aCBw cm90b2NvbCBhbmQgaXRzIGRlcGxveW1lbnQgYmFzZSB0byBwcm92aWRlIGEN DQogICB3YXkgdG8gdXNlIHRoZSBTaW1wbGUgQXV0aGVudGljYXRpb24gYW5k IFNlY3VyaXR5IExheWVyIChTQVNMKQ0NCiAgIFtSRkM0NDIyXSB0byBnYWlu IGFjY2VzcyB0byByZXNvdXJjZXMgd2hlbiB1c2luZyBub24tSFRUUC1iYXNl ZA0NCiAgIHByb3RvY29scywgc3VjaCBhcyB0aGUgSW50ZXJuZXQgTWVzc2Fn ZSBBY2Nlc3MgUHJvdG9jb2wgKElNQVApDQ0KICAgW1JGQzM1MDFdIGFuZCB0 aGUgU2ltcGxlIE1haWwgVHJhbnNmZXIgUHJvdG9jb2wgKFNNVFApIFtSRkM1 MzIxXSwNDQogICB3aGljaCBpcyB3aGF0IHRoaXMgbWVtbyB1c2VzIGluIHRo ZSBleGFtcGxlcy4NDQoNDQogICBUbyBpbGx1c3RyYXRlIHRoZSBpbXBhY3Qg b2YgaW50ZWdyYXRpbmcgdGhpcyBzcGVjaWZpY2F0aW9uIGludG8gYW4NDQog ICBPQXV0aC1lbmFibGVkIGFwcGxpY2F0aW9uIGVudmlyb25tZW50IEZpZ3Vy ZSAxIHNob3dzIHRoZSBhYnN0cmFjdA0NCiAgIG1lc3NhZ2UgZmxvdyBvZiBP QXV0aCAyLjAgW1JGQzY3NDldLiAgQXMgaW5kaWNhdGVkIGluIHRoZSBmaWd1 cmUsDQ0KICAgdGhpcyBkb2N1bWVudCBpbXBhY3RzIHRoZSBleGNoYW5nZSBv ZiBtZXNzYWdlcyAoRSkgYW5kIChGKSBzaW5jZSBTQVNMDQ0KICAgaXMgdXNl ZCBmb3IgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUg cmVzb3VyY2Ugc2VydmVyDQ0KICAgaW5zdGVhZCBvZiBIVFRQLg0NCg0NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0tLSsNDQogICArLS0tLS0tLS0rICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rICB8 DQ0KICAgfCAgICAgICAgfC0tKEEpLS0gQXV0aG9yaXphdGlvbiBSZXF1ZXN0 IC0tLT58ICAgUmVzb3VyY2UgICAgfCAgfA0NCiAgIHwgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgT3duZXIgICAg IHwgIHxQbGFpbg0NCiAgIHwgICAgICAgIHw8LShCKS0tLS0tLSBBY2Nlc3Mg R3JhbnQgLS0tLS0tLS0tfCAgICAgICAgICAgICAgIHwgIHxPQXV0aA0NCiAg IHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLSsgIHwyLjANDQogICB8ICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQ0KICAgfCAgICAgICAgfCAgICAgICAgIENsaWVudCBDcmVkZW50aWFs cyAmICAgICArLS0tLS0tLS0tLS0tLS0tKyAgfA0NCiAgIHwgICAgICAgIHwt LShDKS0tLS0tLSBBY2Nlc3MgR3JhbnQgLS0tLS0tLS0+fCBBdXRob3JpemF0 aW9uIHwgIHwNDQogICB8IENsaWVudCB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgIFNlcnZlciAgICB8ICB8DQ0KICAgfCAgICAg ICAgfDwtKEQpLS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tLS18ICAgICAg ICAgICAgICAgfCAgfA0NCiAgIHwgICAgICAgIHwgICAgICAody8gT3B0aW9u YWwgUmVmcmVzaCBUb2tlbikgKy0tLS0tLS0tLS0tLS0tLSsgIHwNDQogICB8 ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tLS0rDQ0KICAgfCAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tKw0N CiAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLSsgIHwNDQogICB8ICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8 ICB8T0F1dGgNDQogICB8ICAgICAgICB8LS0oRSktLS0tLS0gQWNjZXNzIFRv a2VuIC0tLS0tLS0tPnwgICAgUmVzb3VyY2UgICB8ICB8b3Zlcg0NCiAgIHwg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgU2VydmVyICAgIHwgIHxTQVNMDQ0KICAgfCAgICAgICAgfDwtKEYpLS0t LSBQcm90ZWN0ZWQgUmVzb3VyY2UgLS0tLS18ICAgICAgICAgICAgICAgfCAg fA0NCiAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgIHwgIHwNDQogICArLS0tLS0tLS0rICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0rICB8DQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tKw0NCg0NCiAgIFRoZSBT aW1wbGUgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyaXR5IExheWVyIChTQVNM KSBpcyBhIGZyYW1ld29yaw0NCiAgIGZvciBwcm92aWRpbmcgYXV0aGVudGlj YXRpb24gYW5kIGRhdGEgc2VjdXJpdHkgc2VydmljZXMgaW4NDQogICBjb25u ZWN0aW9uLW9yaWVudGVkIHByb3RvY29scyB2aWEgcmVwbGFjZWFibGUgYXV0 aGVudGljYXRpb24NDQogICBtZWNoYW5pc21zLiAgSXQgcHJvdmlkZXMgYSBz dHJ1Y3R1cmVkIGludGVyZmFjZSBiZXR3ZWVuIHByb3RvY29scyBhbmQNDQog ICBtZWNoYW5pc21zLiAgVGhlIHJlc3VsdGluZyBmcmFtZXdvcmsgYWxsb3dz IG5ldyBwcm90b2NvbHMgdG8gcmV1c2UNDQogICBleGlzdGluZyBhdXRoZW50 aWNhdGlvbiBwcm90b2NvbHMgYW5kIGFsbG93cyBvbGQgcHJvdG9jb2xzIHRv IG1ha2UNDQogICB1c2Ugb2YgbmV3IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlz bXMuICBUaGUgZnJhbWV3b3JrIGFsc28gcHJvdmlkZXMgYQ0NCiAgIHByb3Rv Y29sIGZvciBzZWN1cmluZyBzdWJzZXF1ZW50IHByb3RvY29sIGV4Y2hhbmdl cyB3aXRoaW4gYSBkYXRhDQ0KICAgc2VjdXJpdHkgbGF5ZXIuDQ0KDQ0KICAg V2hlbiBPQXV0aCBpcyBpbnRlZ3JhdGVkIGludG8gU0FTTCB0aGUgaGlnaC1s ZXZlbCBzdGVwcyBhcmUgYXMNDQogICBmb2xsb3dzOg0NCg0NCiAgICAgIChB KSAgVGhlIGNsaWVudCByZXF1ZXN0cyBhdXRob3JpemF0aW9uIGZyb20gdGhl IHJlc291cmNlIG93bmVyLg0NCiAgICAgIFRoZSBhdXRob3JpemF0aW9uIHJl cXVlc3QgY2FuIGJlIG1hZGUgZGlyZWN0bHkgdG8gdGhlIHJlc291cmNlDQ0K ICAgICAgb3duZXIgKGFzIHNob3duKSwgb3IgcHJlZmVyYWJseSBpbmRpcmVj dGx5IHZpYSB0aGUgYXV0aG9yaXphdGlvbg0NCiAgICAgIHNlcnZlciBhcyBh biBpbnRlcm1lZGlhcnkuDQ0KDQ0KICAgICAgKEIpICBUaGUgY2xpZW50IHJl Y2VpdmVzIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgd2hpY2ggaXMgYQ0NCiAg ICAgIGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZSBvd25l cidzIGF1dGhvcml6YXRpb24sDQ0KICAgICAgZXhwcmVzc2VkIHVzaW5nIG9u ZSBvZiBvdXIgZ3JhbnQgdHlwZXMgZGVmaW5lZCBpbiB0aGlzDQ0KICAgICAg c3BlY2lmaWNhdGlvbiBvciB1c2luZyBhbiBleHRlbnNpb24gZ3JhbnQgdHlw ZS4gIFRoZSBhdXRob3JpemF0aW9uDQ0KICAgICAgZ3JhbnQgdHlwZSBkZXBl bmRzIG9uIHRoZSBtZXRob2QgdXNlZCBieSB0aGUgY2xpZW50IHRvIHJlcXVl c3QNDQogICAgICBhdXRob3JpemF0aW9uIGFuZCB0aGUgdHlwZXMgc3VwcG9y dGVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4NDQoNDQogICAgICAo QykgIFRoZSBjbGllbnQgcmVxdWVzdHMgYW4gYWNjZXNzIHRva2VuIGJ5IGF1 dGhlbnRpY2F0aW5nIHdpdGgNDQogICAgICB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgYW5kIHByZXNlbnRpbmcgdGhlIGF1dGhvcml6YXRpb24gZ3JhbnQu DQ0KDQ0KICAgICAgKEQpICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0 aGVudGljYXRlcyB0aGUgY2xpZW50IGFuZA0NCiAgICAgIHZhbGlkYXRlcyB0 aGUgYXV0aG9yaXphdGlvbiBncmFudCwgYW5kIGlmIHZhbGlkIGlzc3VlcyBh biBhY2Nlc3MNDQogICAgICB0b2tlbi4NDQoNDQogICAgICAoRSkgIFRoZSBj bGllbnQgcmVxdWVzdHMgdGhlIHByb3RlY3RlZCByZXNvdXJjZSBmcm9tIHRo ZSByZXNvdXJjZQ0NCiAgICAgIHNlcnZlciBhbmQgYXV0aGVudGljYXRlcyBi eSBwcmVzZW50aW5nIHRoZSBhY2Nlc3MgdG9rZW4uDQ0KDQ0KICAgICAgKEYp ICBUaGUgcmVzb3VyY2Ugc2VydmVyIHZhbGlkYXRlcyB0aGUgYWNjZXNzIHRv a2VuLCBhbmQgaWYgdmFsaWQsDQ0KICAgICAgaW5kaWNhdGVzIGEgc3VjY2Vz c2Z1bCBhdXRoZW50aWNhdGlvbi4NDQoNDQogICBBZ2Fpbiwgc3RlcHMgKEUp IGFuZCAoRikgYXJlIG5vdCBkZWZpbmVkIGluIFtSRkM2NzQ5XSAoYnV0IGFy ZQ0NCiAgIGRlc2NyaWJlZCBpbiwgZm9yIGV4YW1wbGUsIFtSRkM2NzUwXSBm b3IgdGhlIE9BdXRoIEJlYXJlciBUb2tlbg0NCiAgIGluc3RlYWQpIGFuZCBh cmUgdGhlIG1haW4gZnVuY3Rpb25hbGl0eSBzcGVjaWZpZWQgd2l0aGluIHRo aXMNDQogICBkb2N1bWVudC4gIENvbnNlcXVlbnRseSwgdGhlIG1lc3NhZ2Ug ZXhjaGFuZ2Ugc2hvd24gaW4gRmlndXJlIDEgaXMNDQogICB0aGUgcmVzdWx0 IG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gIFRoZSBjbGllbnQgd2lsbCBnZW5l cmFsbHkgbmVlZCB0bw0NCiAgIGRldGVybWluZSB0aGUgYXV0aGVudGljYXRp b24gZW5kcG9pbnRzIChhbmQgcGVyaGFwcyB0aGUgc2VydmljZQ0NCiAgIGVu ZHBvaW50cykgYmVmb3JlIHRoZSBPQXV0aCAyLjAgcHJvdG9jb2wgZXhjaGFu Z2UgbWVzc2FnZXMgaW4gc3RlcHMNDQogICAoQSktKEQpIGFyZSBleGVjdXRl ZC4gIFRoZSBkaXNjb3Zlcnkgb2YgdGhlIHJlc291cmNlIG93bmVyIGFuZA0N CiAgIGF1dGhvcml6YXRpb24gc2VydmVyIGVuZHBvaW50cyBpcyBvdXRzaWRl IHRoZSBzY29wZSBvZiB0aGlzDQ0KICAgc3BlY2lmaWNhdGlvbi4gIFRoZSBj bGllbnQgbXVzdCBkaXNjb3ZlciB0aG9zZSBlbmRwb2ludHMgdXNpbmcgYQ0N CiAgIGRpc2NvdmVyeSBtZWNoYW5pc21zLCBzdWNoIGFzIFdlYmZpbmdlciB1 c2luZyBob3N0LW1ldGEgW1JGQzcwMzNdLg0NCiAgIEluIGJhbmQgZGlzY292 ZXJ5IGlzIG5vdCB0ZW5hYmxlIGlmIGNsaWVudHMgc3VwcG9ydCB0aGUgT0F1 dGggMi4wDQ0KICAgcGFzc3dvcmQgZ3JhbnQuICBPbmNlIGNyZWRlbnRpYWxz IGFyZSBvYnRhaW5lZCB0aGUgY2xpZW50IHByb2NlZWRzIHRvDQ0KICAgc3Rl cHMgKEUpIGFuZCAoRikgZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24u DQ0KDQ0KICAgT0F1dGggMS4wIGZvbGxvd3MgYSBzaW1pbGFyIG1vZGVsIGJ1 dCB1c2VzIGEgZGlmZmVyZW50IHRlcm1pbm9sb2d5DQ0KICAgYW5kIGRvZXMg bm90IHNlcGFyYXRlIHRoZSByZXNvdXJjZSBzZXJ2ZXIgZnJvbSB0aGUgYXV0 aG9yaXphdGlvbg0NCiAgIHNlcnZlci4NDQoNDQoyLiAgVGVybWlub2xvZ3kN DQoNDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJF UVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQ0KICAgIlNIT1VMRCIs ICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BU SU9OQUwiIGluIHRoaXMNDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJw cmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4NDQoNDQogICBUaGUg cmVhZGVyIGlzIGFzc3VtZWQgdG8gYmUgZmFtaWxpYXIgd2l0aCB0aGUgdGVy bXMgdXNlZCBpbiB0aGUgT0F1dGgNDQogICAyLjAgc3BlY2lmaWNhdGlvbiBb UkZDNjc0OV0gYW5kIFNBU0wgW1JGQzQ0MjJdLg0NCg0NCiAgIEluIGV4YW1w bGVzLCAiQzoiIGFuZCAiUzoiIGluZGljYXRlIGxpbmVzIHNlbnQgYnkgdGhl IGNsaWVudCBhbmQNDQogICBzZXJ2ZXIgcmVzcGVjdGl2ZWx5LiAgTGluZSBi cmVha3MgaGF2ZSBiZWVuIGluc2VydGVkIGZvciByZWFkYWJpbGl0eS4NDQoN DQogICBOb3RlIHRoYXQgdGhlIElNQVAgU0FTTCBzcGVjaWZpY2F0aW9uIHJl cXVpcmVzIGJhc2U2NCBlbmNvZGluZywgc2VlDQ0KICAgU2VjdGlvbiA0IG9m IFtSRkM0NjQ4XSwgbm90IHRoaXMgbWVtby4NDQoNDQozLiAgT0F1dGggU0FT TCBNZWNoYW5pc20gU3BlY2lmaWNhdGlvbnMNDQoNDQogICBTQVNMIGlzIHVz ZWQgYXMgYW4gYXV0aGVudGljYXRpb24gZnJhbWV3b3JrIGluIGEgdmFyaWV0 eSBvZg0NCiAgIGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29scy4gIFRoaXMg ZG9jdW1lbnQgZGVmaW5lcyB0aGUgZm9sbG93aW5nDQ0KICAgU0FTTCBtZWNo YW5pc21zIGZvciB1c2FnZSB3aXRoIE9BdXRoOg0NCg0NCiAgICAgIA0NCg0N CiAgICAgIE9BVVRIQkVBUkVSOiBPQXV0aCAyLjAgYmVhcmVyIHRva2Vucywg YXMgZGVzY3JpYmVkIGluIFtSRkM2NzUwXS4NDQogICAgICAgICBSRkMgNjc1 MCB1c2VzIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSB0byBzZWN1 cmUgdGhlDQ0KICAgICAgICAgcHJvdG9jb2wgaW50ZXJhY3Rpb24gYmV0d2Vl biB0aGUgY2xpZW50IGFuZCB0aGUgcmVzb3VyY2UNDQogICAgICAgICBzZXJ2 ZXIuDQ0KDQ0KICAgICAgT0FVVEgxMEE6IE9BdXRoIDEuMGEgTUFDIHRva2Vu cyAodXNpbmcgdGhlIEhNQUMtU0hBMSBrZXllZCBtZXNzYWdlDQ0KICAgICAg ICAgZGlnZXN0KSwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40LjIgb2Yg W1JGQzU4NDldLg0NCg0NCiAgIE5ldyBleHRlbnNpb25zIG1heSBiZSBkZWZp bmVkIHRvIGFkZCBhZGRpdGlvbmFsIE9BdXRoIEFjY2VzcyBUb2tlbg0NCiAg IFR5cGVzLiAgU3VjaCBhIG5ldyBTQVNMIE9BdXRoIG1lY2hhbmlzbSBjYW4g YmUgYWRkZWQgYnkgc2ltcGx5DQ0KICAgcmVnaXN0ZXJpbmcgdGhlIG5ldyBu YW1lKHMpIGFuZCBjaXRpbmcgdGhpcyBzcGVjaWZpY2F0aW9uIGZvciB0aGUN DQogICBmdXJ0aGVyIGRlZmluaXRpb24uDQ0KDQ0KICAgVGhlc2UgbWVjaGFu aXNtcyBhcmUgY2xpZW50IGluaXRpYXRlZCBhbmQgbG9jay1zdGVwLCB0aGUg c2VydmVyDQ0KICAgYWx3YXlzIHJlcGx5aW5nIHRvIGEgY2xpZW50IG1lc3Nh Z2UuICBJbiB0aGUgY2FzZSB3aGVyZSB0aGUgY2xpZW50DQ0KICAgaGFzIGFu ZCBjb3JyZWN0bHkgdXNlcyBhIHZhbGlkIHRva2VuIHRoZSBmbG93IGlzOg0N Cg0NCiAgIDEuICBDbGllbnQgc2VuZHMgYSB2YWxpZCBhbmQgY29ycmVjdCBp bml0aWFsIGNsaWVudCByZXNwb25zZS4NDQoNDQogICAyLiAgU2VydmVyIHJl c3BvbmRzIHdpdGggYSBzdWNjZXNzZnVsIGF1dGhlbnRpY2F0aW9uLg0NCg0N CiAgIEluIHRoZSBjYXNlIHdoZXJlIGF1dGhvcml6YXRpb24gZmFpbHMgdGhl IHNlcnZlciBzZW5kcyBhbiBlcnJvcg0NCiAgIHJlc3VsdCwgdGhlbiBjbGll bnQgTVVTVCB0aGVuIHNlbmQgYW4gYWRkaXRpb25hbCBtZXNzYWdlIHRvIHRo ZQ0NCiAgIHNlcnZlciBpbiBvcmRlciB0byBhbGxvdyB0aGUgc2VydmVyIHRv IGZpbmlzaCB0aGUgZXhjaGFuZ2UuICBTb21lDQ0KICAgcHJvdG9jb2xzIGFu ZCBjb21tb24gU0FTTCBpbXBsZW1lbnRhdGlvbnMgZG8gbm90IHN1cHBvcnQg Ym90aCBzZW5kaW5nDQ0KICAgYSBTQVNMIG1lc3NhZ2UgYW5kIGZpbmFsaXpp bmcgYSBTQVNMIG5lZ290aWF0aW9uLCB0aGUgYWRkaXRpb25hbA0NCiAgIGNs aWVudCBtZXNzYWdlIGluIHRoZSBlcnJvciBjYXNlIGRlYWxzIHdpdGggdGhp cyBwcm9ibGVtLiAgVGhpcw0NCiAgIGV4Y2hhbmdlIGlzOg0NCg0NCiAgIDEu ICBDbGllbnQgc2VuZHMgYW4gaW52YWxpZCBpbml0aWFsIGNsaWVudCByZXNw b25zZS4NDQoNDQogICAyLiAgU2VydmVyIHJlc3BvbmRzIHdpdGggYW4gZXJy b3IgbWVzc2FnZS4NDQoNDQogICAzLiAgQ2xpZW50IHNlbmRzIGEgZHVtbXkg Y2xpZW50IHJlc3BvbnNlLg0NCg0NCiAgIDQuICBTZXJ2ZXIgZmFpbHMgdGhl IGF1dGhlbnRpY2F0aW9uLg0NCg0NCjMuMS4gIEluaXRpYWwgQ2xpZW50IFJl c3BvbnNlDQ0KDQ0KICAgQ2xpZW50IHJlc3BvbnNlcyBhcmUgYSBHUzIgW1JG QzU4MDFdIGhlYWRlciBmb2xsb3dlZCBieSBhIGtleS92YWx1ZQ0NCiAgIHBh aXIgc2VxdWVuY2UsIG9yIG1heSBiZSBlbXB0eS4gIFRoZSBnczItaGVhZGVy IGlzIGRlZmluZWQgaGVyZSBmb3INDQogICBjb21wYXRpYmlsaXR5IHdpdGgg R1MyIGlmIGEgR1MyIG1lY2hhbmlzbSBpcyBmb3JtYWxseSBkZWZpbmVkLCBi dXQNDQogICB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGRlZmluZSBvbmUuICBU aGVzZSBrZXkvdmFsdWUgcGFpcnMgY2FycnkgdGhlDQ0KICAgZXF1aXZhbGVu dCB2YWx1ZXMgZnJvbSBhbiBIVFRQIGNvbnRleHQgaW4gb3JkZXIgdG8gYmUg YWJsZSB0bw0NCiAgIGNvbXBsZXRlIGFuIE9BdXRoIHN0eWxlIEhUVFAgYXV0 aG9yaXphdGlvbi4gIFVua25vd24ga2V5L3ZhbHVlIHBhaXJzDQ0KICAgTVVT VCBiZSBpZ25vcmVkIGJ5IHRoZSBzZXJ2ZXIuICBUaGUgQUJORiBbUkZDNTIz NF0gc3ludGF4IGlzOg0NCg0NCiAgIA0NCiAgICAga3ZzZXAgICAgICAgICAg PSAleDAxDQ0KICAgICBrZXkgICAgICAgICAgICA9IDEqKEFMUEhBIC8gIiwi KQ0NCiAgICAgdmFsdWUgICAgICAgICAgPSAqKFZDSEFSIC8gU1AgLyBIVEFC IC8gQ1IgLyBMRiApDQ0KICAgICBrdnBhaXIgICAgICAgICA9IGtleSAiPSIg dmFsdWUga3ZzZXANDQogICA7O2dzMi1oZWFkZXIgICAgID0gU2VlIFJGQyA1 ODAxDQ0KICAgICBjbGllbnRfcmVzcCAgICA9IChnczItaGVhZGVyIGt2c2Vw IDAqa3ZwYWlyIGt2c2VwKSAvIGt2c2VwDQ0KDQ0KICAgVGhlIEdTMiBoZWFk ZXIgTVVTVCBpbmNsZGUgdGhlIHVzZXIgbmFtZSBhc29jaWF0ZWQgd2l0aCB0 aGUgcmVzb3VyY2UNDQogICBiZWluZyBhY2Nlc3NlZCwgdGhlICJhdXRoemlk Ii4NDQoNDQogICBUaGUgZm9sbG93aW5nIGtleS92YWx1ZSBwYWlycyBhcmUg ZGVmaW5lZCBpbiB0aGUgY2xpZW50IHJlc3BvbnNlOg0NCg0NCiAgICAgIA0N Cg0NCiAgICAgIGF1dGggKFJFUVVJUkVEKTogVGhlIHBheWxvYWQgb2YgdGhl IEhUVFAgQXV0aG9yaXphdGlvbiBoZWFkZXIgZm9yDQ0KICAgICAgICAgYW4g ZXF1aXZhbGVudCBIVFRQIE9BdXRoIGF1dGhvcml6YXRpb24uDQ0KDQ0KICAg ICAgaG9zdDogQ29udGFpbnMgdGhlIGhvc3QgbmFtZSB0byB3aGljaCB0aGUg Y2xpZW50IGNvbm5lY3RlZC4NDQoNDQogICAgICBwb3J0OiBDb250YWlucyB0 aGUgcG9ydCBudW1iZXIgcmVwcmVzZW50ZWQgYXMgYSBkZWNpbWFsIHBvc2l0 aXZlDQ0KICAgICAgICAgaW50ZWdlciBzdHJpbmcgd2l0aG91dCBsZWFkaW5n IHplcm9zIHRvIHdoaWNoIHRoZSBjbGllbnQNDQogICAgICAgICBjb25uZWN0 ZWQuDQ0KDQ0KICAgICAgcXM6IFRoZSBIVFRQIHF1ZXJ5IHN0cmluZy4gIFRo aXMgaXMgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UsIHRoZQ0NCiAgICAgICAg IGNsaWVudCBTSE9VRCBOT1Qgc2VuZCBpdCwgYW5kIGhhcyB0aGUgZGVmYXVs dCB2YWx1ZSBvZiAiIi4NDQoNDQogICBGb3IgT0F1dGggdG9rZW4gdHlwZXMg dGhhdCB1c2Uga2V5ZWQgbWVzc2FnZSBkaWdlc3RzIHRoZSBjbGllbnQgTVVT VA0NCiAgIHNlbmQgaG9zdCBhbmQgcG9ydCBudW1iZXIga2V5L3ZhbHVlcywg YW5kIHRoZSBzZXJ2ZXIgTVVTVCBmYWlsIGFuDQ0KICAgYXV0aG9yaXphdGlv biByZXF1ZXN0IHJlcXVpcmluZyBrZXllZCBtZXNzYWdlIGRpZ2VzdHMgdGhh dCBkbyBub3QNDQogICBoYXZlIGhvc3QgYW5kIHBvcnQgdmFsdWVzLiAgIElu IE9BdXRoIDEuMGEgZm9yIGV4YW1wbGUsIHRoZSBzby1jYWxsZWQNDQogICAi c2lnbmF0dXJlIGJhc2Ugc3RyaW5nIGNhbGN1bGF0aW9uIiBpbmNsdWRlcyB0 aGUgcmVjb25zdHJ1Y3RlZCBIVFRQDQ0KICAgVVJMLg0NCg0NCjMuMS4xLiAg UmVzZXJ2ZWQgS2V5L1ZhbHVlcw0NCg0NCiAgIEluIHRoZXNlIG1lY2hhbmlz bXMgdmFsdWVzIGZvciBwYXRoLCBxdWVyeSBzdHJpbmcgYW5kIHBvc3QgYm9k eSBhcmUNDQogICBhc3NpZ25lZCBkZWZhdWx0IHZhbHVlcy4gIE9BdXRoIGF1 dGhvcml6YXRpb24gc2NoZW1lcyBNQVkgZGVmaW5lDQ0KICAgdXNhZ2Ugb2Yg dGhlc2UgaW4gdGhlIFNBU0wgY29udGV4dCBhbmQgZXh0ZW5kIHRoaXMgc3Bl Y2lmaWNhdGlvbi4NDQogICBGb3IgT0F1dGggQWNjZXNzIFRva2VuIFR5cGVz IHRoYXQgdXNlIHJlcXVlc3Qga2V5ZWQgbWVzc2FnZSBkaWdlc3QNDQogICB0 aGUgZGVmYXVsdCB2YWx1ZXMgTVVTVCBiZSB1c2VkIHVubGVzcyBleHBsaWNp dCB2YWx1ZXMgYXJlIHByb3ZpZGVkDQ0KICAgaW4gdGhlIGNsaWVudCByZXNw b25zZS4gIFRoZSBmb2xsb3dpbmcga2V5IHZhbHVlcyBhcmUgcmVzZXJ2ZWQg Zm9yDQ0KICAgZnV0dXJlIHVzZToNDQoNDQogICAgICANDQoNDQogICAgICBt dGhkIChSRVNFUlZFRCk6IEhUVFAgbWV0aG9kLCB0aGUgZGVmYXVsdCB2YWx1 ZSBpcyAiUE9TVCIuDQ0KDQ0KICAgICAgcGF0aCAoUkVTRVJWRUQpOiBIVFRQ IHBhdGggZGF0YSwgdGhlIGRlZmF1bHQgdmFsdWUgaXMgIi8iLg0NCg0NCiAg ICAgIHBvc3QgKFJFU0VSVkVEKTogSFRUUCBwb3N0IGRhdGEsIHRoZSBkZWZh dWx0IHZhbHVlIGlzICIiLg0NCg0NCjMuMi4gIFNlcnZlcidzIFJlc3BvbnNl DQ0KDQ0KICAgVGhlIHNlcnZlciB2YWxpZGF0ZXMgdGhlIHJlc3BvbnNlIHBl ciB0aGUgc3BlY2lmaWNhdGlvbiBmb3IgdGhlIE9BdXRoDQ0KICAgQWNjZXNz IFRva2VuIFR5cGVzIHVzZWQuICBJZiB0aGUgT0F1dGggQWNjZXNzIFRva2Vu IFR5cGUgdXRpbGl6ZXMgYQ0NCiAgIGtleWVkIG1lc3NhZ2UgZGlnZXN0IG9m IHRoZSByZXF1ZXN0IHBhcmFtZXRlcnMgdGhlbiB0aGUgY2xpZW50IG11c3QN DQogICBwcm92aWRlIGEgY2xpZW50IHJlc3BvbnNlIHRoYXQgc2F0aXNmaWVz IHRoZSBkYXRhIHJlcXVpcmVtZW50cyBmb3INDQogICB0aGUgc2NoZW1lIGlu IHVzZS4NDQoNDQogICBUaGUgc2VydmVyIHJlc3BvbmRzIHRvIGEgc3VjY2Vz c2Z1bGx5IHZlcmlmaWVkIGNsaWVudCBtZXNzYWdlIGJ5DQ0KICAgY29tcGxl dGluZyB0aGUgU0FTTCBuZWdvdGlhdGlvbi4gIFRoZSBhdXRoZW50aWNhdGVk IGlkZW50aXR5IHJlcG9ydGVkDQ0KICAgYnkgdGhlIFNBU0wgbWVjaGFuaXNt IGlzIHRoZSBpZGVudGl0eSBzZWN1cmVseSBlc3RhYmxpc2hlZCBmb3IgdGhl DQ0KICAgY2xpZW50IHdpdGggdGhlIE9BdXRoIGNyZWRlbnRpYWwuICBUaGUg YXBwbGljYXRpb24sIG5vdCB0aGUgU0FTTA0NCiAgIG1lY2hhbmlzbSwgYmFz ZWQgb24gbG9jYWwgYWNjZXNzIHBvbGljeSBkZXRlcm1pbmVzIHdoZXRoZXIg dGhlDQ0KICAgaWRlbnRpdHkgcmVwb3J0ZWQgYnkgdGhlIG1lY2hhbmlzbSBp cyBhbGxvd2VkIGFjY2VzcyB0byB0aGUgcmVxdWVzdGVkDQ0KICAgcmVzb3Vy Y2UuICBOb3RlIHRoYXQgdGhlIHNlbWFudGljcyBvZiB0aGUgYXV0aHotaWQg aXMgc3BlY2lmaWVkIGJ5DQ0KICAgdGhlIFNBU0wgZnJhbWV3b3JrIFtSRkM0 NDIyXS4NDQoNDQozLjIuMS4gIE9BdXRoIElkZW50aWZpZXJzIGluIHRoZSBT QVNMIENvbnRleHQNDQoNDQogICBJbiB0aGUgT0F1dGggZnJhbWV3b3JrIHRo ZSBjbGllbnQgbWF5IGJlIGF1dGhlbnRpY2F0ZWQgYnkgdGhlDQ0KICAgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHRoZSByZXNvdXJjZSBvd25lciBpcyBh dXRoZW50aWNhdGVkIHRvIHRoZQ0NCiAgIGF1dGhvcml6YXRpb24gc2VydmVy LiAgT0F1dGggYWNjZXNzIHRva2VucyBtYXkgY29udGFpbiBpbmZvcm1hdGlv bg0NCiAgIGFib3V0IHRoZSBhdXRoZW50aWNhdGlvbiBvZiB0aGUgcmVzb3Vy Y2Ugb3duZXIgYW5kIGFib3V0IHRoZSBjbGllbnQNDQogICBhbmQgbWF5IHRo ZXJlZm9yZSBtYWtlIHRoaXMgaW5mb3JtYXRpb24gYWNjZXNzaWJsZSB0byB0 aGUgcmVzb3VyY2UNDQogICBzZXJ2ZXIuDQ0KDQ0KICAgSWYgYm90aCBpZGVu dGlmaWVycyBhcmUgbmVlZGVkIGJ5IGFuIGFwcGxpY2F0aW9uIHRoZSBkZXZl bG9wZXIgd2lsbA0NCiAgIG5lZWQgdG8gcHJvdmlkZSBhIHdheSB0byBjb21t dW5pY2F0ZSB0aGF0IGZyb20gdGhlIFNBU0wgbWVjaGFuaXNtDQ0KICAgYmFj ayB0byB0aGUgYXBwbGljYXRpb24uDQ0KDQ0KMy4yLjIuICBTZXJ2ZXIgUmVz cG9uc2UgdG8gRmFpbGVkIEF1dGhlbnRpY2F0aW9uDQ0KDQ0KICAgRm9yIGEg ZmFpbGVkIGF1dGhlbnRpY2F0aW9uIHRoZSBzZXJ2ZXIgcmV0dXJucyBhIEpT T04gW1JGQzQ2MjddDQ0KICAgZm9ybWF0dGVkIGVycm9yIHJlc3VsdCwgYW5k IGZhaWxzIHRoZSBhdXRoZW50aWNhdGlvbi4gIFRoZSBlcnJvcg0NCiAgIHJl c3VsdCBjb25zaXN0cyBvZiB0aGUgZm9sbG93aW5nIHZhbHVlczoNDQoNDQog ICAgICANDQoNDQogICAgICBzdGF0dXMgKFJFUVVJUkVEKTogVGhlIGF1dGhv cml6YXRpb24gZXJyb3IgY29kZS4gIFZhbGlkIGVycm9yDQ0KICAgICAgICAg Y29kZXMgYXJlIGRlZmluZWQgaW4gdGhlIElBTkEgIk9BdXRoIEV4dGVuc2lv bnMgRXJyb3IgUmVnaXN0cnkiDQ0KICAgICAgICAgc3BlY2lmaWVkIGluIHRo ZSBPQXV0aCAyIGNvcmUgc3BlY2lmaWNhdGlvbi4NDQoNDQogICAgICBzY29w ZSAoT1BUSU9OQUwpOiBBbiBPQXV0aCBzY29wZSB3aGljaCBpcyB2YWxpZCB0 byBhY2Nlc3MgdGhlDQ0KICAgICAgICAgc2VydmljZS4gIFRoaXMgbWF5IGJl IGVtcHR5IHdoaWNoIGltcGxpZXMgdGhhdCB1bnNjb3BlZCB0b2tlbnMNDQog ICAgICAgICBhcmUgcmVxdWlyZWQsIG9yIGEgc2NvcGUgdmFsdWUuICBJZiBh IHNjb3BlIGlzIHNwZWNpZmllZCB0aGVuIGENDQogICAgICAgICBzaW5nbGUg c2NvcGUgaXMgcHJlZmVycmVkLCB1c2Ugb2YgYSBzcGFjZSBzZXBhcmF0ZWQg bGlzdCBvZg0NCiAgICAgICAgIHNjb3BlcyBpcyBOT1QgUkVDT01NRU5ERUQu DQ0KDQ0KICAgSWYgdGhlIHJlc291cmNlIHNlcnZlciBwcm92aWRlcyBhIHNj b3BlIHRoZW4gdGhlIGNsaWVudCBNVVNUIGFsd2F5cw0NCiAgIHJlcXVlc3Qg c2NvcGVkIHRva2VucyBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludC4gIElmIHRo ZSByZXNvdXJjZQ0NCiAgIHNlcnZlciBwcm92aWRlcyBubyBzY29wZSB0byB0 aGUgY2xpZW50IHRoZW4gdGhlIGNsaWVudCBTSE9VTEQgcHJlc3VtZQ0NCiAg IGFuIGVtcHR5IHNjb3BlICh1bnNjb3BlZCB0b2tlbikgaXMgbmVlZGVkLg0N Cg0NCjMuMi4zLiAgQ29tcGxldGluZyBhbiBFcnJvciBNZXNzYWdlIFNlcXVl bmNlDQ0KDQ0KICAgU2VjdGlvbiAzLjYgb2YgW1JGQzQ0MjJdIGV4cGxpY2l0 bHkgcHJvaGliaXRzIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24NDQogICBpbiBh biB1bnN1Y2Nlc3NmdWwgYXV0aGVudGljYXRpb24gb3V0Y29tZS4gIFRoZXJl Zm9yZSwgdGhlIGVycm9yDQ0KICAgbWVzc2FnZSBpcyBzZW50IGluIGEgbm9y bWFsIG1lc3NhZ2UuICBUaGUgY2xpZW50IE1VU1QgdGhlbiBzZW5kIGFuDQ0K ICAgYWRkaXRpb25hbCBjbGllbnQgcmVzcG9uc2UgY29uc2lzdGluZyBvZiBh IHNpbmdsZSAleDAxIChjb250cm9sIEEpDQ0KICAgY2hhcmFjdGVyIHRvIHRo ZSBzZXJ2ZXIgaW4gb3JkZXIgdG8gYWxsb3cgdGhlIHNlcnZlciB0byBmaW5p c2ggdGhlDQ0KICAgZXhjaGFuZ2UuDQ0KDQ0KMy4zLiAgT0F1dGggQWNjZXNz IFRva2VuIFR5cGVzIHVzaW5nIEtleWVkIE1lc3NhZ2UgRGlnZXN0cw0NCg0N CiAgIE9BdXRoIEFjY2VzcyBUb2tlbiBUeXBlcyBtYXkgdXNlIGtleWVkIG1l c3NhZ2UgZGlnZXN0cyBhbmQgdGhlIGNsaWVudA0NCiAgIGFuZCB0aGUgcmVz b3VyY2Ugc2VydmVyIG1heSBuZWVkIHRvIHBlcmZvcm0gYSBjcnlwdG9ncmFw aGljDQ0KICAgY29tcHV0YXRpb24gZm9yIGludGVncml0eSBwcm90ZWN0aW9u IGFuZCBkYXRhIG9yaWdpbiBhdXRoZW50aWNhdGlvbi4NDQoNDQogICBPQXV0 aCBpcyBkZXNpZ25lZCBmb3IgYWNjZXNzIHRvIHJlc291cmNlcyBpZGVudGlm aWVkIGJ5IFVSSXMuICBTQVNMDQ0KICAgaXMgZGVzaWduZWQgZm9yIHVzZXIg YXV0aGVudGljYXRpb24sIGFuZCBoYXMgbm8gZmFjaWxpdHkgZm9yIG1vcmUN DQogICBmaW5lLWdyYWluZWQgYWNjZXNzIGNvbnRyb2wuICBJbiB0aGlzIHNw ZWNpZmljYXRpb24gd2UgcmVxdWlyZSBvcg0NCiAgIGRlZmluZSBkZWZhdWx0 IHZhbHVlcyBmb3IgdGhlIGRhdGEgZWxlbWVudHMgZnJvbSBhbiBIVFRQIHJl cXVlc3QNDQogICB3aGljaCBhbGxvdyB0aGUgc2lnbmF0dXJlIGJhc2Ugc3Ry aW5nIHRvIGJlIGNvbnN0cnVjdGVkIHByb3Blcmx5Lg0NCiAgIFRoZSBkZWZh dWx0IEhUVFAgcGF0aCBpcyAiLyIgYW5kIHRoZSBkZWZhdWx0IHBvc3QgYm9k eSBpcyBlbXB0eS4NDQogICBUaGVzZSBhdG9tcyBhcmUgZGVmaW5lZCBhcyBl eHRlbnNpb24gcG9pbnRzIHNvIHRoYXQgbm8gY2hhbmdlcyBhcmUNDQogICBu ZWVkZWQgaWYgdGhlcmUgaXMgYSByZXZpc2lvbiBvZiBTQVNMIHdoaWNoIHN1 cHBvcnRzIG1vcmUgc3BlY2lmaWMNDQogICByZXNvdXJjZSBhdXRob3JpemF0 aW9uLCBlLmcuLCBJTUFQIGFjY2VzcyB0byBhIHNwZWNpZmljIGZvbGRlciBv ciBGVFANDQogICBhY2Nlc3MgbGltaXRlZCB0byBhIHNwZWNpZmljIGRpcmVj dG9yeS4NDQoNDQogICBVc2luZyB0aGUgZXhhbXBsZSBpbiB0aGUgT0F1dGgg MS4wYSBzcGVjaWZpY2F0aW9uIGFzIGEgc3RhcnRpbmcNDQogICBwb2ludCwg b24gYW4gSU1BUCBzZXJ2ZXIgcnVubmluZyBvbiBwb3J0IDE0MyBhbmQgZ2l2 ZW4gdGhlIE9BdXRoIDEuMGENDQogICBzdHlsZSBhdXRob3JpemF0aW9uIHJl cXVlc3QgKHdpdGggJXgwMSBzaG93biBhcyBeQSBhbmQgbGluZSBicmVha3MN DQogICBhZGRlZCBmb3IgcmVhZGFiaWxpdHkpIGJlbG93Og0NCg0NCiAgIG4s YT11c2VyQGV4YW1wbGUuY29tLF5BDQ0KICAgaG9zdD1leGFtcGxlLmNvbV5B DQ0KICAgcG9ydD0xNDNeQQ0NCiAgIGF1dGg9T0F1dGggcmVhbG09IkV4YW1w bGUiLA0NCiAgICAgICAgICAgICAgb2F1dGhfY29uc3VtZXJfa2V5PSI5ZGpk ajgyaDQ4ZGpzOWQyIiwNDQogICAgICAgICAgICAgIG9hdXRoX3Rva2VuPSJr a2s5ZDdkaDNrMzlzanY3IiwNDQogICAgICAgICAgICAgIG9hdXRoX3NpZ25h dHVyZV9tZXRob2Q9IkhNQUMtU0hBMSIsDQ0KICAgICAgICAgICAgICBvYXV0 aF90aW1lc3RhbXA9IjEzNzEzMTIwMSIsDQ0KICAgICAgICAgICAgICBvYXV0 aF9ub25jZT0iN2Q4ZjNlNGEiLA0NCiAgICAgICAgICAgICAgb2F1dGhfc2ln bmF0dXJlPSJUbTkwSUdFZ2NtVmhiQ0J6YVdkdVlYUjFjbVUlM0QiXkFeQQ0N Cg0NCiAgIFRoZSBzaWduYXR1cmUgYmFzZSBzdHJpbmcgd291bGQgYmUgY29u c3RydWN0ZWQgcGVyIHRoZSBPQXV0aCAxLjANDQogICBzcGVjaWZpY2F0aW9u IFtSRkM1ODQ5XSB3aXRoIHRoZSBmb2xsb3dpbmcgdGhpbmdzIG5vdGVkOg0N Cg0NCiAgIG8gIFRoZSBtZXRob2QgdmFsdWUgaXMgZGVmYXVsdGVkIHRvIFBP U1QuDQ0KDQ0KICAgbyAgVGhlIHNjaGVtZSBkZWZhdWx0cyB0byBiZSAiaHR0 cCIsIGFuZCBhbnkgcG9ydCBudW1iZXIgb3RoZXIgdGhhbg0NCiAgICAgIDgw IGlzIGluY2x1ZGVkLg0NCg0NCiAgIG8gIFRoZSBwYXRoIGRlZmF1bHRzIHRv ICIvIi4NDQoNDQogICBvICBUaGUgcXVlcnkgc3RyaW5nIGRlZmF1bHRzIHRv ICIiLg0NCg0NCiAgIEluIHRoaXMgZXhhbXBsZSB0aGUgc2lnbmF0dXJlIGJh c2Ugc3RyaW5nIHdpdGggbGluZSBicmVha3MgYWRkZWQgZm9yDQ0KICAgcmVh ZGFiaWxpdHkgd291bGQgYmU6DQ0KDQ0KICAgUE9TVCZodHRwJTNBJTJGJTJG ZXhhbXBsZS5jb206MTQzJTJGJm9hdXRoX2NvbnN1bWVyX2tleSUzRDlkamRq ODJoNA0NCiAgIDhkanM5ZDIlMjZvYXV0aF9ub25jZSUzRDdkOGYzZTRhJTI2 b2F1dGhfc2lnbmF0dXJlX21ldGhvZCUzREhNQUMtU0gNDQogICBBMSUyNm9h dXRoX3RpbWVzdGFtcCUzRDEzNzEzMTIwMSUyNm9hdXRoX3Rva2VuJTNEa2tr OWQ3ZGgzazM5c2p2Nw0NCg0NCjQuICBFeGFtcGxlcw0NCg0NCiAgIFRoZXNl IGV4YW1wbGVzIGlsbHVzdHJhdGUgZXhjaGFuZ2VzIGJldHdlZW4gYW4gSU1B UCBhbmQgU01UUCBjbGllbnRzDQ0KICAgYW5kIHNlcnZlcnMuDQ0KDQ0KICAg Tm90ZSB0byBpbXBsZW1lbnRlcnM6ICBUaGUgU0FTTCBPQXV0aCBtZXRob2Qg bmFtZXMgYXJlIGNhc2UNDQogICBpbnNlbnNpdGl2ZS4gIE9uZSBleGFtcGxl IHVzZXMgIkJlYXJlciIgYnV0IHRoYXQgY291bGQgYXMgZWFzaWx5IGJlDQ0K ICAgImJlYXJlciIsICJCRUFSRVIiLCBvciAiQmVBckVyIi4NDQoNDQo0LjEu ICBTdWNjZXNzZnVsIEJlYXJlciBUb2tlbiBFeGNoYW5nZQ0NCg0NCiAgIFRo aXMgZXhhbXBsZSBzaG93cyBhIHN1Y2Nlc3NmdWwgT0F1dGggMi4wIGJlYXJl ciB0b2tlbiBleGNoYW5nZS4NDQogICBOb3RlIHRoYXQgbGluZSBicmVha3Mg YXJlIGluc2VydGVkIGZvciByZWFkYWJpbGl0eSBhbmQgdGhlIHVuZGVybHlp bmcNDQogICBUTFMgZXN0YWJsaXNobWVudCBpcyBub3Qgc2hvd24gZWl0aGVy Lg0NCg0NCiAgIFM6ICogT0sgSU1BUDRyZXYxIFNlcnZlciBSZWFkeQ0NCiAg IEM6IHQwIENBUEFCSUxJVFkNDQogICBTOiAqIENBUEFCSUxJVFkgSU1BUDRy ZXYxIEFVVEg9T0FVVEhCRUFSRVIgU0FTTC1JUg0NCiAgIFM6IHQwIE9LIENv bXBsZXRlZA0NCiAgIEM6IHQxIEFVVEhFTlRJQ0FURSBPQVVUSEJFQVJFUiBi aXhoUFhWelpYSkFaWGhoYlhCc1pTNWpiMjBzQVdodmMzUTljMg0NCiAgICAg ICAgIFZ5ZG1WeUxtVjRZVzF3YkdVdVkyOXRBWEJ2Y25ROU1UUXpBV0YxZEdn OVFtVmhjbVZ5SUhaR09XUm1kRFJ4Yg0NCiAgICAgICAgIFZSak1rNTJZak5T YkdOclFtaGlTRkpvWkcxc2VtUkhSWFZaTWpsMFEyYzlQUUVCDQ0KICAgUzog dDEgT0sgU0FTTCBhdXRoZW50aWNhdGlvbiBzdWNjZWVkZWQNDQoNDQogICBB cyByZXF1aXJlZCBieSBJTUFQIFtSRkMzNTAxXSwgdGhlIHBheWxvYWRzIGFy ZSBiYXNlNjQtZW5jb2RlZC4gIFRoZQ0NCiAgIGRlY29kZWQgaW5pdGlhbCBj bGllbnQgcmVzcG9uc2UgKHdpdGggJXgwMSByZXByZXNlbnRlZCBhcyBeQSBh bmQgbG9uZw0NCiAgIGxpbmVzIHdyYXBwZWQgZm9yIHJlYWRhYmlsaXR5KSBp czoNDQoNDQogICBuLGE9dXNlckBleGFtcGxlLmNvbSxeQWhvc3Q9c2VydmVy LmV4YW1wbGUuY29tXkFwb3J0PTE0M15BDQ0KICAgYXV0aD1CZWFyZXIgdkY5 ZGZ0NHFtVGMyTnZiM1JsY2tCaGJIUmhkbWx6ZEdFdVkyOXRDZz09XkFeQQ0N Cg0NCiAgIFRoZSBzYW1lIGNyZWRlbnRpYWwgdXNlZCBpbiBhbiBTTVRQIGV4 Y2hhbmdlIGlzIHNob3duIGJlbG93LiAgTm90ZQ0NCiAgIHRoYXQgbGluZSBi cmVha3MgYXJlIGluc2VydGVkIGZvciByZWFkYWJpbGl0eSwgYW5kIHRoYXQg dGhlIFNNVFANDQogICBwcm90b2NvbCB0ZXJtaW5hdGVzIGxpbmVzIHdpdGgg Q1IgYW5kIExGIGNoYXJhY3RlcnMgKEFTQ0lJIHZhbHVlcw0NCiAgIDB4MEQg YW5kIDB4MEEpLCB0aGVzZSBhcmUgbm90IGRpc3BsYXllZCBleHBsaWNpdGx5 IGluIHRoZSBleGFtcGxlLg0NCg0NCiAgIFtjb25uZWN0aW9uIGJlZ2luc10N DQogICBTOiAyMjAgbXguZXhhbXBsZS5jb20gRVNNVFAgMTJzbTIwOTU2MDNm a3MuOQ0NCiAgIEM6IEVITE8gc2VuZGVyLmV4YW1wbGUuY29tDQ0KICAgUzog MjUwLW14LmV4YW1wbGUuY29tIGF0IHlvdXIgc2VydmljZSxbMTcyLjMxLjEz NS40N10NDQogICBTOiAyNTAtU0laRSAzNTY1MTU4NA0NCiAgIFM6IDI1MC04 QklUTUlNRQ0NCiAgIFM6IDI1MC1BVVRIIExPR0lOIFBMQUlOIE9BVVRIQkVB UkVSDQ0KICAgUzogMjUwLUVOSEFOQ0VEU1RBVFVTQ09ERVMNDQogICBTOiAy NTAgUElQRUxJTklORw0NCiAgIEM6IHQxIEFVVEhFTlRJQ0FURSBPQVVUSEJF QVJFUiBiaXhoUFhWelpYSkFaWGhoYlhCc1pTNWpiMjBzQVdodmMzUTljDQ0K ICAgICAgICAgMlZ5ZG1WeUxtVjRZVzF3YkdVdVkyOXRBWEJ2Y25ROU1UUXpB V0YxZEdnOVFtVmhjbVZ5SUhaR09XUm1kRFINDQogICAgICAgICB4YlZSak1r NTJZak5TYkdOclFtaGlTRkpvWkcxc2VtUkhSWFZaTWpsMFEyYzlQUUVCDQ0K ICAgUzogMjM1IEF1dGhlbnRpY2F0aW9uIHN1Y2Nlc3NmdWwuDQ0KICAgW2Nv bm5lY3Rpb24gY29udGludWVzLi4uXQ0NCg0NCjQuMi4gIFN1Y2Nlc3NmdWwg T0F1dGggMS4wYSBUb2tlbiBFeGNoYW5nZQ0NCg0NCiAgIFRoaXMgZXhhbXBs ZSBzaG93cyBhIHN1Y2Nlc3NmdWwgT0F1dGggMS4wYSAgdG9rZW4gZXhjaGFu Z2UuICBOb3RlDQ0KICAgdGhhdCBsaW5lIGJyZWFrcyBhcmUgaW5zZXJ0ZWQg Zm9yIHJlYWRhYmlsaXR5IGFuZCB0aGUgdW5kZXJseWluZyBUTFMNDQogICBl c3RhYmxpc2htZW50IGlzIG5vdCBzaG93bi4gIFNpZ25hdHVyZSBjb21wdXRh dGlvbiBpcyBkaXNjdXNzZWQgaW4NDQogICBTZWN0aW9uIDMuMy4NDQoNDQog ICBTOiAqIE9LIElNQVA0cmV2MSBTZXJ2ZXIgUmVhZHkNDQogICBDOiB0MCBD QVBBQklMSVRZDQ0KICAgUzogKiBDQVBBQklMSVRZIElNQVA0cmV2MSBBVVRI PU9BVVRIQkVBUkVSIE9BVVRIMTBBIFNBU0wtSVINDQogICBTOiB0MCBPSyBD b21wbGV0ZWQNDQogICBDOiB0MSBBVVRIRU5USUNBVEUgT0FVVEgxMEEgYml4 aFBYVnpaWEpBWlhoaGJYQnNaUzVqYjIwc0FXaHZjM1E5WlhoaGINDQogICAg ICAgICBYQnNaUzVqYjIwQmNHOXlkRDB4TkRNQllYVjBhRDFQUVhWMGFDQnla V0ZzYlQwaVJYaGhiWEJzWlNJc2IyRjENDQogICAgICAgICBkR2hmWTI5dWMz VnRaWEpmYTJWNVBTSTVaR3BrYWpneWFEUTRaR3B6T1dReUlpeHZZWFYwYUY5 MGIydGxiajANDQogICAgICAgICBpYTJ0ck9XUTNaR2d6YXpNNWMycDJOeUlz YjJGMWRHaGZjMmxuYm1GMGRYSmxYMjFsZEdodlpEMGlTRTFCUXkNDQogICAg ICAgICAxVFNFRXhJaXh2WVhWMGFGOTBhVzFsYzNSaGJYQTlJakV6TnpFek1U SXdNU0lzYjJGMWRHaGZibTl1WTJVOUkNDQogICAgICAgICBqZGtPR1l6WlRS aElpeHZZWFYwYUY5emFXZHVZWFIxY21VOUlsUnRPVEJKUjBWblkyMVdhR0pE UW5waFYyUjENDQogICAgICAgICBXVmhTTVdOdFZTVXpSQ0lCQVE9PQ0NCiAg IFM6IHQxIE9LIFNBU0wgYXV0aGVudGljYXRpb24gc3VjY2VlZGVkDQ0KDQ0K ICAgQXMgcmVxdWlyZWQgYnkgSU1BUCBbUkZDMzUwMV0sIHRoZSBwYXlsb2Fk cyBhcmUgYmFzZTY0LWVuY29kZWQuICBUaGUNDQogICBkZWNvZGVkIGluaXRp YWwgY2xpZW50IHJlc3BvbnNlICh3aXRoICV4MDEgcmVwcmVzZW50ZWQgYXMg XkEgYW5kIGxvbmcNDQogICBsaW5lcyB3cmFwcGVkIGZvciByZWFkYWJpbGl0 eSkgaXM6DQ0KDQ0KICAgbixhPXVzZXJAZXhhbXBsZS5jb20sXkENDQogICBo b3N0PWV4YW1wbGUuY29tXkENDQogICBwb3J0PTE0M15BDQ0KICAgYXV0aD1P QXV0aCByZWFsbT0iRXhhbXBsZSIsDQ0KICAgICAgICAgICAgICBvYXV0aF9j b25zdW1lcl9rZXk9IjlkamRqODJoNDhkanM5ZDIiLA0NCiAgICAgICAgICAg ICAgb2F1dGhfdG9rZW49ImtrazlkN2RoM2szOXNqdjciLA0NCiAgICAgICAg ICAgICAgb2F1dGhfc2lnbmF0dXJlX21ldGhvZD0iSE1BQy1TSEExIiwNDQog ICAgICAgICAgICAgIG9hdXRoX3RpbWVzdGFtcD0iMTM3MTMxMjAxIiwNDQog ICAgICAgICAgICAgIG9hdXRoX25vbmNlPSI3ZDhmM2U0YSIsDQ0KICAgICAg ICAgICAgICBvYXV0aF9zaWduYXR1cmU9IlRtOTBJR0VnY21WaGJDQnphV2R1 WVhSMWNtVSUzRCJeQV5BDQ0KDQ0KNC4zLiAgRmFpbGVkIEV4Y2hhbmdlDQ0K DQ0KICAgVGhpcyBleGFtcGxlIHNob3dzIGEgZmFpbGVkIGV4Y2hhbmdlIGJl Y2F1c2Ugb2YgdGhlIGVtcHR5DQ0KICAgQXV0aG9yaXphdGlvbiBoZWFkZXIs IHdoaWNoIGlzIGhvdyBhIGNsaWVudCBjYW4gcXVlcnkgZm9yIHRoZSBuZWVk ZWQNDQogICBzY29wZS4gIE5vdGUgdGhhdCBsaW5lIGJyZWFrcyBhcmUgaW5z ZXJ0ZWQgZm9yIHJlYWRhYmlsaXR5Lg0NCg0NCiAgIFM6ICogQ0FQQUJJTElU WSBJTUFQNHJldjEgQVVUSD1PQVVUSEJFQVJFUiBTQVNMLUlSIElNQVA0cmV2 MSBTZXJ2ZXINDQogICAgICAgIFJlYWR5DQ0KICAgUzogdDAgT0sgQ29tcGxl dGVkDQ0KICAgQzogdDEgQVVUSEVOVElDQVRFIE9BVVRIQkVBUkVSIGJpeGhQ WFZ6WlhKQVpYaGhiWEJzWlM1amIyMHNBVw0NCiAgICAgICAgIGh2YzNROWMy VnlkbVZ5TG1WNFlXMXdiR1V1WTI5dEFYQnZjblE5TVRRekFXRjFkR2c5QVFF PQ0NCiAgIFM6ICsgZXdvaWMzUmhkSFZ6SWpvaU5EQXhJZ29pYzJOdmNHVWlP aUpsZUdGdGNHeGxYM05qYjNCbElncDkNDQogICBDOiArIEFRPT0NDQogICBT OiB0MSBOTyBTQVNMIGF1dGhlbnRpY2F0aW9uIGZhaWxlZA0NCg0NCiAgIFRo ZSBkZWNvZGVkIGluaXRpYWwgY2xpZW50IHJlc3BvbnNlIGlzOg0NCg0NCiAg IG4sYT11c2VyQGV4YW1wbGUuY29tLF5BaG9zdD1zZXJ2ZXIuZXhhbXBsZS5j b21eQQ0NCiAgIHBvcnQ9MTQzXkFhdXRoPV5BXkENDQoNDQogICBUaGUgZGVj b2RlZCBzZXJ2ZXIgZXJyb3IgcmVzcG9uc2UgaXM6DQ0KDQ0KICAgew0NCiAg ICJzdGF0dXMiOiI0MDEiLA0NCiAgICJzY29wZSI6ImV4YW1wbGVfc2NvcGUi DQ0KICAgfQ0NCg0NCiAgIFRoZSBjbGllbnQgcmVzcG9uZHMgd2l0aCB0aGUg cmVxdWlyZWQgZHVtbXkgcmVzcG9uc2UuDQ0KDQ0KNC40LiAgU01UUCBFeGFt cGxlIG9mIGEgRmFpbGVkIE5lZ290aWF0aW9uDQ0KDQ0KICAgVGhpcyBleGFt cGxlIHNob3dzIGFuIGF1dGhvcml6YXRpb24gZmFpbHVyZSBpbiBhbiBTTVRQ IGV4Y2hhbmdlLg0NCiAgIE5vdGUgdGhhdCBsaW5lIGJyZWFrcyBhcmUgaW5z ZXJ0ZWQgZm9yIHJlYWRhYmlsaXR5LCBhbmQgdGhhdCB0aGUgU01UUA0NCiAg IHByb3RvY29sIHRlcm1pbmF0ZXMgbGluZXMgd2l0aCBDUiBhbmQgTEYgY2hh cmFjdGVycyAoQVNDSUkgdmFsdWVzDQ0KICAgMHgwRCBhbmQgMHgwQSksIHRo ZXNlIGFyZSBub3QgZGlzcGxheWVkIGV4cGxpY2l0bHkgaW4gdGhlIGV4YW1w bGUuDQ0KDQ0KICAgW2Nvbm5lY3Rpb24gYmVnaW5zXQ0NCiAgIFM6IDIyMCBt eC5leGFtcGxlLmNvbSBFU01UUCAxMnNtMjA5NTYwM2Zrcy45DQ0KICAgQzog RUhMTyBzZW5kZXIuZXhhbXBsZS5jb20NDQogICBTOiAyNTAtbXguZXhhbXBs ZS5jb20gYXQgeW91ciBzZXJ2aWNlLFsxNzIuMzEuMTM1LjQ3XQ0NCiAgIFM6 IDI1MC1TSVpFIDM1NjUxNTg0DQ0KICAgUzogMjUwLThCSVRNSU1FDQ0KICAg UzogMjUwLUFVVEggTE9HSU4gUExBSU4gT0FVVEhCRUFSRVINDQogICBTOiAy NTAtRU5IQU5DRURTVEFUVVNDT0RFUw0NCiAgIFM6IDI1MCBQSVBFTElOSU5H DQ0KICAgQzogQVVUSCBPQVVUSEJFQVJFUiBiaXgxYzJWeVBYTnZiV1YxYzJW eVFHVjRZVzF3YkdVdVkyOXRMQUZoZFhSb1BVSmxZWEpsDQ0KICAgICAgICAg ICBjaUIyUmpsa1puUTBjVzFVWXpKT2RtSXpVbXhqYTBKb1pFaFNhR1J0Ykhw a1IwVjFXVEk1ZEVOblBUMEJBUT09DQ0KICAgUzogMzM0IGV5SnpkR0YwZFhN aU9pSTBNREVpTENKelkyaGxiV1Z6SWpvaVltVmhjbVZ5SUcxaFl5SXNJbk5q YjNCbElqb2lhDQ0KICAgICAgICAgIEhSMGNITTZMeTl0WVdsc0xtZHZiMmRz WlM1amIyMHZJbjBLDQ0KICAgQzogQVE9PQ0NCiAgIFM6IDUzNS01LjcuMSBV c2VybmFtZSBhbmQgUGFzc3dvcmQgbm90IGFjY2VwdGVkLiBMZWFybiBtb3Jl IGF0DQ0KICAgUzogNTM1IDUuNy4xIGh0dHA6Ly9zdXBwb3J0LmV4YW1wbGUu Y29tL21haWwvb2F1dGgNDQogICBbY29ubmVjdGlvbiBjb250aW51ZXMuLi5d DQ0KDQ0KICAgVGhlIHNlcnZlciByZXR1cm5lZCBhbiBlcnJvciBtZXNzYWdl IGluIHRoZSAzMzQgU0FTTCBtZXNzYWdlLCB0aGUNDQogICBjbGllbnQgcmVz cG9uZHMgd2l0aCB0aGUgcmVxdWlyZWQgZHVtbXkgcmVzcG9uc2UsIGFuZCB0 aGUgc2VydmVyDQ0KICAgZmluYWxpemVzIHRoZSBuZWdvdGlhdGlvbi4NDQoN DQo1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNDQoNDQogICBPQXV0aCAx LjBhIGFuZCBPQXV0aCAyIGFsbG93cyBmb3IgYSB2YXJpZXR5IG9mIGRlcGxv eW1lbnQgc2NlbmFyaW9zLA0NCiAgIGFuZCB0aGUgc2VjdXJpdHkgcHJvcGVy dGllcyBvZiB0aGVzZSBwcm9maWxlcyB2YXJ5LiAgQXMgc2hvd24gaW4NDQog ICBGaWd1cmUgMSB0aGlzIHNwZWNpZmljYXRpb24gaXMgYWltZWQgdG8gYmUg aW50ZWdyYXRlZCBpbnRvIGEgbGFyZ2VyDQ0KICAgT0F1dGggZGVwbG95bWVu dC4gIEFwcGxpY2F0aW9uIGRldmVsb3BlcnMgdGhlcmVmb3JlIG5lZWQgdG8N DQogICB1bmRlcnN0YW5kIHRoZSBuZWVkcyBvZiB0aGVpciBzZWN1cml0eSBy ZXF1aXJlbWVudHMgYmFzZWQgb24gYSB0aHJlYXQNDQogICBhc3Nlc3NtZW50 IGJlZm9yZSBzZWxlY3RpbmcgYSBzcGVjaWZpYyBTQVNMIE9BdXRoIG1lY2hh bmlzbS4gIEZvcg0NCiAgIE9BdXRoIDIuMCBhIGRldGFpbGVkIHNlY3VyaXR5 IGRvY3VtZW50IFtSRkM2ODE5XSBwcm92aWRlcyBndWlkYW5jZSB0bw0NCiAg IHNlbGVjdCB0aG9zZSBPQXV0aCAyLjAgY29tcG9uZW50cyB0aGF0IGhlbHAg dG8gbWl0aWdhdGUgdGhyZWF0cyBmb3IgYQ0NCiAgIGdpdmVuIGRlcGxveW1l bnQuICBGb3IgT0F1dGggMS4wYSBTZWN0aW9uIDQgb2YgUkZDIDU4NDkgW1JG QzU4NDldDQ0KICAgcHJvdmlkZXMgZ3VpZGFuY2Ugc3BlY2lmaWMgdG8gT0F1 dGggMS4wLg0NCg0NCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHR3byBT QVNMICBNZWNoYW5pc21zIGZvciBPQXV0aCBhbmQgZWFjaCBjb21lcw0NCiAg IHdpdGggZGlmZmVyZW50IHNlY3VyaXR5IHByb3BlcnRpZXMuDQ0KDQ0KICAg T0FVVEhCRUFSRVI6IFRoaXMgbWVjaGFuaXNtIGJvcnJvd3MgZnJvbSBPQXV0 aCAyLjAgYmVhcmVyIHRva2Vucw0NCiAgICAgIFtSRkM2NzUwXS4gIEl0IHJl bGllcyBvbiB0aGUgYXBwbGljYXRpb24gdXNpbmcgVExTIHRvIHByb3RlY3Qg dGhlDQ0KICAgICAgT0F1dGggMi4wIEJlYXJlciBUb2tlbiBleGNoYW5nZTsg d2l0aG91dCBUTFMgdXNhZ2UgYXQgdGhlDQ0KICAgICAgYXBwbGljYXRpb24g bGF5ZXIgdGhpcyBtZXRob2QgaXMgY29tcGxldGVseSBpbnNlY3VyZS4NDQog ICAgICBDb25zZXF1ZW50bHksIFRMUyBNVVNUIGJlIHByb3ZpZGVkIGJ5IHRo ZSBhcHBsaWNhdGlvbiB3aGVuDQ0KICAgICAgY2hvb3NpbmcgdGhpcyBhdXRo ZW50aWNhdGlvbiBtZWNoYW5pc20uDQ0KDQ0KICAgT0FVVEgxMEE6IFRoaXMg bWVjaGFuaXNtIHJlLXVzZXMgT0F1dGggMS4wYSBNQUMgdG9rZW5zICh1c2lu ZyB0aGUNDQogICAgICBITUFDLVNIQTEga2V5ZWQgbWVzc2FnZSBkaWdlc3Qp LCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjQuMiBvZg0NCiAgICAgIFtS RkM1ODQ5XS4gIFRvIGNvbXB1dGUgdGhlIGtleWVkIG1lc3NhZ2UgZGlnZXN0 IGluIHRoZSBzYW1lIHdheQ0NCiAgICAgIHdhcyBpbiBSRkMgNTgzOSB0aGlz IHNwZWNpZmljYXRpb24gY29udmV5cyBhZGRpdGlvbmFsIHBhcmFtZXRlcnMN DQogICAgICBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBzZXJ2ZXIuICBU aGlzIFNBU0wgbWVjaGFuaXNtIG9ubHkNDQogICAgICBzdXBwb3J0cyBjbGll bnQgYXV0aGVudGljYXRpb24uICBJZiBzZXJ2ZXItc2lkZSBhdXRoZW50aWNh dGlvbiBpcw0NCiAgICAgIGRlc2lyZWFibGUgdGhlbiBpdCBtdXN0IGJlIHBy b3ZpZGVkIGJ5IHRoZSBhcHBsaWNhdGlvbiB1bmRlcm5lYXRoDQ0KICAgICAg dGhlIFNBU0wgbGF5ZXIuICBUaGUgdXNlIG9mIFRMUyBpcyBzdHJvbmdseSBS RUNPTU1FTkRFRC4NDQoNDQogICBBZGRpdGlvbmFsbHksIHRoZSBmb2xsb3dp bmcgYXNwZWN0cyBhcmUgd29ydGggcG9pbnRpbmcgb3V0Og0NCg0NCiAgIEFu IGFjY2VzcyB0b2tlbiBpcyBub3QgZXF1aXZhbGVudCB0byB0aGUgdXNlcidz IGxvbmcgdGVybSBwYXNzd29yZC4gDQ0KDQ0KICAgICAgQ2FyZSBoYXMgdG8g YmUgdGFrZW4gd2hlbiB0aGVzZSBPQXV0aCBjcmVkZW50aWFscyBhcmUgdXNl ZCBmb3INDQogICAgICBhY3Rpb25zIGxpa2UgY2hhbmdpbmcgcGFzc3dvcmRz IChhcyBpdCBpcyBwb3NzaWJsZSB3aXRoIHNvbWUNDQogICAgICBwcm90b2Nv bHMsIGUuZy4sIFhNUFAgW1JGQzYxMjBdKS4gVGhlIHJlc291cmNlIHNlcnZl ciBzaG91bGQNDQogICAgICBlbnN1cmUgdGhhdCBhY3Rpb25zIHRha2VuIGlu IHRoZSBhdXRoZW50aWNhdGVkIGNoYW5uZWwgYXJlDQ0KICAgICAgYXBwcm9w cmlhdGUgdG8gdGhlIHN0cmVuZ3RoIG9mIHRoZSBwcmVzZW50ZWQgY3JlZGVu dGlhbC4NDQoNDQogICBMaWZldGltZSBvZiB0aGUgYXBwbGlhdGlvbiBzZXNz aW9ucy4gDQ0KDQ0KICAgICAgSXQgaXMgcG9zc2libGUgdGhhdCBTQVNMIHdp bGwgYmUgYXV0aGVudGljYXRpbmcgYSBjb25uZWN0aW9uIGFuZA0NCiAgICAg IHRoZSBsaWZlIG9mIHRoYXQgY29ubmVjdGlvbiBtYXkgb3V0bGFzdCB0aGUg bGlmZSBvZiB0aGUgYWNjZXNzDQ0KICAgICAgdG9rZW4gdXNlZCB0byBlc3Rh Ymxpc2ggaXQuICBUaGlzIGlzIGEgY29tbW9uIHByb2JsZW0gaW4NDQogICAg ICBhcHBsaWNhdGlvbiBwcm90b2NvbHMgd2hlcmUgY29ubmVjdGlvbnMgYXJl IGxvbmctbGl2ZWQsIGFuZCBub3QgYQ0NCiAgICAgIHByb2JsZW0gd2l0aCB0 aGlzIG1lY2hhbmlzbSBwZXIgc2UuICBSZXNvdXJjZSBzZXJ2ZXJzIG1heQ0N CiAgICAgIHVuaWxhdGVyYWxseSBkaXNjb25uZWN0IGNsaWVudHMgaW4gYWNj b3JkYW5jZSB3aXRoIHRoZSBhcHBsaWNhdGlvbg0NCiAgICAgIHByb3RvY29s Lg0NCg0NCiAgIEFjY2VzcyB0b2tlbnMgaGF2ZSBhIGxpZmV0aW1lLiANDQoN DQogICAgICBSZWR1Y2luZyB0aGUgbGlmZXRpbWUgb2YgYW4gYWNjZXNzIHRv a2VuIHByb3ZpZGVzIHNlY3VyaXR5DQ0KICAgICAgYmVuZWZpdHMgYW5kIE9B dXRoIDIuMCBpbnRyb2R1Y2VzIHJlZnJlc2ggdG9rZW5zIHRvIG9idGFpbiBu ZXcNDQogICAgICBhY2Nlc3MgdG9rZW4gb24gdGhlIGZseSB3aXRob3V0IGFu eSBuZWVkIGZvciBhIGh1bWFuIGludGVyYWN0aW9uLg0NCiAgICAgIEFkZGl0 aW9uYWxseSwgYSBwcmV2aW91c2x5IG9idGFpbmVkIGFjY2VzcyB0b2tlbiBt YXkgYmUgcmV2b2tlZCBvcg0NCiAgICAgIHJlbmRlcmVkIGludmFsaWQgYXQg YW55IHRpbWUuICBUaGUgY2xpZW50IG1heSByZXF1ZXN0IGEgbmV3IGFjY2Vz cw0NCiAgICAgIHRva2VuIGZvciBlYWNoIGNvbm5lY3Rpb24gdG8gYSByZXNv dXJjZSBzZXJ2ZXIsIGJ1dCBpdCBTSE9VTEQNDQogICAgICBjYWNoZSBhbmQg cmUtdXNlIHZhbGlkIGNyZWRlbnRpYWxzLg0NCg0NCjYuICBJbnRlcm5hdGlv bmFsaXphdGlvbiBDb25zaWRlcmF0aW9ucw0NCg0NCiAgIFRoZSBpZGVudGlm ZXIgYXNzZXJ0ZWQgYnkgdGhlIE9BdXRoIGF1dGhvcml6YXRpb24gc2VydmVy IGFib3V0IHRoZQ0NCiAgIHJlc291cmNlIG93bmVyIGluc2lkZSB0aGUgYWNj ZXNzIHRva2VuIG1heSBiZSBkaXNwbGF5ZWQgdG8gYSBodW1hbi4NDQogICBG b3IgZXhhbXBsZSwgd2hlbiBTQVNMIGlzIHVzZWQgaW4gdGhlIGNvbnRleHQg b2YgSU1BUCB0aGUgcmVzb3VyY2UNDQogICBzZXJ2ZXIgbWF5IGFzc2VydCB0 aGUgcmVzb3VyY2Ugb3duZXIncyBlbWFpbCBhZGRyZXNzIHRvIHRoZSBJTUFQ DQ0KICAgc2VydmVyIGZvciB1c2FnZSBpbiBhbiBlbWFpbC1iYXNlZCBhcHBs aWNhdGlvbi4gIFRoZSBpZGVudGlmaWVyIG1heQ0NCiAgIHRoZXJlZm9yZSBj b250YWluIGludGVybmF0aW9uYWxpemVkIGNoYXJhY3RlcnMgYW5kIGFuIGFw cGxpY2F0aW9uDQ0KICAgbmVlZHMgdG8gZW5zdXJlIHRoYXQgdGhlIG1hcHBp bmcgYmV0d2VlbiB0aGUgaWRlbnRpZmllciBwcm92aWRlZCBieQ0NCiAgIE9B dXRoIGlzIHN1aXRhYmxlIGZvciB1c2Ugd2l0aCB0aGUgYXBwbGljYXRpb24g bGF5ZXIgcHJvdG9jb2wgU0FTTCBpcw0NCiAgIGluY29ycG9yYXRlZCBpbnRv Lg0NCg0NCiAgIEF0IHRoZSB0aW1lIG9mIHdyaXRpbmcgdGhlIHN0YW5kYXJk aXphdGlvbiBvZiB0aGUgdmFyaW91cyBjbGFpbXMgaW4NDQogICB0aGUgYWNj ZXNzIHRva2VuIChpbiBKU09OIGZvcm1hdCkgaXMgc3RpbGwgb25nb2luZywg c2VlIFtJLUQuaWV0Zi0NDQogICBvYXV0aC1qc29uLXdlYi10b2tlbl0uICBP bmNlIGNvbXBsZXRlZCBpdCB3aWxsIHByb3ZpZGUgYSBzdGFuZGFyZGl6ZWQN DQogICBmb3JtYXQgZm9yIGV4Y2hhbmdpbmcgaWRlbnRpdHkgaW5mb3JtYXRp b24gYmV0d2VlbiB0aGUgYXV0aG9yaXphdGlvbg0NCiAgIHNlcnZlciBhbmQg dGhlIHJlc291cmNlIHNlcnZlci4NDQoNDQo3LiAgSUFOQSBDb25zaWRlcmF0 aW9ucw0NCg0NCjcuMS4gIFNBU0wgUmVnaXN0cmF0aW9uDQ0KDQ0KICAgVGhl IElBTkEgaXMgcmVxdWVzdGVkIHRvIHJlZ2lzdGVyIHRoZSBmb2xsb3dpbmcg U0FTTCBwcm9maWxlOg0NCg0NCiAgICAgIFNBU0wgbWVjaGFuaXNtIHByb2Zp bGU6IE9BVVRIQkVBUkVSDQ0KDQ0KICAgICAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnM6IFNlZSB0aGlzIGRvY3VtZW50DQ0KDQ0KICAgICAgUHVibGlzaGVk IFNwZWNpZmljYXRpb246IFNlZSB0aGlzIGRvY3VtZW50DQ0KDQ0KICAgICAg Rm9yIGZ1cnRoZXIgaW5mb3JtYXRpb246IENvbnRhY3QgdGhlIGF1dGhvcnMg b2YgdGhpcyBkb2N1bWVudC4NDQoNDQogICAgICBPd25lci9DaGFuZ2UgY29u dHJvbGxlcjogdGhlIElFVEYNDQoNDQogICAgICBOb3RlOiBOb25lDQ0KDQ0K ICAgVGhlIElBTkEgaXMgcmVxdWVzdGVkIHRvIHJlZ2lzdGVyIHRoZSBmb2xs b3dpbmcgU0FTTCBwcm9maWxlOg0NCg0NCiAgICAgIFNBU0wgbWVjaGFuaXNt IHByb2ZpbGU6IE9BVVRIMTBBDQ0KDQ0KICAgICAgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnM6IFNlZSB0aGlzIGRvY3VtZW50DQ0KDQ0KICAgICAgUHVibGlz aGVkIFNwZWNpZmljYXRpb246IFNlZSB0aGlzIGRvY3VtZW50DQ0KDQ0KICAg ICAgRm9yIGZ1cnRoZXIgaW5mb3JtYXRpb246IENvbnRhY3QgdGhlIGF1dGhv cnMgb2YgdGhpcyBkb2N1bWVudC4NDQoNDQogICAgICBPd25lci9DaGFuZ2Ug Y29udHJvbGxlcjogdGhlIElFVEYNDQoNDQogICAgICBOb3RlOiBOb25lDQ0K DQ0KOC4gIFJlZmVyZW5jZXMNDQoNDQo4LjEuICBOb3JtYXRpdmUgUmVmZXJl bmNlcw0NCg0NCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29y ZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQ0KICAgICAgICAgICAg ICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJj aCAxOTk3Lg0NCg0NCiAgIFtSRkMzMTc0XSAgRWFzdGxha2UsIEQuIGFuZCBQ LiBKb25lcywgIlVTIFNlY3VyZSBIYXNoIEFsZ29yaXRobSAxDQ0KICAgICAg ICAgICAgICAoU0hBMSkiLCBSRkMgMzE3NCwgU2VwdGVtYmVyIDIwMDEuDQ0K DQ0KICAgW1JGQzQ0MjJdICBNZWxuaWtvdiwgQS4gYW5kIEsuIFplaWxlbmdh LCAiU2ltcGxlIEF1dGhlbnRpY2F0aW9uIGFuZA0NCiAgICAgICAgICAgICAg U2VjdXJpdHkgTGF5ZXIgKFNBU0wpIiwgUkZDIDQ0MjIsIEp1bmUgMjAwNi4N DQoNDQogICBbUkZDNDYyN10gIENyb2NrZm9yZCwgRC4sICJUaGUgYXBwbGlj YXRpb24vanNvbiBNZWRpYSBUeXBlIGZvcg0NCiAgICAgICAgICAgICAgSmF2 YVNjcmlwdCBPYmplY3QgTm90YXRpb24gKEpTT04pIiwgUkZDIDQ2MjcsIEp1 bHkgMjAwNi4NDQoNDQogICBbUkZDNDY0OF0gIEpvc2Vmc3NvbiwgUy4sICJU aGUgQmFzZTE2LCBCYXNlMzIsIGFuZCBCYXNlNjQgRGF0YQ0NCiAgICAgICAg ICAgICAgRW5jb2RpbmdzIiwgUkZDIDQ2NDgsIE9jdG9iZXIgMjAwNi4NDQoN DQogICBbUkZDNTIzNF0gIENyb2NrZXIsIEQuIGFuZCBQLiBPdmVyZWxsLCAi QXVnbWVudGVkIEJORiBmb3IgU3ludGF4DQ0KICAgICAgICAgICAgICBTcGVj aWZpY2F0aW9uczogQUJORiIsIFNURCA2OCwgUkZDIDUyMzQsIEphbnVhcnkg MjAwOC4NDQoNDQogICBbUkZDNTI0Nl0gIERpZXJrcywgVC4gYW5kIEUuIFJl c2NvcmxhLCAiVGhlIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eQ0NCiAgICAg ICAgICAgICAgKFRMUykgUHJvdG9jb2wgVmVyc2lvbiAxLjIiLCBSRkMgNTI0 NiwgQXVndXN0IDIwMDguDQ0KDQ0KICAgW1JGQzU4MDFdICBKb3NlZnNzb24s IFMuIGFuZCBOLiBXaWxsaWFtcywgIlVzaW5nIEdlbmVyaWMgU2VjdXJpdHkN DQogICAgICAgICAgICAgIFNlcnZpY2UgQXBwbGljYXRpb24gUHJvZ3JhbSBJ bnRlcmZhY2UgKEdTUy1BUEkpIE1lY2hhbmlzbXMNDQogICAgICAgICAgICAg IGluIFNpbXBsZSBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJpdHkgTGF5ZXIg KFNBU0wpOiBUaGUNDQogICAgICAgICAgICAgIEdTMiBNZWNoYW5pc20gRmFt aWx5IiwgUkZDIDU4MDEsIEp1bHkgMjAxMC4NDQoNDQogICBbUkZDNTg0OV0g IEhhbW1lci1MYWhhdiwgRS4sICJUaGUgT0F1dGggMS4wIFByb3RvY29sIiwg UkZDIDU4NDksDQ0KICAgICAgICAgICAgICBBcHJpbCAyMDEwLg0NCg0NCiAg IFtSRkM2NzQ5XSAgSGFyZHQsIEQuLCAiVGhlIE9BdXRoIDIuMCBBdXRob3Jp emF0aW9uIEZyYW1ld29yayIsIFJGQw0NCiAgICAgICAgICAgICAgNjc0OSwg T2N0b2JlciAyMDEyLg0NCg0NCiAgIFtSRkM2NzUwXSAgSm9uZXMsIE0uIGFu ZCBELiBIYXJkdCwgIlRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbg0NCiAg ICAgICAgICAgICAgRnJhbWV3b3JrOiBCZWFyZXIgVG9rZW4gVXNhZ2UiLCBS RkMgNjc1MCwgT2N0b2JlciAyMDEyLg0NCg0NCjguMi4gIEluZm9ybWF0aXZl IFJlZmVyZW5jZXMNDQoNDQogICBbSS1ELmlldGYtb2F1dGgtanNvbi13ZWIt dG9rZW5dDQ0KICAgICAgICAgICAgICBKb25lcywgTS4sIEJyYWRsZXksIEou IGFuZCBOLiBTYWtpbXVyYSwgIkpTT04gV2ViIFRva2VuDQ0KICAgICAgICAg ICAgICAoSldUKSIsIEludGVybmV0LURyYWZ0IGRyYWZ0LWlldGYtb2F1dGgt anNvbi13ZWItdG9rZW4tMTMsDQ0KICAgICAgICAgICAgICBOb3ZlbWJlciAy MDEzLg0NCg0NCiAgIFtJLUQuaWV0Zi1vYXV0aC12Mi1odHRwLW1hY10NDQog ICAgICAgICAgICAgIEhhbW1lci1MYWhhdiwgRS4sICJIVFRQIEF1dGhlbnRp Y2F0aW9uOiBNQUMgQWNjZXNzDQ0KICAgICAgICAgICAgICBBdXRoZW50aWNh dGlvbiIsIEludGVybmV0LURyYWZ0IGRyYWZ0LWlldGYtb2F1dGgtdjItaHR0 cC0NDQogICAgICAgICAgICAgIG1hYy0wMSwgRmVicnVhcnkgMjAxMi4NDQoN DQogICBbUkZDMjYxNl0gIEZpZWxkaW5nLCBSLiwgR2V0dHlzLCBKLiwgTW9n dWwsIEouLCBGcnlzdHlrLCBILiwNDQogICAgICAgICAgICAgIE1hc2ludGVy LCBMLiwgTGVhY2gsIFAuIGFuZCBULiBCZXJuZXJzLUxlZSwgIkh5cGVydGV4 dA0NCiAgICAgICAgICAgICAgVHJhbnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8x LjEiLCBSRkMgMjYxNiwgSnVuZSAxOTk5Lg0NCg0NCiAgIFtSRkMzNTAxXSAg Q3Jpc3BpbiwgTS4sICJJTlRFUk5FVCBNRVNTQUdFIEFDQ0VTUyBQUk9UT0NP TCAtIFZFUlNJT04NDQogICAgICAgICAgICAgIDRyZXYxIiwgUkZDIDM1MDEs IE1hcmNoIDIwMDMuDQ0KDQ0KICAgW1JGQzUzMjFdICBLbGVuc2luLCBKLiwg IlNpbXBsZSBNYWlsIFRyYW5zZmVyIFByb3RvY29sIiwgUkZDIDUzMjEsDQ0K ICAgICAgICAgICAgICBPY3RvYmVyIDIwMDguDQ0KDQ0KICAgW1JGQzYxMjBd ICBTYWludC1BbmRyZSwgUC4sICJFeHRlbnNpYmxlIE1lc3NhZ2luZyBhbmQg UHJlc2VuY2UNDQogICAgICAgICAgICAgIFByb3RvY29sIChYTVBQKTogQ29y ZSIsIFJGQyA2MTIwLCBNYXJjaCAyMDExLg0NCg0NCiAgIFtSRkM2ODE5XSAg TG9kZGVyc3RlZHQsIFQuLCBNY0dsb2luLCBNLiBhbmQgUC4gSHVudCwgIk9B dXRoIDIuMA0NCiAgICAgICAgICAgICAgVGhyZWF0IE1vZGVsIGFuZCBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyIsIFJGQyA2ODE5LA0NCiAgICAgICAgICAg ICAgSmFudWFyeSAyMDEzLg0NCg0NCiAgIFtSRkM3MDMzXSAgSm9uZXMsIFAu LCBTYWxndWVpcm8sIEcuLCBKb25lcywgTS4gYW5kIEouIFNtYXJyLA0NCiAg ICAgICAgICAgICAgIldlYkZpbmdlciIsIFJGQyA3MDMzLCBTZXB0ZW1iZXIg MjAxMy4NDQoNDQpBcHBlbmRpeCBBLiAgQWNrbm93bGVnZW1lbnRzDQ0KDQ0K ICAgVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byB0aGFuayB0aGUgbWVtYmVy cyBvZiB0aGUgS2l0dGVuIHdvcmtpbmcNDQogICBncm91cCwgYW5kIGluIGFk ZGl0aW9uIGFuZCBzcGVjaWZpY2FsbHk6IFNpbW9uIEpvc2Vmc29uLCBUb3Jz dGVuDQ0KICAgTG9kZGVyc3RhZHQsIFJ5YW4gVHJvbGwsIEFsZXhleSBNZWxu aWtvdiwgSmVmZnJleSBIdXR6ZWxtYW4sIE5pY28NDQogICBXaWxsaWFtcywg YW5kIE1hdHQgTWlsbGVyLg0NCg0NCiAgIFRoaXMgZG9jdW1lbnQgd2FzIHBy b2R1Y2VkIHVuZGVyIHRoZSBjaGFpcm1hbnNoaXAgb2YgQWxleGV5IE1lbG5p a292LA0NCiAgIFRvbSBZdSwgU2hhd24gRW1lcnksIEpvc2ggSG93bGV0dCwg U2FtIEhhcnRtYW4uICBUaGUgc3VwZXJ2aXNpbmcgYXJlYQ0NCiAgIGRpcmVj dG9yIHdhcyBTdGVwaGVuIEZhcnJlbGwuDQ0KDQ0KQXBwZW5kaXggQi4gIERv Y3VtZW50IEhpc3RvcnkNDQoNDQogICBbWyB0byBiZSByZW1vdmVkIGJ5IFJG QyBlZGl0b3IgYmVmb3JlIHB1YmxpY2F0aW9uIGFzIGFuIFJGQyBdXQ0NCg0N CiAgIC0xNQ0NCg0NCiAgIG8gIExhc3QgY2FsbCBmZWVkYWNrIG9uIHRoZSBH UzIgc3R1ZmYgYmVpbmcgcmlwcGVkIG91dCBjb21wbGV0ZWx5Li4NDQoNDQog ICBvICBSZW1vdmVkIHRoZSAidXNlciIgcGFyYW1ldGVyIGFuZCBwdXQgc3R1 ZmYgYmFjayBpbnRvIHRoZQ0NCiAgICAgIGdzMi1oZWFkZXIuICBDYWxsIG91 dCB0aGF0IHRoZSBhdXRoemlkIG11c3QgZ28gaW4gdGhlIGdzMi1oZWFkZXIu DQ0KICAgICAgVmVyeSBjb21wYXJhYmxlIHRvIC0xMC4NDQoNDQogICBvICBB ZGRlZCBhbiBPQXV0aCAxLjBBIGV4YW1wbGUgZXhwbGljaXRseS4NDQoNDQog ICAtMTQNDQoNDQogICBvICBMYXN0IGNhbGwgZmVlZGFjayBvbiBSRkMgY2l0 YXRpb25zIG5lZWRlZCwgc21hbGwgZWRpdG9yaWFsLg0NCg0NCiAgIG8gIEFk ZGVkIHRoZSAidXNlciIgcGFyYW1ldGVyIGJhY2ssIHdoaWNoIHdhcyBwdWxs ZWQgd2hlbiB3ZSBzdGFydGVkDQ0KICAgICAgZG93biB0aGUgR1MyIHBhdGgu ICBTYW1lIGxhbmd1YWdlIGFzIC0wMy4NDQoNDQogICBvICBEZWZpbmVkIGEg c3R1YiBHUzIgaGVhZGVyIHRvIG1ha2Ugc3VyZSB0aGF0IHdoZW4gdGhlIEdT MiBicmlkZSBpcw0NCiAgICAgIGRlZmluZWQgZm9yIHRoaXMgdGhhdCBub3Ro aW5nIHdpbGwgYnJlYWsgd2hlbiBpdCBhY3R1YWxseSBzdGFydHMNDQogICAg ICB0byBnZXQgcG9wdWxhdGVkLg0NCg0NCiAgIC0xMw0NCg0NCiAgIG8gIENo YW5nZWQgYWZmaWxpYXRpb24uDQ0KDQ0KICAgLTEyDQ0KDQ0KICAgbyAgUmVt b3ZlZCAtUExVUyBjb21wb25lbnRzIGZyb20gdGhlIHNwZWNpZmljYXRpb24u DQ0KDQ0KICAgLTExDQ0KDQ0KICAgbyAgUmVtb3ZlZCBHU1MtQVBJIGNvbXBv bmVudHMgZnJvbSB0aGUgc3BlY2lmaWNhdGlvbi4NDQoNDQogICBvICBVcGRh dGVkIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbi4NDQoNDQogICAt MTANDQoNDQogICBvICBDbGFyaWZpY2F0aW9ucyB0aHJvdWdob3V0IHRoZSBk b2N1bWVudCBpbiByZXNwb25zZSB0byB0aGUgZmVlZGJhY2sNDQogICAgICBm cm9tIEplZmZyZXkgSHV0emVsbWFuLg0NCg0NCiAgIC0wOQ0NCg0NCiAgIG8g IEluY29ycG9yYXRlZCByZXZpZXcgYnkgQWxleGV5IGFuZCBIYW5uZXMuDQ0K DQ0KICAgbyAgQ2xhcmlmaWVkIHRoZSB0aHJlZSBPQXV0aCBTQVNMIG1lY2hh bmlzbXMuDQ0KDQ0KICAgbyAgVXBkYXRlZCByZWZlcmVuY2VzDQ0KDQ0KICAg byAgRXh0ZW5kZWQgYWNrbm93bGVkZ2VtZW50cw0NCg0NCiAgIC0wOA0NCg0N CiAgIG8gIEZpeGVkIHRoZSBjaGFubmVsIGJpbmRpbmcgZXhhbXBsZXMgZm9y IHA9JGNidHlwZQ0NCg0NCiAgIG8gIE1vcmUgdHVuaW5nIG9mIHRoZSBhdXRo Y2lkIGxhbmd1YWdlIGFuZCBlZGl0ZWQgYW5kIHJlbmFtZWQgMy4yLjEuDQ0K DQ0KICAgLTA3DQ0KDQ0KICAgbyAgU3RydWNrIHRoZSBNVVNUIGxhbmdpYWdl IGZyb20gYXV0aHppZC4NDQoNDQogICAtMDYNDQoNDQogICBvICBSZW1vdmVk IHRoZSB1c2VyIGZpZWxkLiAgRml4ZWQgdGhlIGV4YW1wbGVzIGFnYWluLg0N Cg0NCiAgIG8gIEFkZGVkIGNhbm9uaWNhbGl6YXRpb24gbGFuZ3VhZ2UuDQ0K DQ0KICAgLTA1DQ0KDQ0KICAgbyAgRml4ZWQgdGhlIEdTMiBoZWFkZXIgbGFu Z3VhZ2UgYWdhaW4uDQ0KDQ0KICAgbyAgU2VwYXJhdGVkIG91dCBkaWZmZXJl bnQgT0F1dGggc2NoZW1lcyBpbnRvIGRpZmZlcmVudCBTQVNMDQ0KICAgICAg bWVjaGFuaXNtcy4gIFRvb2sgb3V0IHRoZSBzY2hlbWUgaW4gdGhlIGVycm9y IHJldHVybi4gIFR1bmVkIHVwDQ0KICAgICAgdGhlIElBTkEgcmVnaXN0cmF0 aW9ucy4NDQoNDQogICBvICBBZGRlZCB0aGUgdXNlciBmaWVsZCBiYWNrIGlu dG8gdGhlIFNBU0wgbWVzc2FnZS4NDQoNDQogICBvICBGaXhlZCB0aGUgZXhh bXBsZXMgKGFnYWluKS4NDQoNDQogICAtMDQNDQoNDQogICBvICBDaGFuZ2Vk IHVzZXIgZmllbGQgdG8gYmUgY2FycmllZCBpbiB0aGUgZ3MyLWhlYWRlciwg YW5kIG1hZGUgZ3MyDQ0KICAgICAgaGVhZGVyIGV4cGxpY2l0IGluIGFsbCBj YXNlcy4NDQoNDQogICBvICBDb252ZXJ0ZWQgTUFDIGV4YW1wbGVzIHRvIE9B dXRoIDEuMGEuICBNb3ZlZCBNQUMgdG8gYW4gaW5mb3JtYXRpdmUNDQogICAg ICByZWZlcmVuY2UuDQ0KDQ0KICAgbyAgQ2hhbmdlZCB0byBzZW5kaW5nIGFu IGVtcHR5IGNsaWVudCByZXNwb25zZSAoc2luZ2xlIGNvbnRyb2wtQSkgYXMN DQogICAgICB0aGUgc2Vjb25kIG1lc3NhZ2Ugb2YgYSBmYWlsZWQgc2VxdWVu Y2UuDQ0KDQ0KICAgbyAgRml4ZWQgY2hhbm5lbCBiaW5kaW5nIHByb3NlIHRv IHJlZmVyIHRvIHRoZSBub3JtYXRpdmUgc3BlY3MgYW5kDQ0KICAgICAgcmVt b3ZlZCB0aGUgaGFzaGluZyBvZiBsYXJnZSBjaGFubmVsIGJpbmRpbmcgZGF0 YSwgd2hpY2ggYnJvdWdodA0NCiAgICAgIG1yb2UgcHJvYmxlbXMgdGhhbiBp dCBzb2x2ZWQuDQ0KDQ0KICAgbyAgQWRkZWQgYSBTTVRQIGV4YW1wbGVzIGZv ciBCZWFyZXIgdXNlIGNhc2UuDQ0KDQ0KICAgLTAzDQ0KDQ0KICAgbyAgQWRk ZWQgdXNlciBmaWVsZCBpbnRvIGV4YW1wbGVzIGFuZCBmaXhlZCBlZ3JlZ2lv dXMgZXJyb3JzIHRoZXJlIGFzDQ0KICAgICAgd2VsbC4NDQoNDQogICBvICBB ZGRlZCB0ZXh0IHJlbWluZGluZyBkZXZlbG9wZXJzIHRoYXQgQXV0aG9yaXph dGlvbiBzY2hlbWUgbmFtZXMNDQogICAgICBhcmUgY2FzZSBpbnNlbnNpdGl2 ZS4NDQoNDQogICAtMDINDQoNDQogICBvICBBZGRlZCB0aGUgdXNlciBkYXRh IGVsZW1lbnQgYmFjayBpbi4NDQoNDQogICBvICBNaW5vciBlZGl0b3JpYWwg Y2hhbmdlcy4NDQoNDQogICAtMDENDQoNDQogICBvICBSaXBwaW5nIG91dCBk aXNjb3ZlcnkuICBDaGFuZ2VkIHRvIHJlZmVyIHRvIEktRC5qb25lcy1hcHBz YXdnLQ0NCiAgICAgIHdlYmZpbmdlciBpbnN0ZWFkIG9mIFdGIGFuZCBTV0Qg b2xkZXIgZHJhZnRzLg0NCg0NCiAgIG8gIFJlcGxhY2luZyBIVFRQIGFzIHRo ZSBtZXNzYWdlIGZvcm1hdCBhbmQgYWRqdXN0ZWQgYWxsIGV4YW1wbGVzLg0N Cg0NCiAgIC0wMA0NCg0NCiAgIG8gIFJlbmFtZWQgZHJhZnQgaW50byBwcm9w ZXIgSUVURiBuYW1pbmcgZm9ybWF0IG5vdyB0aGF0IGl0J3MNDQogICAgICBh ZG9wdGVkLg0NCg0NCiAgIG8gIE1pbm9yIGZpeGVzLg0NCg0NCkF1dGhvcnMn IEFkZHJlc3Nlcw0NCg0NCiAgIFdpbGxpYW0gTWlsbHMNDQogICBZYWhvbyEg SW5jLg0NCiAgIA0NCiAgIEVtYWlsOiB3bWlsbHNfOTIxMDVAeWFob28uY29t DQ0KDQ0KDQ0KICAgVGltIFNob3dhbHRlcg0NCiAgIA0NCiAgIEVtYWlsOiB0 anNAcHNhdXguY29tDQ0KDQ0KDQ0KICAgSGFubmVzIFRzY2hvZmVuaWcNDQog ICBBUk0gTHRkLg0NCiAgIDExMCBGdWxib3VybiBSZA0NCiAgIENhbWJyaWRn ZSwgQ0IxIDlOSg0NCiAgIEdyZWF0IEJyaXRhaW4NDQogICANDQogICBFbWFp bDogSGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldA0NCiAgIFVSSTogICBodHRw Oi8vd3d3LnRzY2hvZmVuaWcucHJpdi5hdA0NCg0NCg== --469468616-147888852-1394650561=:77489-- From nobody Thu Mar 13 11:58:06 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D3E1A0155 for ; Thu, 13 Mar 2014 11:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_VGqDPD1bpL for ; Thu, 13 Mar 2014 11:58:04 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB5E1A03E2 for ; Thu, 13 Mar 2014 11:58:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 29B9A206AE; Thu, 13 Mar 2014 14:53:09 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qayZMdE9tkxl; Thu, 13 Mar 2014 14:53:08 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 13 Mar 2014 14:53:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9367383F4E; Thu, 13 Mar 2014 14:57:55 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott" References: <1394571259.25748.22.camel@minbar.fac.cs.cmu.edu> Date: Thu, 13 Mar 2014 14:57:55 -0400 In-Reply-To: (Scott Cantor's message of "Tue, 11 Mar 2014 23:27:13 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/nxocfttwVdq3jcyu0ptz4LCv7Xk Cc: "kitten@ietf.org" , Sam Hartman , Jeffrey Hutzelman Subject: Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 18:58:05 -0000 I think on the subkey/session key/acceptor subkey space twe need to find the right language to say "just use this key!" in the terminology of rfc 4121. I don't have that swapped in, b ut it's just a matter of finding the right text. From nobody Thu Mar 13 13:09:24 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A38C1A07D9 for ; Thu, 13 Mar 2014 13:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fs8gavLVL_En for ; Thu, 13 Mar 2014 13:09:18 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 959351A075C for ; Thu, 13 Mar 2014 13:09:18 -0700 (PDT) Received: from mail112-tx2-R.bigfish.com (10.9.14.229) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Mar 2014 20:09:11 +0000 Received: from mail112-tx2 (localhost [127.0.0.1]) by mail112-tx2-R.bigfish.com (Postfix) with ESMTP id BCE723A02C1; Thu, 13 Mar 2014 20:09:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.222; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf08; RD:none; EFVD:NLI X-SpamScore: 4 X-BigFish: VPS4(zzbb2dI98dI9371Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzd9hz1de098h1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh1b1cn1b1bi1155h) Received-SPF: pass (mail112-tx2: domain of osu.edu designates 164.107.81.222 as permitted sender) client-ip=164.107.81.222; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf08 ; cio-tnc-pf08 ; Received: from mail112-tx2 (localhost.localdomain [127.0.0.1]) by mail112-tx2 (MessageSwitch) id 1394741350106563_14704; Thu, 13 Mar 2014 20:09:10 +0000 (UTC) Received: from TX2EHSMHS028.bigfish.com (unknown [10.9.14.243]) by mail112-tx2.bigfish.com (Postfix) with ESMTP id 14AD3380067; Thu, 13 Mar 2014 20:09:10 +0000 (UTC) Received: from cio-tnc-pf08 (164.107.81.222) by TX2EHSMHS028.bigfish.com (10.9.99.128) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Mar 2014 20:09:09 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-tnc-pf08 (Postfix) with ESMTPS id D76DA2E008A; Thu, 13 Mar 2014 16:09:08 -0400 (EDT) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.03.0174.001; Thu, 13 Mar 2014 16:09:07 -0400 From: "Cantor, Scott" To: Sam Hartman Thread-Topic: [kitten] comments on draft-ietf-kitten-sasl-saml-ec Thread-Index: AQHPPJGI5mV+TEdtgEiWvASeMKVPmZrfYyuhgAAkp4A= Date: Thu, 13 Mar 2014 20:09:07 +0000 Message-ID: References: <1394571259.25748.22.camel@minbar.fac.cs.cmu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.243.24] Content-Type: text/plain; charset="us-ascii" Content-ID: <789E254A4D2C304C9FB4D4562E2DA05F@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/W-QZW_ZK57MJj40yihYwVCSrcNA Cc: "kitten@ietf.org" , Jeffrey Hutzelman Subject: Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 20:09:21 -0000 On 3/13/14, 2:57 PM, "Sam Hartman" wrote: >I think on the subkey/session key/acceptor subkey space >we need to find the right language to say "just use this key!" in the >terminology of rfc 4121. >I don't have that swapped in, b ut it's just a matter of finding the >right text. I believe the answer is to just use the so-called protocol or session key. There's no subkey here because it's not Kerberos messages going back and forth. That was the intent of the current language so hopefully it's just a clarification that there's no subkey involved. -- Scott From nobody Fri Mar 14 14:52:40 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCCC1A01F4 for ; Fri, 14 Mar 2014 14:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSfwPeqarpZP for ; Fri, 14 Mar 2014 14:52:35 -0700 (PDT) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) by ietfa.amsl.com (Postfix) with ESMTP id 40A191A01DE for ; Fri, 14 Mar 2014 14:52:35 -0700 (PDT) Received: from [66.196.81.170] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 14 Mar 2014 21:52:28 -0000 Received: from [98.139.212.211] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 14 Mar 2014 21:52:28 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 14 Mar 2014 21:52:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 67451.459.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 29757 invoked by uid 60001); 14 Mar 2014 21:52:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394833947; bh=ee4mRSIoRF7XhPT8GVBVBnnlp4CGWw4P9HtZJ3BujCg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tbs1WTDqWqgMnm3l+n14iDVQ9G8w6rS0AaXOYvZaZwHd+dFmgd0+iClL4v/kuTzoCKAjnceS/lN2VqhEM5nIb4UNzjWnYFMBrRMbvtNY4a9Z+k13dqAzucV9KZQir2uI1TesimjI84Qv+HwFfLY236l7oPeiT3ngJX2hGHje5Pk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=wMyu4LdA2R7h6kWl7DPCctPc+h7SQkGISS8YX4D4HVnIiX9lrWswaXnHis92IVJJmNxgd9v3/Vc8mfrR+pAxcGoreNIO93rfZDgBlYbU4lqx2rvPfKEg7bR54uh5lrYkMLx6VJKDMfNqQouQmNazkzebXd/tjvHLXv1Jo1q9ox8=; X-YMail-OSG: rzC0cNgVM1lpZ5ZwdeWKCem7PWTIf3vuf14.1hWdGl1ls9t UrilR1RwHdy2lxMkC09XM6i5pAaCbOiiOyLTCHLRGpwdKoI3hq_IssSXVJvi bIUaIvLD74I5rh40XXdjREWOHfMKoStxeub4IkEWReew4a1QMb9isksI0p8a Mrhigv.MreDaih9HXilTCJiuoyHAbkY.RMyxjtbgS.o0ghW2.PDAOgs3V_gb YEVFAQ1kM4PZSq.6gBw5lhAW2BAu.oHtIjz1SUwM.tPQtO5oy_VIFPkrhEwk e_29ztgIn07JriaOcYv0MQYAD4.QtjOgKljLRhYdl9GTNXN6B.7hPbLqOfkR 0ywL9e5ot5C2uivuCbPENVI6lG1Z_h3lld0BvUBssClWNN.p2nqP6ScKYqS_ KthM5dHmAjrE8AB2hnXCrDBxmfanEp.qjnOD4tjPW80AqK7TtU_xnQH87MBP 8keLDVGIvLJaZt0quYWv0x8.Hn7N0aktrnLp.KsBUu5flqX12UDtj1RJ_9Kz 8zwbIOPVTqc9sUu9bymDt5n7QgInZutAbFMtfVwcS0ysdyUspG299IZkGcHP uQEEY2ZAVbjHm2V.DOEwUknkuLRJuGo8efnHN5BilGDN2zSvlt.dDBBcwRk8 .X0chE1YgZsE3WIa10QAA3NxXPuSN0p4OAfYPWdF0EIU4ahixsEwdCv_lovt CsvdeQ6VfE1O1TdbL79FbAOXLoQi0vABPgnLQQLwW0KMjmciWQOjyUbHlUH. p10h9ASDhJfaz6X2UHdioXf4y8hyd2FBra4Bu9KXSIboybaUg_V4pSYHq2rx TsCYOMcSEFMB_c3ViCTW5g9s6Ut8- Received: from [66.228.162.52] by web142802.mail.bf1.yahoo.com via HTTP; Fri, 14 Mar 2014 14:52:27 PDT X-Rocket-MIMEInfo: 002.001, UXVvdGluZyBoZXJlLCBpbiB0aGUgaG9wZSB0aGF0IGl0IHBpcXVlcyBzb21lb25lJ3MgaW50ZXJlc3QuIMKgTmV3IHByb3Bvc2VkIGxhbmd1YWdlIGlzOgoKIsKgQ2xpZW50IHJlc3BvbnNlcyBhcmUgYSBHUzLCoFtSRkM1ODAxXcKgaGVhZGVyIGZvbGxvd2VkIGJ5IGEga2V5L3ZhbHVlIHBhaXIgc2VxdWVuY2UsIG9yIG1heSBiZSBlbXB0eS4gVGhlIGdzMi1oZWFkZXIgaXMgZGVmaW5lZCBoZXJlIGZvciBjb21wYXRpYmlsaXR5IHdpdGggR1MyIGlmIGEgR1MyIG1lY2hhbmlzbSBpcyBmb3JtYWxseSBkZWZpbmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.178.641 References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> Message-ID: <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Fri, 14 Mar 2014 14:52:27 -0700 (PDT) From: Bill Mills To: Bill Mills , Ryan Troll , Bill Mills In-Reply-To: <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-696907514-1394833947=:5753" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/BTVPGFuZliF6l2190lHdgplNcps Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Pending draft 15 Re: sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 21:52:38 -0000 --1397251415-696907514-1394833947=:5753 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Quoting here, in the hope that it piques someone's interest. =A0New propose= d language is:=0A=0A"=A0Client responses are a GS2=A0[RFC5801]=A0header fol= lowed by a key/value pair sequence, or may be empty. The gs2-header is defi= ned here for compatibility with GS2 if a GS2 mechanism is formally defined,= but this document does not define one. These key/value pairs carry the equ= ivalent values from an HTTP context in order to be able to complete an OAut= h style HTTP authorization. Unknown key/value pairs MUST be ignored by the = server. The ABNF=A0[RFC5234]=A0syntax is:kvsep =3D %x01 key = =3D 1*(ALPHA / ",") value =3D *(VCHAR / SP / HTAB / CR / LF )= kvpair =3D key "=3D" value kvsep=0A;;gs2-header =3D See RFC 58= 01 client_resp =3D (gs2-header kvsep 0*kvpair kvsep) / kvsep=A0=0AThe GS= 2 header MUST inclde the user name asociated with the resource being access= ed, the "authzid"."=0A=0AHoping to wrap this up soon.=0A=0AThanks,=0A=0A-bi= ll=0A=0A=0A=0A=0AOn Wednesday, March 12, 2014 11:56 AM, Bill Mills wrote:=0A =0APlease take a look at the attached, specifica= lly 3.1, and see if it captures what's been discussed.=0A=0AThanks,=0A=0A-b= ill=0A=0A=0A=0AOn Thursday, March 6, 2014 3:38 PM, Ryan Troll wrote:=0A =0AApologies for the delay in responding.=0A=0AI underst= and this was discussed in today's meeting; and we're going to have a follow= -up to discuss further - very reasonable.=0A=0ATo answer Bill's original qu= estion: user=3D or a=3D --> Either works for us. =A0If one has better impli= cations than the other, we'll use it.=0A=0A-R=0A=0A=0A=0A=0AOn Tue, Mar 4, = 2014 at 7:55 AM, Bill Mills wrote:=0A=0A=0A>=0A>It i= s not used as a SASL identity.=A0 Quoting from -03 and -14 in progress:=0A>= =0A>"user (REQUIRED):=0A>=0A>=0A>Contains the user name being =0Aauthentica= ted. The server MAY use this as a routing or database lookup =0Ahint. The= server MUST NOT use this as authoritative, the user name MUST be asserted = by the OAuth credential."=0A>=A0=0A>Also, looking at the Google API docs fo= r XOAUTH2, they implemented based on the -03 spec and have the "user=3D$use= rname" syntax.=A0 See https://developers.google.com/gmail/xoauth2_protocol = =0A>=0A>Based on Google's server API and the extant clients they have I'd l= ike to ask for a consensus call on the following:=0A>=0A>1) Add the -03 "us= er" kvpair back into the spec.=0A>=0A>a) YES or b) NO.=A0 =0A>=0A>2) Should= we include a GS2 header"=0A>=0A>a) No, let's wait for the GS2 update that = deals with things that lack mutual auth and then write a spec that defines = a GS2 header for SASL+OAUTH.=0A>=0A>b) Change the definition of "key" in kv= pair to 1*(ALPHA / ",").=A0 This makes a GS2 header followed by a ^A (i.e.= =0A "n,a=3Duser@example.com^A") a valid kvpair which would be ignored by se= rvers that don't understand it. =0A>=0A>c) Define a stub OPTIONAL GS2 heade= r explicitly.=0A>=0A>d) Include a fully=0A defined GS2 header (language fro= m draft -10).=0A>=0A>=0A>My own feedback is 1: YES, 2: a or b.=0A>=0A>=0A>-= bill=0A>=0A>=0A>=0A>--------------------------------=0A>William J. Mills=0A= >"Paranoid" MUX Yahoo!=0A>=0A>=0A>=0A>=0A>=0A>=0A>On Tuesday, March 4, 2014= 12:06 AM, Sam Hartman wrote:=0A> =0A>t's discuss T= hursday.=0A>I'd like to understand what the user=3D value signifies and whe= ther it's=0A>actually a SASL authorization identifier.=0A>=0A>I'd like to u= nderstand whether there's value in an unprotected SASL=0A>authorization ide= ntifier.=0A>=0A>=0A>=0A>=0A>=0A>=0A>_______________________________________= ________=0A>Kitten mailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/= mailman/listinfo/kitten=0A>=0A>=0A=0A=0A___________________________________= ____________=0AKitten mailing list=0AKitten@ietf.org=0Ahttps://www.ietf.org= /mailman/listinfo/kitten=0A=0A=0A=0A_______________________________________= ________=0AKitten mailing list=0AKitten@ietf.org=0Ahttps://www.ietf.org/mai= lman/listinfo/kitten --1397251415-696907514-1394833947=:5753 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Quoting here, in the hope that it piques someone's= interest.  New proposed language is:

" Client responses are a = GS2 [R= FC5801] header followed by a key/value = pair sequence, or may be empty. The gs2-header is defined here for compatib= ility with GS2 if a GS2 mechanism is formally defined, but this document do= es not define one. These key/value pairs carry the equivalent values from a= n HTTP context in order to be able to complete an OAuth style HTTP authoriz= ation. Unknown key/value pairs MUST be ignored by the server. The ABNF [R= FC5234] syntax is:
            =0A  kvse=
p          =3D %x01=0A  key            =3D 1*(ALPHA / ",")=0A  value       =
   =3D *(VCHAR / SP / HTAB / CR / LF )=0A  kvpair         =3D key "=3D" val=
ue kvsep=0A;;gs2-header     =3D See RFC 5801=0A  client_resp    =3D (gs2-he=
ader kvsep 0*kvpair kvsep) / kvsep 
The GS2 header MUST inclde the user name asociate= d with the resource being accessed, the "authzid"."

Hoping to wrap this up soon.

Thanks,
=

-bill



On Wednesday, Ma= rch 12, 2014 11:56 AM, Bill Mills <wmills_92105@yahoo.com> wrote:
=
<= div>
Please take a look at the = attached, specifically 3.1, and see if it captures what's been discussed.

Thanks,

-bill


<= div style=3D"font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial= , 'Lucida Grande', sans-serif; font-size: 12pt;">
On Thursday, March 6, 2014 3:38 PM, Ryan Troll <rtroll@googlers.com>= ; wrote:
Apologies for the delay in re= sponding.

I understand this was discussed= in today's meeting; and we're going to have a follow-up to discuss further= - very reasonable.

=0A
To answer Bi= ll's original question: user=3D or a=3D --> Either works for us.  I= f one has better implications than the other, we'll use it.

-R

=0A

=
On Tue, Mar 4, 2014 at 7:55 AM, Bil= l Mills <wmills@yahoo-inc.com> wrote:
=0A
=
=0A

=0A
It is not used as a SASL identity= .  Quoting from -03 and -14 in progress:
=0A<= /div>
"user (REQUIRED):

Contains the user name being = =0Aauthenticated. The server MAY use this as a routing or database lookup = =0Ahint. The server MUST NOT use this as authoritative, the user name MUST= =0A be asserted by the OAuth credential."
 
Also, looking at the Google API docs for XOAUTH2, they implemented ba= sed on the -03 spec and have the "user=3D$username" syntax.  See https://developers.google.com/gmail/xoau= th2_protocol
=0A
Based on Google's= server API and the extant clients they have I'd like to ask for a consensu= s call on the following:

1) Add the -0= 3 "user" kvpair back into the spec.
=0A
a) YES or b) NO. 

2) Should we = include a GS2 header"

a) No, let's wai= t for the GS2 update that deals with things that lack mutual auth and then = write a spec that defines a GS2 header for SASL+OAUTH.
= =0A
b) Change the definition of "key" in kvpair to 1*(ALP= HA / ",").  This makes a GS2 header followed by a ^A (i.e.=0A "n,a=3D<= a rel=3D"nofollow" shape=3D"rect" ymailto=3D"mailto:user@example.com" targe= t=3D"_blank" href=3D"mailto:user@example.com">user@example.com^A") a va= lid kvpair which would be ignored by servers that don't understand it.

c) Define a stub OPTIONAL GS2 header expl= icitly.
=0A
d) Include a fully=0A defin= ed GS2 header (language from draft -10).


My own feedback is 1: YES, 2: a or b.

-bill


=0A
--------------------------------
William J. M= ills
"Paranoid" MUX Yahoo!
=0A



=0A
On= =0A Tuesday, March 4, 2014 12:06 AM, Sam Hartman <hartmans-ietf@mit.edu> wrote:
t's discuss Thursday.
=0AI'd like to understand what the user=3D value signifies and whether it= 's
actually a SASL authorization identifier.

I'd like to understand whether there's value in an= unprotected SASL
=0Aauthorization identifier.





<= /div>

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


_______________________________________________
Kitte= n mailing list
Kitten@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/kitten

=

___________________= ____________________________
Kitten mailing list
Kitten@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/kitten


--1397251415-696907514-1394833947=:5753-- From nobody Sun Mar 16 16:55:09 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553F61A0210 for ; Sun, 16 Mar 2014 16:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrR86-TmuWwf for ; Sun, 16 Mar 2014 16:55:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 52DBC1A020B for ; Sun, 16 Mar 2014 16:55:03 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2GNssMR029335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 16 Mar 2014 23:54:55 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2GNssLt012467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 16 Mar 2014 23:54:54 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2GNssiK003256 for ; Sun, 16 Mar 2014 23:54:54 GMT Received: from [10.159.120.127] (/10.159.120.127) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 16 Mar 2014 16:54:53 -0700 Message-ID: <532639C6.40603@oracle.com> Date: Sun, 16 Mar 2014 17:54:46 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140222 Thunderbird/17.0.6 MIME-Version: 1.0 To: "kitten@ietf.org" References: <5319DE8B.1030202@att.com> <20140312162849.152e924b@latte.josefsson.org> In-Reply-To: <20140312162849.152e924b@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/oLF84qjPB7bq4dMgs_jotcuSgPE Subject: Re: [kitten] [IANA #748877] please review SASL-SCRAM-256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 23:55:07 -0000 On 03/12/14 09:28 AM, Simon Josefsson wrote: > Dear all, > > We have received a request to register the SCRAM-SHA-256 and > SCRAM-SHA-256-PLUS mechanism. According to my understanding of what RFC > 5802 section 10 says, the registration process is "IETF Review" > http://tools.ietf.org/html/rfc5226#page-11 which requires an RFC, but I > may be mistaken. Anyway, suggestions on how to deal with the > registration request is appreciated. Typing as an individual... the mechanism name seems to be very much in keeping with guidance provided in 5802 section 4. > Having a SCRAM with SHA-256 seems like a fairly non-controversial > thing to me. There are interop aspects though, and the utility of > defining a lot of variants could be debated. I would like to see a > GSS-API OID registered at the same time for any new SCRAM-SHA-* family > member, but it seems we forgot to write a policy to make sure that > happens. Other thoughts? I don't envision that there will be a proliferation of SCRAM-SHA-* mechanism variations. Certainly if we can keep to a small set of output sizes per algorithm. Shawn. -- >> Dear Simon, >> >> IANA has received a request from Tony Hansen (tony@att.com) for two >> new registrations in the SASL Mechanisms registry at >> http://www.iana.org/assignments/sasl-mechanisms. >> >> Please let us know when the two-week review period onsasl@ietf.org >> is complete. >> >> thanks, >> >> Amanda Baber >> IANA Request Specialist >> ICANN >> >> === >> >> IANA, please register the following: >> >> To:iana@iana.org >> Subject: Registration of a new SASL mechanism SCRAM-SHA-256 >> >> SASL mechanism name (or prefix for the family): SCRAM-SHA-256 >> Security considerations: Section 7 of [RFC5802] >> Published specification (optional, recommended): [RFC5802] >> Person & email address to contact for further information: >> IETF SASL WG >> Intended usage: COMMON >> Owner/Change controller: IESG >> Note: >> >> To:iana@iana.org >> Subject: Registration of a new SASL mechanism SCRAM-SHA-256-PLUS >> >> SASL mechanism name (or prefix for the family): SCRAM-SHA-256-PLUS >> Security considerations: Section 7 of [RFC5802] >> Published specification (optional, recommended): [RFC5802] >> Person & email address to contact for further information: >> IETF SASL WG >> Intended usage: COMMON >> Owner/Change controller: IESG >> Note: >> > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > From nobody Mon Mar 17 10:14:54 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864081A043A for ; Mon, 17 Mar 2014 10:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN-BgmiuUFmq for ; Mon, 17 Mar 2014 10:14:50 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id F1E1F1A0432 for ; Mon, 17 Mar 2014 10:14:49 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id j15so5584043qaq.2 for ; Mon, 17 Mar 2014 10:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zhZod8e5VByFFIOQE1lmfbC/0t3ejwaAJw3U8e8CBls=; b=VOlyf5E2atOIQJr+F3v8ODQWG7vN3WMXKvqgqwj/9va7f4ZdTfU53FCIwpwgLyde0p i4Lp+2w/7icW1fKi9jc4HItVXKaDMLQijXe5A5p1QbS886973eKhLE3umnzS5C7hLuYn U2M7VQ+ccP+VjnFpQmGf8B1fEn9q6Kp+fgRj4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zhZod8e5VByFFIOQE1lmfbC/0t3ejwaAJw3U8e8CBls=; b=FkrweeUA89ick199BD0iFRGY4povZ63v3DFP9T3ez13cwRnHw2oHK1sh6F/8P0lCYY JRtZw1hvN040e7sG6g7Z405k73B++fauMlO+peLLXnME1O4PCHnJO3r/u2xsgzPmfz2o kq+6ecUnw7LOrbHeihtpqDfSMLakh1EMtfgyCUb8DfXZYpPVDqhEe5Cyp6pPH8sFssBr vUWUd56mVZGFmRVNI6X7Iz7QCCIz4GvMRrbRK/YtSQHdnVUSRuUMiLwHzHTQXQdGg1Fe zoRJ+cEtUN3+kcu0gWd+JVUtsllLasCOy7Pxm6uy0sK9gHSP5Ct4GFsShqgpl1ffjAZJ Jhzw== X-Gm-Message-State: ALoCoQlul5tpY+W5ZmmrZDvBSkOcZoMaoDcn+vzc1HZrDLpdaiqs9OULgPTLG+mMayMDzF6mKT4klJLqb63evXujRYf75XGWJuU02VEkDxMX1Qfhkkug5fHsQIx5/mqrRYmS9FhfaGSGAPFt1AG7WNc854GPRby+9x+zdzIb3Z7qq4lar43X1qh62+bgx27nL09NcorKudjQ MIME-Version: 1.0 X-Received: by 10.224.115.68 with SMTP id h4mr29510696qaq.35.1395076481461; Mon, 17 Mar 2014 10:14:41 -0700 (PDT) Received: by 10.229.205.197 with HTTP; Mon, 17 Mar 2014 10:14:41 -0700 (PDT) In-Reply-To: <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Mon, 17 Mar 2014 10:14:41 -0700 Message-ID: From: Ryan Troll To: Bill Mills Content-Type: multipart/alternative; boundary=047d7bdc7fc61cc83a04f4d08e92 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/DN9oLEtJZD0lAPDDCbP6-u2M2iw Cc: "kitten@ietf.org" , Bill Mills , Sam Hartman Subject: Re: [kitten] Pending draft 15 Re: sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 17:14:52 -0000 --047d7bdc7fc61cc83a04f4d08e92 Content-Type: text/plain; charset=UTF-8 Seems reasonable. The last sentence contains two typos. -R On Fri, Mar 14, 2014 at 2:52 PM, Bill Mills wrote: > Quoting here, in the hope that it piques someone's interest. New proposed > language is: > > " Client responses are a GS2 [RFC5801] > header followed by a key/value pair sequence, or may be empty. The > gs2-header is defined here for compatibility with GS2 if a GS2 mechanism is > formally defined, but this document does not define one. These key/value > pairs carry the equivalent values from an HTTP context in order to be able > to complete an OAuth style HTTP authorization. Unknown key/value pairs MUST > be ignored by the server. The ABNF [RFC5234] > syntax is: > > > kvsep = %x01 > key = 1*(ALPHA / ",") > value = *(VCHAR / SP / HTAB / CR / LF ) > kvpair = key "=" value kvsep > ;;gs2-header = See RFC 5801 > client_resp = (gs2-header kvsep 0*kvpair kvsep) / kvsep > > The GS2 header MUST inclde the user name asociated with the resource being > accessed, the "authzid"." > > Hoping to wrap this up soon. > > Thanks, > > -bill > > > > On Wednesday, March 12, 2014 11:56 AM, Bill Mills < > wmills_92105@yahoo.com> wrote: > Please take a look at the attached, specifically 3.1, and see if it > captures what's been discussed. > > Thanks, > > -bill > > > On Thursday, March 6, 2014 3:38 PM, Ryan Troll > wrote: > Apologies for the delay in responding. > > I understand this was discussed in today's meeting; and we're going to > have a follow-up to discuss further - very reasonable. > > To answer Bill's original question: user= or a= --> Either works for us. > If one has better implications than the other, we'll use it. > > -R > > > > On Tue, Mar 4, 2014 at 7:55 AM, Bill Mills wrote: > > > It is not used as a SASL identity. Quoting from -03 and -14 in progress: > "user (REQUIRED): > Contains the user name being authenticated. The server MAY use this as a > routing or database lookup hint. The server MUST NOT use this as > authoritative, the user name MUST be asserted by the OAuth credential." > > Also, looking at the Google API docs for XOAUTH2, they implemented based > on the -03 spec and have the "user=$username" syntax. See > https://developers.google.com/gmail/xoauth2_protocol > > Based on Google's server API and the extant clients they have I'd like to > ask for a consensus call on the following: > > 1) Add the -03 "user" kvpair back into the spec. > > a) YES or b) NO. > > 2) Should we include a GS2 header" > > a) No, let's wait for the GS2 update that deals with things that lack > mutual auth and then write a spec that defines a GS2 header for SASL+OAUTH. > > b) Change the definition of "key" in kvpair to 1*(ALPHA / ","). This > makes a GS2 header followed by a ^A (i.e. "n,a=user@example.com^A") a > valid kvpair which would be ignored by servers that don't understand it. > > c) Define a stub OPTIONAL GS2 header explicitly. > > d) Include a fully defined GS2 header (language from draft -10). > > > My own feedback is 1: YES, 2: a or b. > > -bill > > > -------------------------------- > William J. Mills > "Paranoid" MUX Yahoo! > > > > On Tuesday, March 4, 2014 12:06 AM, Sam Hartman > wrote: > t's discuss Thursday. > I'd like to understand what the user= value signifies and whether it's > actually a SASL authorization identifier. > > I'd like to understand whether there's value in an unprotected SASL > authorization identifier. > > > > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > > --047d7bdc7fc61cc83a04f4d08e92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Seems reasonable.

The last sentence con= tains two typos.

-R


On Fri, Mar 14, 2014 at 2:52 PM,= Bill Mills <wmills_92105@yahoo.com> wrote:
Quoting here, in the hope that it piques someone's interest. =C2= =A0New proposed language is:

"=C2=A0Client responses are a GS2=C2=A0[RFC5801]=C2=A0header followed by= a key/value pair sequence, or may be empty. The gs2-header is defined here= for compatibility with GS2 if a GS2 mechanism is formally defined, but thi= s document does not define one. These key/value pairs carry the equivalent = values from an HTTP context in order to be able to complete an OAuth style = HTTP authorization. Unknown key/value pairs MUST be ignored by the server. = The ABNF=C2=A0[RFC5234]=C2=A0syntax is:
           =20
  kvsep          =3D %x01
  key            =3D 1*(ALPHA / ",")
  value          =3D *(VCHAR / SP / HTAB / CR / LF )
  kvpair         =3D key "=3D" value kvsep
;;gs2-header     =3D See RFC 5801
  client_resp    =3D (gs2-header kvsep 0*kvpair kvsep) / kvsep=C2=A0
<= div style=3D"margin-left:2em;margin-right:2em">
The GS2 header MUST inclde the user name asociated with the resource bei= ng accessed, the "authzid"."

Hoping to wrap this up soon.

Thanks,

-bill


On Wednesday, March 12, 2014 11:56= AM, Bill Mills <wmills_92105@yahoo.com> wrote:
Please take a look at the attached, specifically 3.1, and see if it captures what's been discussed.=

Thanks,

-bill


On Thursday, March 6, 2014 3:38 PM= , Ryan Troll <r= troll@googlers.com> wrote:
Apologies for the delay in responding.

I = understand this was discussed in today's meeting; and we're going t= o have a follow-up to discuss further - very reasonable.

To answer Bill's original question: user=3D or a=3D --> Either = works for us. =C2=A0If one has better implications than the other, we'l= l use it.

-R



On Tue, Mar 4, 2014 at 7:55 AM, = Bill Mills <wmills@yahoo-inc.com>= ; wrote:
<= div style=3D"font-family:'Courier New',courier,monaco,monospace,san= s-serif;font-size:14pt">

It is not used as a SASL identity.=C2=A0 Quoting from = -03 and -14 in progress:
"user (REQUIRED):

Contains the user name= being=20 authenticated. The server MAY use this as a routing or database lookup=20 hint. The server MUST NOT use this as authoritative, the user name MUST be asserted by the OAuth credential."
=C2=A0
Also, looking at the Google API docs for XOAUTH2, they implemente= d based on the -03 spec and have the "user=3D$username" syntax.= =C2=A0 See https://developers.googl= e.com/gmail/xoauth2_protocol

Based on Google's server API and the extant clients = they have I'd like to ask for a consensus call on the following:

1) Add the -03 "user" kvpair back = into the spec.

a) YES or b) NO.=C2=A0

2) Should we include a GS2 header"

a) No, let's wait for the GS2 update that deals with things that= lack mutual auth and then write a spec that defines a GS2 header for SASL+= OAUTH.

b) Change the definition of "key" in kvpair to= 1*(ALPHA / ",").=C2=A0 This makes a GS2 header followed by a ^A = (i.e. "n,a=3Duser@example.com^A") a valid kvpair which = would be ignored by servers that don't understand it.

c) Define a stub OPTIONAL GS2 header explicitly.

d) Include a fully defined GS2 header (language from draft -10).


My own feedback is 1: YES, 2: a or b.

-bill


----------------------= ----------
William J. Mills
"Paran= oid" MUX Yahoo!



On Tuesday, March 4, 2014 12:06 AM, Sam Hartman <hartmans-= ietf@mit.edu> wrote:
t's= discuss Thursday.
I'd like to understand what the user=3D value signifies and whether it&= #39;s
actually a SASL authorization identifier.

I'd like to understand whether there's= value in an unprotected SASL
authorization identifier.


<= br clear=3D"none">


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


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


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



--047d7bdc7fc61cc83a04f4d08e92-- From nobody Mon Mar 17 10:19:24 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349691A045C for ; Mon, 17 Mar 2014 10:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.454 X-Spam-Level: X-Spam-Status: No, score=0.454 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBZ1uIze7qFb for ; Mon, 17 Mar 2014 10:19:18 -0700 (PDT) Received: from nm41.bullet.mail.bf1.yahoo.com (nm41.bullet.mail.bf1.yahoo.com [216.109.114.57]) by ietfa.amsl.com (Postfix) with ESMTP id F40A21A045A for ; Mon, 17 Mar 2014 10:19:17 -0700 (PDT) Received: from [66.196.81.174] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 17:19:09 -0000 Received: from [98.139.212.224] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 17:19:09 -0000 Received: from [127.0.0.1] by omp1033.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 17:19:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 796904.70079.bm@omp1033.mail.bf1.yahoo.com Received: (qmail 29607 invoked by uid 60001); 17 Mar 2014 17:19:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395076749; bh=3rai32R33N9yb9lJLFBMTmaPIuBdx4oqYEq0HhFTg6o=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=avHgcSJ3ACIkf9BMcREZ7IG4Ew1Ev0gREIS+w8E1jGfnp2yZE6YfOpy94Qd96GpPK5ZzhHBa9p37lhNagLd5V4MPhks/RqnVYMxlgwFVnDNinM63lqFSki+0HDWZ2/J1SacAJs/ANvm9+pLKpb3uWD2eB4FyMaltOPu/jt56L+s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kklOds/qeD/2sV8ERjQkI1I5ZOrmsS+6Xn3/z7SOjvZXpZYo7SP3hPgz4eb+WjC8FEiHSXLjj8mhvFTh6w6YF6n09D4bi84/daQLMtqK5omFG5vnel3TkM3THMRTdcpcVjQiGQ3xoqEgNMoiHB6eXb8peBoFMa2ss93AV/45Tbg=; X-YMail-OSG: 6Dx4xyAVM1nVNfDucfJSDnvDXPthDZWnfqSKyHZeP94gp4V Y0V2eNlaA_uBfP6Yj22eLTlP1QO_vmqaez0LC.kf39K0Voo27FHoNsko8hCy dwy.Ir3Gy48X8IBfB0nO2OPZiE.rLcv72Jw_3Ok6MHDaLMvDGuOCpw78eEDa d2FWdsjM1jg19qw79KktA27ugY9399Ao_ZQWX1S7YbjU4NAx6htwQosvZskn EBdXgKQ9QsvhD03Yd5kHWHpTyRISSz3bjrxCip5x1gfOKoS4xMmaMLvmxsLP ymLTUf8zYKefG5i9aLXkS9qCxc0sKCZsKomOuypiDIMByl4lKhpsiYMT0RfD WUOfICRmmwNhZx2aLJwKgwJmKnQgSQW3KuqQNodjMRs2l1DGZde2uaSXhBU8 bcQ_KvM2BDE7K7RcggjKbkcQTh1wNUANewMuTEQALr6t4FurG9PX1g0TKCJq 4A2jl2jZmJv.Ma.zgNqS_Mvhp439zZp7LtSvXhpleOXVLBmKUSj2sEYN9a7b 34y5Bx9uZ2THdn.uhOsLThCBy2XbTtWzWQsexlbBXUpItWD5SeUAZWQsjOfP MZ8c16YY1zsYm7j3geHofFBG3FQDEW3tS2nxaq2jz8UcK1HuleCuevdSwZyR g3C9lGPfEAE1TEmd7QKWBVvUYphcJZlWxRFL1LSdgxCbG_9QWjTlGq160Pzy PVl0b3jZJyD8js6CWDWUZlhgIEOvpByRKlw2luyRN_5CIiVr0w3.X7O0XVag wJKSCdj3dFKn.WLP6dHdosWAEq.SS1d_SvY9zKZkXbs.uHkyeVl3hJ7Ofp96 wj0TyIRG3NokDF7zQonHd3.c- Received: from [99.31.212.42] by web142806.mail.bf1.yahoo.com via HTTP; Mon, 17 Mar 2014 10:19:09 PDT X-Rocket-MIMEInfo: 002.001, Rml4ZWQuIFRoYW5rcy4KCgoKT24gTW9uZGF5LCBNYXJjaCAxNywgMjAxNCAxMDoxNCBBTSwgUnlhbiBUcm9sbCA8cnRyb2xsQGdvb2dsZXJzLmNvbT4gd3JvdGU6CiAKU2VlbXMgcmVhc29uYWJsZS4KClRoZSBsYXN0IHNlbnRlbmNlIGNvbnRhaW5zIHR3byB0eXBvcy4KCi1SCgoKCk9uIEZyaSwgTWFyIDE0LCAyMDE0IGF0IDI6NTIgUE0sIEJpbGwgTWlsbHMgPHdtaWxsc185MjEwNUB5YWhvby5jb20.IHdyb3RlOgoKUXVvdGluZyBoZXJlLCBpbiB0aGUgaG9wZSB0aGF0IGl0IHBpcXVlcyBzb21lb25lJ3MgaW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.178.641 References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> Message-ID: <1395076749.76185.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Mon, 17 Mar 2014 10:19:09 -0700 (PDT) From: Bill Mills To: Ryan Troll In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="515012262-276450129-1395076749=:76185" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/D-XxlB5HuVNh3g3H2KgiAi6psEU Cc: "kitten@ietf.org" , Bill Mills , Sam Hartman Subject: Re: [kitten] Pending draft 15 Re: sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 17:19:20 -0000 --515012262-276450129-1395076749=:76185 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Fixed. Thanks.=0A=0A=0A=0AOn Monday, March 17, 2014 10:14 AM, Ryan Troll wrote:=0A =0ASeems reasonable.=0A=0AThe last sentence c= ontains two typos.=0A=0A-R=0A=0A=0A=0AOn Fri, Mar 14, 2014 at 2:52 PM, Bill= Mills wrote:=0A=0AQuoting here, in the hope that = it piques someone's interest. =A0New proposed language is:=0A>=0A>=0A>"=A0C= lient responses are a GS2=A0[RFC5801]=A0header followed by a key/value pair= sequence, or may be empty. The gs2-header is defined here for compatibilit= y with GS2 if a GS2 mechanism is formally defined, but this document does n= ot define one. These key/value pairs carry the equivalent values from an HT= TP context in order to be able to complete an OAuth style HTTP authorizatio= n. Unknown key/value pairs MUST be ignored by the server. The ABNF=A0[RFC52= 34]=A0syntax is:=0A>kvsep =3D %x01 key =3D 1*(ALPHA / "= ,") value =3D *(VCHAR / SP / HTAB / CR / LF ) kvpair =3D k= ey "=3D" value kvsep=0A;;gs2-header =3D See RFC 5801 client_resp =3D= (gs2-header kvsep 0*kvpair kvsep) / kvsep=A0=0A>The GS2 header MUST inclde= the user name asociated with the resource being accessed, the "authzid"."= =0A>=0A>=0A>Hoping to wrap this up soon.=0A>=0A>=0A>Thanks,=0A>=0A>=0A>-bil= l=0A>=0A>=0A>=0A>=0A>=0A>On Wednesday, March 12, 2014 11:56 AM, Bill Mills = wrote:=0A> =0A>Please take a look at the attached,= specifically 3.1, and see if it captures what's been discussed.=0A>=0A>=0A= >Thanks,=0A>=0A>=0A>-bill=0A>=0A>=0A>=0A>On Thursday, March 6, 2014 3:38 PM= , Ryan Troll wrote:=0A> =0A>Apologies for the delay i= n responding.=0A>=0A>=0A>I understand this was discussed in today's meeting= ; and we're going to have a follow-up to discuss further - very reasonable.= =0A>=0A>=0A>To answer Bill's original question: user=3D or a=3D --> Either = works for us. =A0If one has better implications than the other, we'll use i= t.=0A>=0A>=0A>-R=0A>=0A>=0A>=0A>=0A>=0A>On Tue, Mar 4, 2014 at 7:55 AM, Bil= l Mills wrote:=0A>=0A>=0A>>=0A>>It is not used as a = SASL identity.=A0 Quoting from -03 and -14 in progress:=0A>>=0A>>"user (REQ= UIRED):=0A>>=0A>>=0A>>Contains the user name being =0Aauthenticated. The s= erver MAY use this as a routing or database lookup =0Ahint. The server MUS= T NOT use this as authoritative, the user name MUST be asserted by the OAut= h credential."=0A>>=A0=0A>>Also, looking at the Google API docs for XOAUTH2= , they implemented based on the -03 spec and have the "user=3D$username" sy= ntax.=A0 See https://developers.google.com/gmail/xoauth2_protocol =0A>>=0A>= >Based on Google's server API and the extant clients they have I'd like to = ask for a consensus call on the following:=0A>>=0A>>1) Add the -03 "user" k= vpair back into the spec.=0A>>=0A>>a) YES or b) NO.=A0 =0A>>=0A>>2) Should = we include a GS2 header"=0A>>=0A>>a) No, let's wait for the GS2 update that= deals with things that lack mutual auth and then write a spec that defines= a GS2 header for SASL+OAUTH.=0A>>=0A>>b) Change the definition of "key" in= kvpair to 1*(ALPHA / ",").=A0 This makes a GS2 header followed by a ^A (i.= e.=0A "n,a=3Duser@example.com^A") a valid kvpair which would be ignored by = servers that don't understand it. =0A>>=0A>>c) Define a stub OPTIONAL GS2 h= eader explicitly.=0A>>=0A>>d) Include a fully=0A defined GS2 header (langua= ge from draft -10).=0A>>=0A>>=0A>>My own feedback is 1: YES, 2: a or b.=0A>= >=0A>>=0A>>-bill=0A>>=0A>>=0A>>=0A>>--------------------------------=0A>>Wi= lliam J. Mills=0A>>"Paranoid" MUX Yahoo!=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>= On Tuesday, March 4, 2014 12:06 AM, Sam Hartman wro= te:=0A>> =0A>>t's discuss Thursday.=0A>>I'd like to understand what the use= r=3D value signifies and whether it's=0A>>actually a SASL authorization ide= ntifier.=0A>>=0A>>I'd like to understand whether there's value in an unprot= ected SASL=0A>>authorization identifier.=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>= _______________________________________________=0A>>Kitten mailing list=0A>= >Kitten@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/kitten=0A>>=0A>>= =0A>=0A>=0A>_______________________________________________=0A>Kitten maili= ng list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/listinfo/kitten= =0A>=0A>=0A>=0A>_______________________________________________=0A>Kitten m= ailing list=0A>Kitten@ietf.org=0A>https://www.ietf.org/mailman/listinfo/kit= ten=0A>=0A>=0A> --515012262-276450129-1395076749=:76185 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Fixed. Thanks.


On Monday, March 17, 2014 10:1= 4 AM, Ryan Troll <rtroll@googlers.com> wrote:
Seems reasonable.

The last sentence cont= ains two typos.

-R


<= div class=3D"yiv7505174434gmail_quote">On Fri, Mar 14, 2014 at 2:52 PM, Bil= l Mills <wmills_92105@yahoo.com> wrote:
=0A
=0AQuoting here, in the hope that = it piques someone's interest.  New proposed language is:
<= div style=3D"font-style: normal; font-size: 16px; background-color: transpa= rent; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Luci= da Grande', sans-serif;">=0A
" Client responses are a GS2 [RFC5801] header followed by a key/value pair sequence, or may be empty. T= he gs2-header is defined here for compatibility with GS2 if a GS2 mechanism is formally defined, but this do= cument does not define one. These key/value pairs carry the equivalent valu= es from an HTTP context in order to be able to complete an OAuth style HTTP= authorization. Unknown key/value pairs MUST be ignored by the server. The = ABNF [RFC5234] = syntax is:
=0A
            =0A  kvsep          =3D %x01=0A  k=
ey            =3D 1*(ALPHA / ",")=0A  value          =3D *(VCHAR / SP / HTA=
B / CR / LF )=0A  kvpair         =3D key "=3D" value kvsep=0A;;gs2-header  =
   =3D See RFC 5801=0A  client_resp    =3D (gs2-header kvsep 0*kvpair kvsep=
) / kvsep 
=0AThe GS2 header MUST inclde the user= name asociated with the resource being accessed, the "authzid"."
=0A

= =0AHoping to wrap this up soon.
=0A
T= hanks,
=0A

=0A-bill
=0A
On Wednesday, March 12, 201= 4 11:56 AM, Bill Mills <wmills_92105@yahoo.com> wrote:
=
= =0A
Please take a look at the attached,=0A specifically 3.1, and = see if it captures what's been discussed.
=0A
Thanks,
=0A

=0A-bill


=0A
On Thursday, Ma= rch 6, 2014 3:38 PM, Ryan Troll <rtroll@googlers.com> wrote:
=
=0AApologies for the delay in resp= onding.

I understand this was discussed i= n today's meeting; and we're going to have a follow-up to discuss further -= very reasonable.

=0A
=0A
To answer B= ill's original question: user=3D or a=3D --> Either works for us.  = If one has better implications than the other, we'll use it.

-R

=0A
=0A

On Tue, Mar 4, 2014 at 7:5= 5 AM, Bill Mills <wmills@yahoo-inc.com> wrote:
=0A
=0A
=0A=0A
=0A
=
=0A
It is not used as a SA= SL identity.  Quoting from -03 and -14 in progress:
= =0A=0A
"user (REQUIRED):

Contains the user n= ame being =0Aauthenticated. The server MAY use this as a routing or databa= se lookup =0Ahint. The server MUST NOT use this as authoritative, the user= name MUST=0A be asserted by the OAuth credential."
 Also, looking at the Google API docs for XOAUTH2, they impl= emented based on the -03 spec and have the "user=3D$username" syntax. = See https://developers.google.com/= gmail/xoauth2_protocol
=0A=0A
Base= d on Google's server API and the extant clients they have I'd like to ask f= or a consensus call on the following:

= 1) Add the -03 "user" kvpair back into the spec.
=0A=0Aa) YES or b) NO. 

2) Should we include a GS2 header"

= a) No, let's wait for the GS2 update that deals with things that lack mutua= l auth and then write a spec that defines a GS2 header for SASL+OAUTH.
=0A=0A
b) Change the definition of "key" in= kvpair to 1*(ALPHA / ",").  This makes a GS2 header followed by a ^A = (i.e.=0A "n,a=3Duser@example= .com^A") a valid kvpair which would be ignored by servers that don't un= derstand it.

=0Ac) Define a stub OPTI= ONAL GS2 header explicitly.
=0A
d) Incl= ude a fully=0A defined GS2 header (language from draft -10).


My own feedback is 1: YES, 2: a o= r b.

-bill


=0A=0A
--------------------------------
William J. Mills
"Paranoid" MUX Yahoo!
=0A=0A



=0A=0A
On=0A Tuesday, March 4, 2014 12:06 AM, Sam Hartm= an <hartmans-ie= tf@mit.edu> wrote:
t's discu= ss Thursday.
=0A=0AI'd like to understand what the user= =3D value signifies and whether it's
actually a SASL auth= orization identifier.

I'd like to unde= rstand whether there's value in an unprotected SASL
=0A= =0Aauthorization identifier.



=

<= /div>
=0A

______________________________= _________________
=0A=0AKitten mailing list
=0AKitten@ietf.org=0Ahttps://www.ietf.org/mai= lman/listinfo/kitten
=0A


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


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

<= /div>

<= /div>

--515012262-276450129-1395076749=:76185-- From nobody Mon Mar 17 13:14:03 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E161A045F for ; Mon, 17 Mar 2014 13:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0VdwdbDVA7i for ; Mon, 17 Mar 2014 13:14:00 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (agjbgdcfdbhd.dreamhost.com [69.163.253.173]) by ietfa.amsl.com (Postfix) with ESMTP id 96B921A02FC for ; Mon, 17 Mar 2014 13:14:00 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 88DF227BC069 for ; Mon, 17 Mar 2014 13:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=pDL0qspFR7C7p7KYSAz8 lV34SYQ=; b=gF4RM8bj/SN41fAOeBxok60xDKARUfF94+D8h48hBekpWI+m5peX X3G+1Ejp9zDBJTGBZCnv3QvZX1mJ7/n6AhQeFsVI/QyHn/Nf2Zk2p8KYM/wRJkX5 jjRtWi5WuasGK80vOkWe82uE1Rmt+74MZMxtZw5lRxKA3W/RoDYnm04= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 39E6D27BC065 for ; Mon, 17 Mar 2014 13:13:52 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hn9so2762043wib.4 for ; Mon, 17 Mar 2014 13:13:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PKWRTCvd4mp+2kHWn+lSlVt71Ghmjni/lR/PyPNsnU4=; b=Y4JG1BOpIZBpYJj59bgROG9nKErvVeo6xDbMw+r6sev4SD4HqQ1uFip9AA2ZyOD/Ib HS5AXiAj9o1opfJm4DBZ04fZRqQvtYSk9JMxZTUWJckKUQFk03j4aYNkcbGivm3k6nud rGNlCKNI0q+rIpeV3aPKPrytlBoif+Xus+svRi5mgaA1xT5w52CqEzMHDDtRQ9dvmmbb +Dzbu7vzYuciiwh3wJiln6wi8U/l0b6DlQw/CZlwfjDx8j0HxEazR4ylL9dFZBKN4vq4 5mAfn2Zbf+KsDgBzn9z8h3mh62FvZf46qFoufCZaUxTWLX/VL9G5XccqrnlsWBlfyhFU 1juw== MIME-Version: 1.0 X-Received: by 10.194.236.9 with SMTP id uq9mr20046680wjc.31.1395087230892; Mon, 17 Mar 2014 13:13:50 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Mon, 17 Mar 2014 13:13:50 -0700 (PDT) In-Reply-To: <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Mon, 17 Mar 2014 15:13:50 -0500 Message-ID: From: Nico Williams To: Bill Mills Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/6RofmRIyVuY_YHvYXkzWfwzWsl0 Cc: "kitten@ietf.org" , Bill Mills , Sam Hartman Subject: Re: [kitten] Pending draft 15 Re: sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 20:14:01 -0000 On Fri, Mar 14, 2014 at 4:52 PM, Bill Mills wrote: > Quoting here, in the hope that it piques someone's interest. New proposed > language is: > > " Client responses are a GS2 [RFC5801] header followed by a key/value pair > sequence, or may be empty. The gs2-header is defined here for compatibility > with GS2 if a GS2 mechanism is formally defined, but this document does not s/formally/eventually/ ? > define one. These key/value pairs carry the equivalent values from an HTTP > context in order to be able to complete an OAuth style HTTP authorization. > Unknown key/value pairs MUST be ignored by the server. The ABNF [RFC5234] > syntax is: > > > kvsep = %x01 > key = 1*(ALPHA / ",") > value = *(VCHAR / SP / HTAB / CR / LF ) > kvpair = key "=" value kvsep > ;;gs2-header = See RFC 5801 > client_resp = (gs2-header kvsep 0*kvpair kvsep) / kvsep > > The GS2 header MUST inclde the user name asociated with the resource being > accessed, the "authzid"." Hmm, MUST? SASL allows the app to not use an authzid if it doesn't want to. I understand that Google's OAuth use case requires an authzid, but it's not obvious to me that all OAuth use cases will. + the two typos Ryan noticed. Nico -- From nobody Mon Mar 17 13:32:11 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66F11A0200 for ; Mon, 17 Mar 2014 13:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5nZ8bggNmnL for ; Mon, 17 Mar 2014 13:32:07 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C64BD1A0223 for ; Mon, 17 Mar 2014 13:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2227; q=dns/txt; s=iport; t=1395088320; x=1396297920; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=k2B688x+v9EgxwmJJbodUWUOHSuUo36wv1tAQYBxUWI=; b=bllNJp5onct0xqDHieXzms56Od1e2/BNixD9fXtZcb8jtuAOKivkF9Op H9AhZs3+gPQUEI9Gjoryja5ofKe4ga/yPKhh/PD8IfAcqK0jkSG/2tA5L v1qgFWkjUy1ALNd3fVw1yPLiN7hP8Qrfme9x55J42OZY8j2CPXFW8bPAO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApULAN9aJ1OtJV2Y/2dsb2JhbABZgwY7V6kCBIIklmmBJBZ0giUBAQEEeRALGAkNGA8CNBIGAQwBBQIBAYdhAxHUABeMUIFlMwcSDYQZAQOJGjiLCIIFgWeMaIVIgW+BXYFTOQ X-IronPort-AV: E=Sophos;i="4.97,672,1389744000"; d="scan'208";a="310926844" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 17 Mar 2014 20:31:59 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2HKVxwP001625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Mar 2014 20:31:59 GMT Received: from MAMILLE2-M-T03K.local (10.89.11.106) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 17 Mar 2014 15:31:59 -0500 Message-ID: <53275BC1.50808@cisco.com> Date: Mon, 17 Mar 2014 14:32:01 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nico Williams , Bill Mills References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.89.11.106] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ACwHvPvZAQlOXzc15Ad4OCowzGU Cc: "kitten@ietf.org" , Bill Mills , Sam Hartman Subject: Re: [kitten] Pending draft 15 Re: sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 20:32:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 3/17/14, 2:13 PM, Nico Williams wrote: > On Fri, Mar 14, 2014 at 4:52 PM, Bill Mills > wrote: >> Quoting here, in the hope that it piques someone's interest. New >> proposed language is: >> >> " Client responses are a GS2 [RFC5801] header followed by a >> key/value pair sequence, or may be empty. The gs2-header is >> defined here for compatibility with GS2 if a GS2 mechanism is >> formally defined, but this document does not > > s/formally/eventually/ ? > >> define one. These key/value pairs carry the equivalent values >> from an HTTP context in order to be able to complete an OAuth >> style HTTP authorization. Unknown key/value pairs MUST be ignored >> by the server. The ABNF [RFC5234] syntax is: >> >> >> kvsep = %x01 key = 1*(ALPHA / ",") value >> = *(VCHAR / SP / HTAB / CR / LF ) kvpair = key "=" value >> kvsep ;;gs2-header = See RFC 5801 client_resp = >> (gs2-header kvsep 0*kvpair kvsep) / kvsep >> >> The GS2 header MUST inclde the user name asociated with the >> resource being accessed, the "authzid"." > > Hmm, MUST? SASL allows the app to not use an authzid if it > doesn't want to. I understand that Google's OAuth use case > requires an authzid, but it's not obvious to me that all OAuth use > cases will. > > + the two typos Ryan noticed. > I had the same pause as Nico. The implementation I was looking into did not require such information. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTJ1vBAAoJEDWi+S0W7cO1GbIH/jB145C0XvBjgngGNcVKs/Be 15zEdvojCNdDY0wHdjUXbwIbWs7LHA5ltO8NJhUVLU8E+Rmjl6ow+GvtlwqxCEFm IogrbU3uLEtB2liMGXBxLk2u4SbMV92e8g0WNQ7Qmo5Yws8urzkBFrcIG/Yu2gbe yUjvp8ai1E7o3y6xBZtzgZqIebF063mVMRGXJvIR5Z5DcgjQ0UMW0GLhGslYX6yB +pQ+faA2IsTDIVVBuOu9weP8mwgxU2tqtMcxe7ffWy1iPZrxk21pLvVmHL4sLHXO 4znnhsGApj+OzDojLPXh2jEdGOiO2goz2DWcV04rqpMSeMjLYK7jLw3N0YqMMZw= =W7/c -----END PGP SIGNATURE----- From nobody Mon Mar 17 14:15:27 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DBD1A056D for ; Mon, 17 Mar 2014 14:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.92 X-Spam-Level: X-Spam-Status: No, score=-16.92 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_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1F8ktLDZEKK for ; Mon, 17 Mar 2014 14:13:29 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEA51A04C1 for ; Mon, 17 Mar 2014 14:13:29 -0700 (PDT) Received: from BF1-EX10-CAHT01.y.corp.yahoo.com (bf1-ex10-caht01.corp.bf1.yahoo.com [10.74.209.56]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s2HLD4Wb001465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Mar 2014 14:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1395090785; bh=PuKWHAvc/AuG7qE80kwxruvUObVvH9zymwj0Gg33YiI=; h=References:Date:From:Reply-To:Subject:To:CC:In-Reply-To; b=eYcJzmwfvynaHl0Bx9NSu0WqJ2CM/rB4Rlv3aXJqD5zlojxZbM+ekehTDw61fDgos 7y7SCoKaW7hBYFzdbtuuMuPdHjWqg/0rb4yLJCiB1LM1pBphmQCH7ZyiLunrp7Nu+F MLEskQLOV34ImyMI3Q1YBHtbQP0stNT/QW8CsNdc= Received: from omp1059.mail.ne1.yahoo.com (98.138.89.245) by BF1-EX10-CAHT01.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 17 Mar 2014 17:13:03 -0400 Received: (qmail 9897 invoked by uid 1000); 17 Mar 2014 21:13:02 -0000 Received: (qmail 53181 invoked by uid 60001); 17 Mar 2014 21:13:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1395090782; bh=obVwktaXjX+qT7q6pHuYCJmd8002YFLvX2Ju0/bawsA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mzRLbLy7CQtiFAfQnNg/KQQ9/uOdPiF1QBCWmmcA8IxjtMOvO+HgerX8ZGx/gvx8hiWubOBBr+Ph7sx7DxNdKz2TBPc8UEycJMIRNIySM6MYZf3VyuYqGGfge86bX2cVESIEwwlkgztctwMQ0VSmVv7FF6VrI1fQJk/1m6iP+xk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=UUaWz8kppr8ci/Mm7vbDunCtBfCYeeaiZNR5RAf4feBcnI8V30Kh6qiJpBpUvJLQavRy1vpkegcDDLk2sn1/5SnjWYWXjYzEcdD/a6uUaXK00ovBatbrZdXa0nJWdZwNBW5bSFrAwVK85aO4q6mwU7TfCeMEW+WeYdcxIW4QFOo=; X-YMail-OSG: 80YNKh0VM1kWC.txTthN5aGmxQBpPfmywja2RziFg0geLYH 6oORFxoxChoCbvrt_AuCkbSDKOXjCkMBQBMl5yBpKcHZgakBy7jn1rGUx.ou XxSHFTBn32JxXoN8YyaX7KY5wzFog7rZsk1IoFKW8PiX09AjLpCpzy.yY_EZ UjmBSNkoOFAmldOaCovYb47NavkjyWZrC3EpGCTVqiCvgKGNQBv_etbxUAop HSDZuiJvkYQwdnoJK9JZbYW33lea.nkUK5Kc1RCdXvimjNprIul.of3ky8k4 8MLyG1hJY7eLDRhkZ6Vs- Received: from [66.228.162.52] by web125604.mail.ne1.yahoo.com via HTTP; Mon, 17 Mar 2014 14:13:02 PDT X-Rocket-MIMEInfo: 002.001, T0ssIHNvIGdpdmVuIEdvb2dsZSdzIGV4dGFudCBpbXBsZW1lbnRhdGlvbiwgaWYgd2UgY2hhbmdlIGl0IHRvIFNIT1VMRCB0aGUgTVVTVCBpcyBpbXBsaWNpdCBhbmQgdGhlIGRlIGZhY3RvIHN0YW5kYXJkIGFueXdheSBpZiB5b3Ugd2FudCBpdCB0byB3b3JrIHdpdGggR29vZ2xlLgoKCkknZCByYXRoZXIgaGF2ZSB0aGUgc3RhbmRhcmQgZXhwbGljaXRseSBkb2N1bWVudCB3aGF0IGlzIHdvcmtpbmcgbm93LCBidXQgSSBjYW4gbWFrZSB0aGUgY2hhbmdlIGVhc2lseS4KCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.178.641 References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53275BC1.50808@cisco.com> Message-ID: <1395090782.52393.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Mon, 17 Mar 2014 14:13:02 -0700 From: Bill Mills To: Matt Miller , Nico Williams , Bill Mills In-Reply-To: <53275BC1.50808@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-769530606-1395090782=:52393" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 090785001 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/CpcNFA_iADEHyFydin5pIu67Izs X-Mailman-Approved-At: Mon, 17 Mar 2014 14:15:25 -0700 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Pending draft 15 Re: sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 21:13:32 -0000 ---685807438-769530606-1395090782=:52393 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK, so given Google's extant implementation, if we change it to SHOULD the = MUST is implicit and the de facto standard anyway if you want it to work wi= th Google.=0A=0A=0AI'd rather have the standard explicitly document what is= working now, but I can make the change easily.=0A=0A=A0=0A-bill=0A=0A=0A= =0A--------------------------------=0AWilliam J. Mills=0A"Paranoid" MUX Yah= oo!=0A=0A=0A=0A=0A=0AOn Monday, March 17, 2014 1:32 PM, Matt Miller wrote:=0A =0A-----BEGIN PGP SIGNED MESSAGE-----=0AHash: SHA51= 2=0A=0AOn 3/17/14, 2:13 PM, Nico Williams wrote:=0A> On Fri, Mar 14, 2014 a= t 4:52 PM, Bill Mills=0A> wrote:=0A>> Quoting here= , in the hope that it piques someone's interest.=A0 New=0A>> proposed langu= age is:=0A>> =0A>> " Client responses are a GS2 [RFC5801] header followed b= y a=0A>> key/value pair sequence, or may be empty. The gs2-header is=0A>> d= efined here for compatibility with GS2 if a GS2 mechanism is=0A>> formally = defined, but this document does not=0A> =0A> s/formally/eventually/ ?=0A> = =0A>> define one. These key/value pairs carry the equivalent values=0A>> fr= om an HTTP context in order to be able to complete an OAuth=0A>> style HTTP= authorization. Unknown key/value pairs MUST be ignored=0A>> by the server.= The ABNF [RFC5234] syntax is:=0A>> =0A>> =0A>> kvsep=A0 =A0 =A0 =A0 =A0 = =3D %x01 key=A0 =A0 =A0 =A0 =A0 =A0 =3D 1*(ALPHA / ",") value=0A>> =3D *(VC= HAR / SP / HTAB / CR / LF ) kvpair=A0 =A0 =A0 =A0 =3D key "=3D" value=0A>>= kvsep ;;gs2-header=A0 =A0 =3D See RFC 5801 client_resp=A0 =A0 =3D=0A>> (g= s2-header kvsep 0*kvpair kvsep) / kvsep=0A>> =0A>> The GS2 header MUST incl= de the user name asociated with the=0A>> resource being accessed, the "auth= zid"."=0A> =0A> Hmm, MUST?=A0 SASL allows the app to not use an authzid if = it=0A> doesn't want to.=A0 I understand that Google's OAuth use case=0A> re= quires an authzid, but it's not obvious to me that all OAuth use=0A> cases = will.=0A> =0A> + the two typos Ryan noticed.=0A> =0A=0AI had the same pause= as Nico.=A0 The implementation I was looking into=0Adid not require such i= nformation.=0A=0A=0A=0A- -- =0A- - m&m=0A=0AMatt Miller < mamille2@cisco.co= m >=0ACisco Systems, Inc.=0A-----BEGIN PGP SIGNATURE-----=0AVersion: GnuPG/= MacGPG2 v2.0.22 (Darwin)=0AComment: GPGTools - https://gpgtools.org=0AComme= nt: Using GnuPG with Thunderbird - http://www.enigmail.net/=0A=0AiQEcBAEBCg= AGBQJTJ1vBAAoJEDWi+S0W7cO1GbIH/jB145C0XvBjgngGNcVKs/Be=0A15zEdvojCNdDY0wHdj= UXbwIbWs7LHA5ltO8NJhUVLU8E+Rmjl6ow+GvtlwqxCEFm=0AIogrbU3uLEtB2liMGXBxLk2u4S= bMV92e8g0WNQ7Qmo5Yws8urzkBFrcIG/Yu2gbe=0AyUjvp8ai1E7o3y6xBZtzgZqIebF063mVMR= GXJvIR5Z5DcgjQ0UMW0GLhGslYX6yB=0A+pQ+faA2IsTDIVVBuOu9weP8mwgxU2tqtMcxe7ffWy= 1iPZrxk21pLvVmHL4sLHXO=0A4znnhsGApj+OzDojLPXh2jEdGOiO2goz2DWcV04rqpMSeMjLYK= 7jLw3N0YqMMZw=3D=0A=3DW7/c=0A-----END PGP SIGNATURE----- ---685807438-769530606-1395090782=:52393 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
OK, so gi= ven Google's extant implementation, if we change it to SHOULD the MUST is i= mplicit and the de facto standard anyway if you want it to work with Google= .

I'd rather have= the standard explicitly document what is working now, but I can make the c= hange easily.
 
-bill


=
-----= ---------------------------
William J. Mills
"Paranoid" MUX Yahoo!



On Monday, March = 17, 2014 1:32 PM, Matt Miller <mamille2@cisco.com> wrote:
=
-----BEGIN PGP SIGNED MESSAGE-----<= br clear=3D"none">Hash: SHA512

On 3/17= /14, 2:13 PM, Nico Williams wrote:
> On Fri, Mar 14, 2= 014 at 4:52 PM, Bill Mills
> <wmills_92105@yahoo.com> wrote:
>> Quoting= here, in the hope that it piques someone's interest.  New
>> proposed language is:
>>
>> " Client responses are a GS2 [RFC5801] header followed by a
>&= gt; key/value pair sequence, or may be empty. The gs2-header is
>> defined here for compatibility with GS2 if a GS2 mechanism = is
>> formally defined, but this document does not<= br clear=3D"none">>
> s/formally/eventually/ ?
>
>> define one. These key/value= pairs carry the equivalent values
>> from an HTTP = context in order to be able to complete an OAuth
>>= style HTTP authorization. Unknown key/value pairs MUST be ignored
>> by the server. The ABNF [RFC5234] syntax is:
>>
>>
>> kvs= ep          =3D %x01 key       = ;     =3D 1*(ALPHA / ",") value
>> =3D *(= VCHAR / SP / HTAB / CR / LF ) kvpair        =3D key "=3D" value
>> kvsep ;;gs2-header    =3D See RFC 5801 client_resp&nbs= p;   =3D
>> (gs2-header kvsep 0*kvpair kvsep) = / kvsep
>>
>> The GS2 head= er MUST inclde the user name asociated with the
>> = resource being accessed, the "authzid"."
>
> Hmm, MUST?  SASL allows the app to not use an authzid i= f it
> doesn't want to.  I understand that Google= 's OAuth use case
> requires an authzid, but it's not = obvious to me that all OAuth use
> cases will.
>
> + the two typos Ryan noticed.
>

I had the same paus= e as Nico.  The implementation I was looking into
di= d not require such information.



- --
- - m&m


Matt Miller < mamille2@cisc= o.com >
Cisco Systems, Inc.
----= -BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 = (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTJ1vBAAoJEDWi+S0W7cO1GbIH/j= B145C0XvBjgngGNcVKs/Be
15zEdvojCNdDY0wHdjUXbwIbWs7LHA5ltO= 8NJhUVLU8E+Rmjl6ow+GvtlwqxCEFm
IogrbU3uLEtB2liMGXBxLk2u4S= bMV92e8g0WNQ7Qmo5Yws8urzkBFrcIG/Yu2gbe
yUjvp8ai1E7o3y6xBZtzgZqIebF063mVMRGXJvIR5Z5DcgjQ0UMW0GLhGsl= YX6yB
+pQ+faA2IsTDIVVBuOu9weP8mwgxU2tqtMcxe7ffWy1iPZrxk21= pLvVmHL4sLHXO
4znnhsGApj+OzDojLPXh2jEdGOiO2goz2DWcV04rqpM= SeMjLYK7jLw3N0YqMMZw=3D
=3DW7/c
-----EN= D PGP SIGNATURE-----



---685807438-769530606-1395090782=:52393-- From nobody Mon Mar 17 14:15:41 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9F61A05D3 for ; Mon, 17 Mar 2014 14:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2IcPPzEoiJe for ; Mon, 17 Mar 2014 14:15:27 -0700 (PDT) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) by ietfa.amsl.com (Postfix) with ESMTP id 86C1A1A058E for ; Mon, 17 Mar 2014 14:15:27 -0700 (PDT) Received: from [66.196.81.171] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 21:15:19 -0000 Received: from [98.139.212.246] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 21:15:19 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 21:15:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 347813.51320.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 86972 invoked by uid 60001); 17 Mar 2014 21:15:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395090919; bh=ZXgWFE58iTjdN20Ho0GCTUVdpVgeJ/B04vzV8vYKNzg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VkClXxdC7BnboUiT1H/B8YvDIS9tphDCeg5GmllK/GMFi8rkr0peXLXzcjUR5/Hf9Xdrxuwt86ZQZE2FBH42T1kCSgEfGhDNGlQTju2hpPKgjEyySZxD2qyGGDLTHS4M1qOppEYPXVN7tUgVJO0duGTf+QyTz0sJglzZsutB87k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WOeyu8KNWKR/WXmCL1gci2I4RKAXC5HG2yj+ayeC1syPi+w4VADx0yZLQCOQQAOZr4HGFacCSBlh1Y+e0ETuZHMllMapyB1Aeu6fSmYG3SWXKeP5M8hFf1vaH2tkF/jZ0bKYL10H1Ln1CEsttWkXUhHk8x5WWO9CyVg9jnJY6lk=; X-YMail-OSG: n4hvsMwVM1lLhaMc4L0MyN7ANAD7OEL4_KAmKO8MDaRR3fl _cuRifzBc9GcAYvjv8FxSt2K24vPg3rYuHWxkcUtX6DAtZ6dkubug6JsPGSn WaDrzW646vbmbo2vAuSiiTYOaT4853CktnPKe6AzXEVcIAN7FNXhecmlFT_o OS_tevGXyd5CkE3Ku5ZdMpBaoWiJIsSeeoibt0B8NDe3xBlGRvn.kd7ngIYY 39t1Gg02mxSYC_6odaYzYbKy8tGNEYK.AUhXjd4EFZ7Hdqnhs..ZAtrxgbOk mnRXL5HyFKMceAS9e_DrPv5CBSvafs9th.QhD3xiDsymIQ7z2MTwsTQcKmQO J4Mq2oAMrpamyl2ZMvD_KOpo6D8auJl9XVX05DZDe76JhExvtb4sFORAg7Z1 MBfowOiEchmVzMveBFnHUnv3Byl7eO1SpdLxYLHPX.ipy5VYE4ZL1hd8JHiz xL6lsoR9a5EoKaGR6J8b51a0AaRke6xsekmmfBAZHo44IpjNgh8tYJ9pavKH _rCalx1QTAHtC_cRD8KFaOcECbnBAso5yb1A0BG3aDCcxB6HyYMQAzCktowx JVyzEZTwmynDz_oNutBdVQDiK94zSpUPsIj7pI7HKD.MqdQAwcNBaFsokSzo ank4ua2Zste4k4NqfvS3OYsmdklmd.GIBJdY4gySumZkn82MZKut666fhmXw 9G0wnjt2TKvqSKS0w.pc- Received: from [66.228.162.52] by web142806.mail.bf1.yahoo.com via HTTP; Mon, 17 Mar 2014 14:15:19 PDT X-Rocket-MIMEInfo: 002.001, T0ssIHNvIGdpdmVuIEdvb2dsZSdzIGV4dGFudCBpbXBsZW1lbnRhdGlvbiwgaWYgd2UgY2hhbmdlIGl0IHRvIFNIT1VMRCAKdGhlIE1VU1QgaXMgaW1wbGljaXQgYW5kIHRoZSBkZSBmYWN0byBzdGFuZGFyZCBhbnl3YXkgaWYgeW91IHdhbnQgaXQgdG8gCndvcmsgd2l0aCBHb29nbGUuCgoKSSdkIHJhdGhlciBoYXZlIHRoZSBzdGFuZGFyZCBleHBsaWNpdGx5IGRvY3VtZW50IHdoYXQgaXMgd29ya2luZyBub3csIGJ1dCBJIGNhbiBtYWtlIHRoZSBjaGFuZ2UgZWFzaWx5LgoKwqAKLWJpbGwKCgoKCk9uIE1vbmQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.178.641 References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53275BC1.50808@cisco.com> Message-ID: <1395090919.78935.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Mon, 17 Mar 2014 14:15:19 -0700 (PDT) From: Bill Mills To: Matt Miller , Nico Williams In-Reply-To: <53275BC1.50808@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="515012262-1298679956-1395090919=:78935" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/kY8oNteumU1SLhMQ0Yr429QZ3BI Cc: "kitten@ietf.org" , Bill Mills , Sam Hartman Subject: Re: [kitten] Pending draft 15 Re: sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 21:15:30 -0000 --515012262-1298679956-1395090919=:78935 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OK, so given Google's extant implementation, if we change it to SHOULD =0At= he MUST is implicit and the de facto standard anyway if you want it to =0Aw= ork with Google.=0A=0A=0AI'd rather have the standard explicitly document w= hat is working now, but I can make the change easily.=0A=0A=A0=0A-bill=0A= =0A=0A=0A=0AOn Monday, March 17, 2014 1:32 PM, Matt Miller wrote:=0A =0A-----BEGIN PGP SIGNED MESSAGE-----=0AHash: SHA512=0A=0AOn= 3/17/14, 2:13 PM, Nico Williams wrote:=0A> On Fri, Mar 14, 2014 at 4:52 PM= , Bill Mills=0A> wrote:=0A>> Quoting here, in the = hope that it piques someone's interest.=A0 New=0A>> proposed language is:= =0A>> =0A>> " Client responses are a GS2 [RFC5801] header followed by a=0A>= > key/value pair sequence, or may be empty. The gs2-header is=0A>> defined = here for compatibility with GS2 if a GS2 mechanism is=0A>> formally defined= , but this document does not=0A> =0A> s/formally/eventually/ ?=0A> =0A>> de= fine one. These key/value pairs carry the equivalent values=0A>> from an HT= TP context in order to be able to complete an OAuth=0A>> style HTTP authori= zation. Unknown key/value pairs MUST be ignored=0A>> by the server. The ABN= F [RFC5234] syntax is:=0A>> =0A>> =0A>> kvsep=A0 =A0 =A0 =A0 =A0 =3D %x01 k= ey=A0 =A0 =A0 =A0 =A0 =A0 =3D 1*(ALPHA / ",") value=0A>> =3D *(VCHAR / SP /= HTAB / CR / LF ) kvpair=A0 =A0 =A0 =A0 =3D key "=3D" value=0A>> kvsep ;;g= s2-header=A0 =A0 =3D See RFC 5801 client_resp=A0 =A0 =3D=0A>> (gs2-header = kvsep 0*kvpair kvsep) / kvsep=0A>> =0A>> The GS2 header MUST inclde the use= r name asociated with the=0A>> resource being accessed, the "authzid"."=0A>= =0A> Hmm, MUST?=A0 SASL allows the app to not use an authzid if it=0A> doe= sn't want to.=A0 I understand that Google's OAuth use case=0A> requires an = authzid, but it's not obvious to me that all OAuth use=0A> cases will.=0A> = =0A> + the two typos Ryan noticed.=0A> =0A=0AI had the same pause as Nico.= =A0 The implementation I was looking into=0Adid not require such informatio= n.=0A=0A=0A=0A- -- =0A- - m&m=0A=0AMatt Miller < mamille2@cisco.com >=0ACis= co Systems, Inc.=0A-----BEGIN PGP SIGNATURE-----=0AVersion: GnuPG/MacGPG2 v= 2.0.22 (Darwin)=0AComment: GPGTools - https://gpgtools.org=0AComment: Using= GnuPG with Thunderbird - http://www.enigmail.net/=0A=0AiQEcBAEBCgAGBQJTJ1v= BAAoJEDWi+S0W7cO1GbIH/jB145C0XvBjgngGNcVKs/Be=0A15zEdvojCNdDY0wHdjUXbwIbWs7= LHA5ltO8NJhUVLU8E+Rmjl6ow+GvtlwqxCEFm=0AIogrbU3uLEtB2liMGXBxLk2u4SbMV92e8g0= WNQ7Qmo5Yws8urzkBFrcIG/Yu2gbe=0AyUjvp8ai1E7o3y6xBZtzgZqIebF063mVMRGXJvIR5Z5= DcgjQ0UMW0GLhGslYX6yB=0A+pQ+faA2IsTDIVVBuOu9weP8mwgxU2tqtMcxe7ffWy1iPZrxk21= pLvVmHL4sLHXO=0A4znnhsGApj+OzDojLPXh2jEdGOiO2goz2DWcV04rqpMSeMjLYK7jLw3N0Yq= MMZw=3D=0A=3DW7/c=0A-----END PGP SIGNATURE----- --515012262-1298679956-1395090919=:78935 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OK, so given Google's extant implementation, if we= change it to SHOULD =0Athe MUST is implicit and the de facto standard anyw= ay if you want it to =0Awork with Google.

I'd rather have the standard explicitly document what i= s working now, but I can make the change easily.
<= /div>
 
-bill


On Monday, Mar= ch 17, 2014 1:32 PM, Matt Miller <mamille2@cisco.com> wrote:
-----BEGIN PGP SIGNED MESSAGE---= --
Hash: SHA512

On 3/17/14, 2:13 PM, Nico Williams wrote= :
> On Fri, Mar 14, 2014 at 4:52 PM, Bill Mills
> <wmills_92105@yahoo.com>= wrote:
>> Quoting here, in the hope that it piques= someone's interest.  New
>> proposed language= is:
>>
>> " Client respon= ses are a GS2 [RFC5801] header followed by a
>> key= /value pair sequence, or may be empty. The gs2-header is
= >> defined here for compatibility with GS2 if a GS2 mechanism is
>> formally defined, but this document does not
>
> s/formally/eventually/ ?
>
>> define one. These key/value pair= s carry the equivalent values
>> from an HTTP context in order to be able= to complete an OAuth
>> style HTTP authorization. = Unknown key/value pairs MUST be ignored
>> by the s= erver. The ABNF [RFC5234] syntax is:
>>
>>
>> kvsep      &n= bsp;   =3D %x01 key            =3D 1*(AL= PHA / ",") value
>> =3D *(VCHAR / SP / HTAB / CR / = LF ) kvpair        =3D key "=3D" value
>> kvsep ;;gs2-header    =3D See RFC 5801 client_resp&n= bsp;   =3D
>> (gs2-header kvsep 0*kvpair kvsep= ) / kvsep
>>
>> The GS2 he= ader MUST inclde the user name asociated with the
>>= ; resource being accessed, the "authzid"."
>
> Hmm, MUST?  SASL allows the app to not use an authzid if it
> doesn't = want to.  I understand that Google's OAuth use case
= > requires an authzid, but it's not obvious to me that all OAuth use
> cases will.
>
&= gt; + the two typos Ryan noticed.
>

I had the same pause as Nico.  The implementation = I was looking into
did not require such information.



- --
- - m&m


Matt Miller < mamille2@cisc= o.com >
Cisco Systems, Inc.
----= -BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 = (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Th= underbird - http://www.enigmail.net/

iQ= EcBAEBCgAGBQJTJ1vBAAoJEDWi+S0W7cO1GbIH/jB145C0XvBjgngGNcVKs/Be
15zEdvojCNdDY0wHdjUXbwIbWs7LHA5ltO8NJhUVLU8E+Rmjl6ow+GvtlwqxCEFm
IogrbU3uLEtB2liMGXBxLk2u4SbMV92e8g0WNQ7Qmo5Yws8urzkBFrcIG/Yu2= gbe
yUjvp8ai1E7o3y6xBZtzgZqIebF063mVMRGXJvIR5Z5DcgjQ0UMW0= GLhGslYX6yB
+pQ+faA2IsTDIVVBuOu9weP8mwgxU2tqtMcxe7ffWy1iP= Zrxk21pLvVmHL4sLHXO
4znnhsGApj+OzDojLPXh2jEdGOiO2goz2DWcV= 04rqpMSeMjLYK7jLw3N0YqMMZw=3D
=3DW7/c
-= ----END PGP SIGNATURE-----


<= /html> --515012262-1298679956-1395090919=:78935-- From nobody Mon Mar 17 14:27:25 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B581A01DF for ; Mon, 17 Mar 2014 14:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpvGP3EOkH0R for ; Mon, 17 Mar 2014 14:27:22 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (agjbgdcfdbhb.dreamhost.com [69.163.253.171]) by ietfa.amsl.com (Postfix) with ESMTP id 122051A02FC for ; Mon, 17 Mar 2014 14:27:22 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 28BBA43807F for ; Mon, 17 Mar 2014 14:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=AK+3dDhEEVompDy/w6Ni ZXijRPk=; b=AyQlwTHdo8DK1qeKOubrrQKTsv7OsA7kHg86KZlA0UlPgCmBGtW9 LN4MoRPZFu8dkyGT4gmC5hZa2Mf0uJoA4ow8ReOpDoDfYnUaCyTogjjqPJLFnTc/ xgqELqqDr3sAzWPQglr2kxpBFEe+9URESA/r9HeN3rZwIQ8G+v0LeoY= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id D038A43807C for ; Mon, 17 Mar 2014 14:27:13 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id w62so5182185wes.14 for ; Mon, 17 Mar 2014 14:27:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GgEBGRPg3scDDmTbVCCRta9TOqfIXw98FZ6h47wxhw4=; b=hKXIq8mnQ9zpsOfn7+WVhuTMQvS7mPj1sYc8Wd7i92QrlpHSPkrY8aKnfqyY2qJMVW goVTGXP+xsnRKHYQ76HDoHpJoP1PBhfMx8DkAUisji3GAWnxDEFNzom5B3ezu+dLv4rR 4h9PF4WPnPcYJDcmfvMdDksjFnC4eUbyXkb/+hbuC8CT1lRCqclH34wo6Qh1b//cZuLr d9SKo9FubS9j4xors7mwx6tpJR8+sQ00S3Gx224d5P4B2p+7+cpaHbt/A4BKKscqf+Eu mfiDR3VAtj5LWtTlZ0fJxYSA0KYaX1ijDN40wczBoUM/QneXW6mCCFO2Ktkxw74hYnen X3TA== MIME-Version: 1.0 X-Received: by 10.180.97.72 with SMTP id dy8mr11152131wib.5.1395091632588; Mon, 17 Mar 2014 14:27:12 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Mon, 17 Mar 2014 14:27:12 -0700 (PDT) In-Reply-To: <1395090919.78935.YahooMailNeo@web142806.mail.bf1.yahoo.com> References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53275BC1.50808@cisco.com> <1395090919.78935.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Mon, 17 Mar 2014 16:27:12 -0500 Message-ID: From: Nico Williams To: Bill Mills Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/s7pceOJdC_FcaJRsl5XQCtRpKEU Cc: "kitten@ietf.org" , Bill Mills , Sam Hartman Subject: Re: [kitten] Pending draft 15 Re: sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 21:27:23 -0000 On Mon, Mar 17, 2014 at 4:15 PM, Bill Mills wrote: > OK, so given Google's extant implementation, if we change it to SHOULD the > MUST is implicit and the de facto standard anyway if you want it to work > with Google. No need to say either MUST nor SHOULD. Instead you might want to note that in common usage of this mechanism the server tends to require that the client send an authz-id. Nico -- From nobody Mon Mar 17 14:56:29 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA661A0314 for ; Mon, 17 Mar 2014 14:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-YliQCWClB8 for ; Mon, 17 Mar 2014 14:56:27 -0700 (PDT) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) by ietfa.amsl.com (Postfix) with ESMTP id 247221A031A for ; Mon, 17 Mar 2014 14:56:27 -0700 (PDT) Received: from [66.196.81.170] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 21:56:19 -0000 Received: from [98.139.212.226] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 21:56:19 -0000 Received: from [127.0.0.1] by omp1035.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 21:56:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 10761.62925.bm@omp1035.mail.bf1.yahoo.com Received: (qmail 75513 invoked by uid 60001); 17 Mar 2014 21:56:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395093378; bh=JJ9WOzingnAAIG8Iv9HA8etur/AVzGWTs1XlRnEhVZM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ghbe3R09kre2A0eMKbIP/8dSR52hjnD9A/wIIJT2IDav2F8uPsq1uijNPqbxP9G9Anz4Du0Gi0w0BW/c1EGXFgPsYKDgxIfD76/aZtzUEf4xZBzR25G+IuzBKvNVCKLpNGYvzc+xTkqrAoN2Vpkd4DNdBsymxYiaz1CofkubPBc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OtDMmVTnj7/Db8edPRNOCjGjp/W9oyb17nHjmwMOK1AkvnpzN9Nk1ilRxknSJM1bg1+EpRe8Qba9TQOeWLQ3qzNRvq73B8B1ceT70ASRw0BfdMdmWJZL1gF5PJqAsKpqBrvMZyAT9pP0VQ9UizwoVbi/omB1cn36eCoaVbVjaik=; X-YMail-OSG: mmxqdYkVM1mQAL_ICTJhpwIUZRdAhmbqQuzJf6RTzv3Z2nH yCQRwS2P3dp_kemK9MiQTQbbk_bmeFcx5Kwp3oZqHshmQSqxCGNjogmVffLf gtxkdMltQ28zybABzT1Daf9iatI6AO.ODELw_LOe_kEtX9mpzj4Fc1e1hurz kSKx4YdAG7sQgpDU1BfoXSosjGDhs5vQzc8CthHMqYr.YDaGnnsDFHOwEkNu 4zpdFXtK8e8v1lqH5A53HY878kDGBQ_OEW_AQg3w8wzVZFvreaaAWyxqClAM tl5ZuHhbF6CfZ1wCbafhMhL77auUQd2lQaTV13np.hIq_yIIFzvwuC7voG2V bmLmSLkPQH.5__mKmIlgi1ID.3vK_QnmeeQv2iRVWDfyzX5OW.9oHffP1iBj qHOETR0sU.qxCrdMVvo3VzdLt21SPhMVY7UGz12wMK..oaYksqoq4gbnog3K 7DVSzE5cNX7YCLOu29pX2X4JyXlXlC3xIkrrM47UY7kUhMUxmd.XnCB2ENql hTbX4kRgKm61z2NyrkzzWCLNSsyUvqQHn8nbr7DfWzycKjWk8Hrm1omW_1yF RCqFWPY7h7AkNc3v43V3vhZS0tA-- Received: from [66.228.162.52] by web142803.mail.bf1.yahoo.com via HTTP; Mon, 17 Mar 2014 14:56:18 PDT X-Rocket-MIMEInfo: 002.001, VGhpcyBmZWVscyBsaWtlIHNvZnQtc2VsbGluZyB3aGF0IHRoZSBpbXBsZW1lbnRlciBhY3R1YWxseSBoYXMgdG8gZG8uIMKgSXQncyBsaWtlIGhvdyBIVFRQIGV2b2x2ZWQgdG8gYmUgYnVnLWNvbXBsaWFudCB3aXRoIG1ham9yIGJyb3dzZXIgb3Igc2VydmVyIGJ1Z3MuIMKgTmV2ZXIgYWN0dWFsbHkgZG9jdW1lbnRlZCBidXQgYXJlIHRoZSBkZSBmYWN0byBzdGFuZGFyZCBhbnl3YXkuIMKgV2h5IGxlYXZlIGEgbGFuZG1pbmUgbGlrZSB0aGF0IHVuc3BlY2lmaWVkPwoKCgpPbiBNb25kYXksIE1hcmNoIDE3LCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.178.641 References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53275BC1.50808@cisco.com> <1395090919.78935.YahooMailNeo@web142806.mail.bf1.yahoo.com> Message-ID: <1395093378.75479.YahooMailNeo@web142803.mail.bf1.yahoo.com> Date: Mon, 17 Mar 2014 14:56:18 -0700 (PDT) From: Bill Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="905790552-2136928374-1395093378=:75479" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/7m42QP5IFjx0NJhiXsaVpWezCsM Cc: "kitten@ietf.org" , Bill Mills , Sam Hartman Subject: Re: [kitten] Pending draft 15 Re: sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 21:56:28 -0000 --905790552-2136928374-1395093378=:75479 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This feels like soft-selling what the implementer actually has to do. =A0It= 's like how HTTP evolved to be bug-compliant with major browser or server b= ugs. =A0Never actually documented but are the de facto standard anyway. =A0= Why leave a landmine like that unspecified?=0A=0A=0A=0AOn Monday, March 17,= 2014 2:27 PM, Nico Williams wrote:=0A =0AOn Mon, M= ar 17, 2014 at 4:15 PM, Bill Mills wrote:=0A> OK, = so given Google's extant implementation, if we change it to SHOULD the=0A> = MUST is implicit and the de facto standard anyway if you want it to work=0A= > with Google.=0A=0ANo need to say either MUST nor SHOULD.=A0 Instead you m= ight want to note=0Athat in common usage of this mechanism the server tends= to require=0Athat the client send an authz-id.=0A=0A=0ANico=0A-- --905790552-2136928374-1395093378=:75479 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
This feels like soft-selling what the implementer = actually has to do.  It's like how HTTP evolved to be bug-compliant wi= th major browser or server bugs.  Never actually documented but are th= e de facto standard anyway.  Why leave a landmine like that unspecifie= d?

=
On Monday, March 17, 2014 2:27 PM, Nico Williams <nico@cryptonec= tor.com> wrote:
On Mo= n, Mar 17, 2014 at 4:15 PM, Bill Mills <wmills_92105@yahoo= .com> wrote:
> OK, so given Google's extant imp= lementation, if we change it to SHOULD the
> MUST is i= mplicit and the de facto standard anyway if you want it to work
> with Google.

No need to sa= y either MUST nor SHOULD.  Instead you might want to note
that in common usage of this mechanism the server tends to requirethat the client send an authz-id.


Nico
--


--905790552-2136928374-1395093378=:75479-- From nobody Mon Mar 17 15:20:45 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54921A063D for ; Mon, 17 Mar 2014 15:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ebAMCB2cGwN for ; Mon, 17 Mar 2014 15:20:42 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 945771A063A for ; Mon, 17 Mar 2014 15:20:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 0D7FE206BD; Mon, 17 Mar 2014 18:20:27 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75LkNY34i6qv; Mon, 17 Mar 2014 18:20:26 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 17 Mar 2014 18:20:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7A62E83E50; Mon, 17 Mar 2014 18:20:32 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53275BC1.50808@cisco.com> <1395090919.78935.YahooMailNeo@web142806.mail.bf1.yahoo.com> Date: Mon, 17 Mar 2014 18:20:32 -0400 In-Reply-To: (Nico Williams's message of "Mon, 17 Mar 2014 16:27:12 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/4asTCR2U-yIPaxjrSX201TZNEwk Cc: "kitten@ietf.org" , Bill Mills , Sam Hartman Subject: Re: [kitten] Pending draft 15 Re: sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 22:20:43 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Mon, Mar 17, 2014 at 4:15 PM, Bill Mills wrote: >> OK, so given Google's extant implementation, if we change it to >> SHOULD the MUST is implicit and the de facto standard anyway if >> you want it to work with Google. Nico> No need to say either MUST nor SHOULD. Instead you might want Nico> to note that in common usage of this mechanism the server Nico> tends to require that the client send an authz-id. what bill described to me was not authz ID. It was a routing hint that was a lot closer to an in-mechanism authentication ID. From nobody Mon Mar 17 15:29:04 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52461A063F for ; Mon, 17 Mar 2014 15:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ios4DmFzKrDo for ; Mon, 17 Mar 2014 15:29:01 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (agjbgdcfdbfg.dreamhost.com [69.163.253.156]) by ietfa.amsl.com (Postfix) with ESMTP id BDF7A1A0324 for ; Mon, 17 Mar 2014 15:29:01 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id A0412B805C for ; Mon, 17 Mar 2014 15:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=QVk1M++smduP5TU9Dfaq tr2TMPw=; b=uBIPeHqd/YuHD14Kqqvkd/abq4t0KdJFwTjuNUpouCfJjlqfOMbU lmdNuNRdlUWDHjLv45VYlGSEllcAEoSTWeDOKRALxed3CoozEjzVFjs91YtUF6Mn m8echXKvH+WRK2vKZJtFE8plY/YoZRFhzZRxqEOGdjvrCvx3Eq6lXec= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 521B0B805B for ; Mon, 17 Mar 2014 15:28:53 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hr14so2909273wib.3 for ; Mon, 17 Mar 2014 15:28:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ddiqbXxaBS6wakuGfZ4LHv79bgIGTOf+qQIUz2ScilY=; b=bEccdfb1DzcExsIxRnbi6clyr52wGcAvDVur+8dvOYBAcuTS5e9LTq9PkK+QIZrx0M vFLxcHgRnvfah4ujVbwr5jakLIXDvsDqS/dhhKWet/GT2wCjbH5Zcs1Ewl7HNn9sZ2pK laPBTwJcA/fF3h/ZP/oGtEEU53DDMfko8PivB9i9OtKcXFaBnthcEc5OgiyxxKQvFdAX F8sAUNL8H6OmhDfEtUBRdH+d0LQSHs8cSXN7WW01HXqdokEmZuOs0Sv+tqIN0cgqry/V ZKziiqs1KiULJZiUt4gZE2iMX+QdDY0Mf5L8foX/q2DilozP3uT5zaCrm2UGWGBvTn1b gm2w== MIME-Version: 1.0 X-Received: by 10.180.36.8 with SMTP id m8mr11441755wij.42.1395095332005; Mon, 17 Mar 2014 15:28:52 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Mon, 17 Mar 2014 15:28:51 -0700 (PDT) In-Reply-To: <1395093378.75479.YahooMailNeo@web142803.mail.bf1.yahoo.com> References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53275BC1.50808@cisco.com> <1395090919.78935.YahooMailNeo@web142806.mail.bf1.yahoo.com> <1395093378.75479.YahooMailNeo@web142803.mail.bf1.yahoo.com> Date: Mon, 17 Mar 2014 17:28:51 -0500 Message-ID: From: Nico Williams To: Bill Mills Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/kSVYJiS0d8dkvCF4KIz5etkFAek Cc: "kitten@ietf.org" , Bill Mills , Sam Hartman Subject: Re: [kitten] Pending draft 15 Re: sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 22:29:02 -0000 On Mon, Mar 17, 2014 at 4:56 PM, Bill Mills wrote: > This feels like soft-selling what the implementer actually has to do. It's > like how HTTP evolved to be bug-compliant with major browser or server bugs. > Never actually documented but are the de facto standard anyway. Why leave a > landmine like that unspecified? Because the way it works in practice is that the app has something like a dialog or panel where the user is invited to "set/create an account" or something like that. The user will be invited to specify a server name, pick a mechanism, and for the mechnism selection perhaps addition inputs, and finally they'll be invited to specify an authzid. Some of these account parameters are generic: - a local name for whatever this "account" is - the server name (and port) - the authzid - the name of the mechanism everything else is mechanism-specific (e.g., "password", "keystore", "principal name", ...). The generic bits are generic. And authzid has always been application-specific. Application protocols are allowed to require an authzid. Servers are allowed to require an authzid. Mechanisms are NOT allowed to require an authzid. Nico -- From nobody Mon Mar 17 15:46:01 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514921A045F for ; Mon, 17 Mar 2014 15:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVVLvs0vlWIy for ; Mon, 17 Mar 2014 15:45:54 -0700 (PDT) Received: from nm27-vm1.bullet.mail.bf1.yahoo.com (nm27-vm1.bullet.mail.bf1.yahoo.com [98.139.213.148]) by ietfa.amsl.com (Postfix) with ESMTP id 433FD1A0436 for ; Mon, 17 Mar 2014 15:45:54 -0700 (PDT) Received: from [98.139.212.150] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 22:45:46 -0000 Received: from [98.139.212.227] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 22:45:46 -0000 Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 22:45:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 44301.7305.bm@omp1036.mail.bf1.yahoo.com Received: (qmail 9335 invoked by uid 60001); 17 Mar 2014 22:45:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395096345; bh=XpTWCkIAmalqdZsyRKo6aVI2XM5FBUrrw029wTON+ks=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cBwV7WcROD2fhYkuHuume9alsAEWNwH845mEdWS5lgA/hUpivlQTGlicWp0SYz4nGahb1HC3k+FB/3QJUyBpOEFw+Il1zgSvlXdwbTR9cixcICwCuVE0uouRgjTjwNvCVeAqPsaPMEQBui+uApxnGwr+p7wdzqsXCUvepSG9Q84= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DPIB2/Nej69PoN9dwYvU+bzUIttZSdWWtXGyz0t7TnHQyx8O+w1++LSXCQL9Gfqs8woCdz+UyEoaCh6Yh16U58P3xSF4rUDowtunmDTIAHavZTdWjX1aXGZ/krSL9FwdJY7L+93wnRvjctohd5Cjt8CvWVHWvG7wu8AdHx65LHQ=; X-YMail-OSG: 4egw1DUVM1ntjE9.OtSmcInZWbJNCg34FlCbHEMj6KNMBb5 md8alwIjAQuZts.uTcecHBgZ1RhbO56CC.cLAzzxi8u2551zVN4q_acNBZsd t64sqQt5YN.2wvExU6O0o37Q.dOxzr.V5yApVx_K7ievG6Lo7S1u7ue_R6c7 18JQz0uoAqkGWkrBpnP6kN7UA0U_FZQrmU5RR.dCiNhchpDqnXFAjF1GpZPp XQulaUwM8pnz0YR1LcInMOjH8lwH58QXUPPF7NA0rA0GRFBibXS2BBsvn3jk dmIBKW2LIra_sGF1myZhurPm4xMs9G3SAOwOpB17BQN.v2VMOjNf7cMM9zpP y3olD7CrG1RDHQN7Ro06waaEzOEWzp10ZVKkYzDF1IjmtxEWgxBUltbN2hF_ P_pRVv3aU91totRh6IyGzmpb8CrYYE_.sfn_xROrM.1EkH5IX9PVaMK4pzdW ZMfYg6F5elcA11NOAdyPZOQuPnMP2DecMWnIZRaIog7y15DLZysdbIOcALK7 eYV2CWGy_56.D._pvSwzh5wBlgigaac30GoeqmqaRxfWbkCeyfljHc2U2QND grHuA_kKieAQ2b1eR5htUzffAow-- Received: from [66.228.162.52] by web142803.mail.bf1.yahoo.com via HTTP; Mon, 17 Mar 2014 15:45:45 PDT X-Rocket-MIMEInfo: 002.001, Q2hhbmdlZCBNVVNUIHRvIE1BWS4gwqBBZGRlZCAiSXQgaXMgd29ydGggbm90aW5nIHRoYXQgYXBwbGljYXRpb24KcHJvdG9jb2xzIGFyZSBhbGxvd2VkIHRvIHJlcXVpcmUgYW4gYXV0aHppZCwgYXMgYXJlIHNwZWNpZmljIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMuIgoKCgpPbiBNb25kYXksIE1hcmNoIDE3LCAyMDE0IDM6MjggUE0sIE5pY28gV2lsbGlhbXMgPG5pY29AY3J5cHRvbmVjdG9yLmNvbT4gd3JvdGU6CiAKT24gTW9uLCBNYXIgMTcsIDIwMTQgYXQgNDo1NiBQTSwgQmlsbCBNaWxscyA8d21pbGxzXzkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.178.641 References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53275BC1.50808@cisco.com> <1395090919.78935.YahooMailNeo@web142806.mail.bf1.yahoo.com> <1395093378.75479.YahooMailNeo@web142803.mail.bf1.yahoo.com> Message-ID: <1395096345.90762.YahooMailNeo@web142803.mail.bf1.yahoo.com> Date: Mon, 17 Mar 2014 15:45:45 -0700 (PDT) From: Bill Mills To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="905790552-1963799861-1395096345=:90762" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/XOg1gaa84AyKWRy_YdiFWlU6q8w Cc: "kitten@ietf.org" , Bill Mills , Sam Hartman Subject: Re: [kitten] Pending draft 15 Re: sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 22:45:56 -0000 --905790552-1963799861-1395096345=:90762 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Changed MUST to MAY. =A0Added "It is worth noting that application=0Aprotoc= ols are allowed to require an authzid, as are specific server implementatio= ns."=0A=0A=0A=0AOn Monday, March 17, 2014 3:28 PM, Nico Williams wrote:=0A =0AOn Mon, Mar 17, 2014 at 4:56 PM, Bill Mills wrote:=0A> This feels like soft-selling what the imple= menter actually has to do.=A0 It's=0A> like how HTTP evolved to be bug-comp= liant with major browser or server bugs.=0A> Never actually documented but = are the de facto standard anyway.=A0 Why leave a=0A> landmine like that uns= pecified?=0A=0ABecause the way it works in practice is that the app has som= ething=0Alike a dialog or panel where the user is invited to "set/create an= =0Aaccount" or something like that.=A0 The user will be invited to specify= =0Aa server name, pick a mechanism, and for the mechnism selection=0Aperhap= s addition inputs, and finally they'll be invited to specify an=0Aauthzid.= =A0 Some of these account parameters are generic:=0A=0A- a local name for w= hatever this "account" is=0A- the server name (and port)=0A- the authzid=0A= - the name of the mechanism=0A=0Aeverything else is mechanism-specific (e.g= ., "password", "keystore",=0A"principal name", ...).=0A=0AThe generic bits = are generic.=A0 And authzid has always been=0Aapplication-specific.=A0 Appl= ication protocols are allowed to require an=0Aauthzid.=A0 Servers are allow= ed to require an authzid.=A0 Mechanisms are=0ANOT allowed to require an aut= hzid.=0A=0A=0ANico=0A-- --905790552-1963799861-1395096345=:90762 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Changed MUST to MAY.  Added "It is worth noting that application
=0A
=09protocols are allowed to require = an authzid, as are specific server implementations."


=
On Monday, March 17, 201= 4 3:28 PM, Nico Williams <nico@cryptonector.com> wrote:
 <= /div>
On Mon, Mar 17, 2014 at 4:56 PM, Bill= Mills <wmills_92105@yahoo.com> wrote:> This feels like soft-selling what the implementer actu= ally has to do.  It's
> like how HTTP evolved to = be bug-compliant with major browser or server bugs.
> Ne= ver actually documented but are the de facto standard anyway.  Why lea= ve a
> landmine like that unspecified?

Because the way it works in practice is that the app = has something
like a dialog or panel where the user is in= vited to "set/create an
account" or something like that.&= nbsp; The user will be invited to specify
a server name, = pick a mechanism, and for the mechnism selection
perhaps = addition inputs, and finally they'll be invited to specify an
authzid.  Some of these account parameters are generic:

- a local name for whatever this "account" is=
- the server name (and port)
- the a= uthzid
- the name of the mechanism
everything else is mechanism-specific (e.g., "password", "keystore",
"principal name", ...).

The generic = bits are generic.  And authzid has always been
appli= cation-specific.  Application protocols are allowed to require an
authzid.  Servers are allowed to require an authzid.&nbs= p; Mechanisms are
NOT allowed to require an authzid.


Nico
--


--905790552-1963799861-1395096345=:90762-- From nobody Tue Mar 18 13:03:28 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5811A0296 for ; Tue, 18 Mar 2014 13:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.027 X-Spam-Level: X-Spam-Status: No, score=-9.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oldhnjGt3-GT for ; Tue, 18 Mar 2014 13:03:25 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id BF3111A02FB for ; Tue, 18 Mar 2014 13:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2409; q=dns/txt; s=iport; t=1395172997; x=1396382597; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to:content-transfer-encoding; bh=dT33PpLFqfv3fXQKAEbcwGvmLxTuE035teKw4chR/jg=; b=etn22aZdSNgtBmaPBumK32GncqkSt/vlGRLF1DYrvU1x1QNVQOomHUQ7 5fj4cWLwUn9p39emg51L1AcEEiFF+23zeCmbwdbJkO/ipT5Zaiqbhp5mq OpZ4NK16JNo6EF7xQETe0qqXuY3opN/TrIwK53py5RgcYB8X6eHsbhDoa U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIbAEOmKFOtJXG9/2dsb2JhbABagwY7V6kRBIIklmolgQgWdIIdCAEBAQR4ARALGAkMAwcIBwkDAgECATMBERMBBQIBAYVygW8DEdAvF4xKgWUzBwoOgmaBOgEDiRo4jQ2BZ4xohUiBb4Fdggw X-IronPort-AV: E=Sophos;i="4.97,679,1389744000"; d="scan'208";a="28442882" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-5.cisco.com with ESMTP; 18 Mar 2014 20:03:17 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2IK3Hbi031876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Mar 2014 20:03:17 GMT Received: from MAMILLE2-M-T03K.local (64.101.72.44) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 18 Mar 2014 15:03:16 -0500 Message-ID: <5328A685.1020703@cisco.com> Date: Tue, 18 Mar 2014 14:03:17 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 CC: "kitten@ietf.org" References: <1393869321.174.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1393875779.29082.YahooMailNeo@web125604.mail.ne1.yahoo.com> <1393926562.54403.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1393948558.69282.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1394650561.77489.YahooMailNeo@web142801.mail.bf1.yahoo.com> <1394833947.5753.YahooMailNeo@web142802.mail.bf1.yahoo.com> <53275BC1.50808@cisco.com> <1395090919.78935.YahooMailNeo@web142806.mail.bf1.yahoo.com> <1395093378.75479.YahooMailNeo@web142803.mail.bf1.yahoo.com> <1395096345.90762.YahooMailNeo@web142803.mail.bf1.yahoo.com> In-Reply-To: <1395096345.90762.YahooMailNeo@web142803.mail.bf1.yahoo.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.101.72.44] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/PFz3UglL3nUj4sBwA9a4y8Unagc Subject: Re: [kitten] Pending draft 15 Re: sasl-oauth "user" as a kvpair or in the gs2 header? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 20:03:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 That change works for me. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 3/17/14, 4:45 PM, Bill Mills wrote: > Changed MUST to MAY. Added "It is worth noting that application > protocols are allowed to require an authzid, as are specific > server implementations." > > > On Monday, March 17, 2014 3:28 PM, Nico Williams > wrote: On Mon, Mar 17, 2014 at 4:56 PM, > Bill Mills > > wrote: >> This feels like soft-selling what the implementer actually has to >> do. > It's >> like how HTTP evolved to be bug-compliant with major browser or >> server > bugs. >> Never actually documented but are the de facto standard anyway. >> Why > leave a >> landmine like that unspecified? > > Because the way it works in practice is that the app has something > like a dialog or panel where the user is invited to "set/create an > account" or something like that. The user will be invited to > specify a server name, pick a mechanism, and for the mechnism > selection perhaps addition inputs, and finally they'll be invited > to specify an authzid. Some of these account parameters are > generic: > > - a local name for whatever this "account" is - the server name > (and port) - the authzid - the name of the mechanism > > everything else is mechanism-specific (e.g., "password", > "keystore", "principal name", ...). > > The generic bits are generic. And authzid has always been > application-specific. Application protocols are allowed to require > an authzid. Servers are allowed to require an authzid. Mechanisms > are NOT allowed to require an authzid. > > > Nico -- > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTKKaEAAoJEDWi+S0W7cO1IGIH/3dMfLiDSY6PVLK46Iar14m7 yDViiMOVMUGSPuuV9p2imv2CTn1hGUmz9Ca16HMZtyqncQauM0wuO86hgr2L7RAI h1AtgGCIrepwPMeVMDUnSb+Kv7T4JEeMpszLlIOcEellIAN+dBWOby3UJUsVR822 yWWz5F/6LR/dIws9SP6wJPq2Y0xn40KDwL+20ofjOMMI3cCsEnjdCX4fSdEAOufE LTBDyhxRK2nY7UrleWXW/flJeb5fJX2n/Mf51uSDmG0Z5h00DZhmrqA8pexwYFek mqnDs9tY/tDuDVdDmZzhHzLmLk8a/nvR4kRRobNIisVD3HwmOGoisMCUZNMFR28= =Zei6 -----END PGP SIGNATURE----- From nobody Mon Mar 24 12:33:12 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215E81A02D2 for ; Mon, 24 Mar 2014 12:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiHXOvXux0CE for ; Mon, 24 Mar 2014 12:33:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BDA261A0293 for ; Mon, 24 Mar 2014 12:33:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 52407BE57; Mon, 24 Mar 2014 19:33:06 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dgiSA0UAe84; Mon, 24 Mar 2014 19:33:06 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3269DBE49; Mon, 24 Mar 2014 19:33:06 +0000 (GMT) Message-ID: <53308872.9030305@cs.tcd.ie> Date: Mon, 24 Mar 2014 19:33:06 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "kitten@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/krCSxMNkXqQWWu8owETOfttxeQ4 Cc: "iana-questions@iana.org" Subject: [kitten] [IANA #731918] SASL mechanism not listed X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 19:33:12 -0000 Hiya, IANA were asked the following question a while back, but I dropped the ball;-) I'd appreciate your thoughts on the matter. I'm not quite sure which registries are meant exactly though. (I'll also forward to the oauth WG, but not cross-post) Thanks, S. The following draft describes a SASL mechanism that is in use on GMail and should not therefore be allocated to another scheme unless we want bad things to happen. http://tools.ietf.org/id/draft-murchison-sasl-login-00.txt The strings XOAUTH and XOAUTH2 are also being used for a preliminary version of the OAUTH spec as well. The reason Google is using this particular mechanism rather than PLAIN is that it is the one that has the widest client support: http://www.fehcom.de/qmail/smtpauth.html So it would be a real disaster if this particular code point was re-issued. It would probably be a good idea if every registry had a list of 'dirty' code points that must not be reused because there are existing applications. From nobody Mon Mar 24 13:07:04 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9E71A02EB for ; Mon, 24 Mar 2014 13:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.508 X-Spam-Level: X-Spam-Status: No, score=-1.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjLAw_DaEbhv for ; Mon, 24 Mar 2014 13:06:54 -0700 (PDT) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) by ietfa.amsl.com (Postfix) with ESMTP id 5898B1A02EA for ; Mon, 24 Mar 2014 13:06:54 -0700 (PDT) Received: from [98.139.215.140] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 24 Mar 2014 20:06:53 -0000 Received: from [98.139.212.242] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 24 Mar 2014 20:06:53 -0000 Received: from [127.0.0.1] by omp1051.mail.bf1.yahoo.com with NNFMP; 24 Mar 2014 20:06:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 379288.51803.bm@omp1051.mail.bf1.yahoo.com Received: (qmail 12795 invoked by uid 60001); 24 Mar 2014 20:06:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395691613; bh=jXaF9w7ON79g3GEpLfW+kBt6jteUmI5bTL0+CdlyavU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=PRgKNzoX7O+ak6EiXTVYJ3XNxSgIsSw1RC/OSmaq6j2V5SiRlrBTRS8JVCNa7KY+LWrPONEwdWSDvbHL9yZ3aAxf5kSwM7RBPdNpHY4qyevD+YXewM841Nbsg53y35gn/ZoiTU5u7Mpg0c9a4qj4I9rHNEKigXjm6ERd7oUxSOU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=sV2vnKKr9gCcLRZnNYFxuZdtP9powyC/kaP4b+gFZxIjzLmZq4jM1R4gGB9IuDDIuoaBvlpzialgVQYww+hTJ6CF0jI623XB1tn6LMFIiOTGG037taQAU8q87N1VePEGeRPbiu5N+/5B6MroihTW0LbCfX/MNslj6csB+/J5c40=; X-YMail-OSG: NXKbMRQVM1kJEUv1xVM1fhlVgv93HHmIaNE7e1OOxaoaYcB ywtr3oRyD0X8e.deEZvtK4g34Wpv3m.zgE8QiF3m21SDGDnvqHAMtonqkR8O 3VHyzKQym75L2hdUDHsNT_ngTUgnUM5RPbzUndhxd.jL5oKSsj8xY81731pd TEOwtS2M1yiJRd4Kv9qOABP2EjjJSD3J36WR0rTOJ6UKLRjwupsWtX2KIGzK UhFRgm36_OXbIrnmr4HiLQ0tPrOrPwsuFaltMfuoZUOpEFDqmYKGxdL0N149 FSDCBa0bjRpdFO5DMzwGEUfgq0SWKBXz4nybLMkBmX5sefYvHVvYJeieR0G6 eZAE.TPNh8Bvh_bgfTQLLv_UCx6AkC2VBvVo7QIFSRqbW8HoLj_C8S2Gf5QY WwneuWI6S2tHU_DEtMcSRjWmLS7Ix82VzqMrocG.x3nv9meh8HkbCpwKCpFB fLjTl8arA0pl4MNfj_LMIp8QcEPLUdogiCvkvYzxpzCx2TQPuH6c2ofulrga JbnM2djAJGwI6VtG.nEVH.zEO0yOq41TWn_lMakBgDsvdGU_Ig59X4yOKWrz wkmfPP1DvUANNK6OSjHn4r_mZK3vwbMVZF9QQugTZaqt5Yl2GcSXu2t8jLNU czh4_PzvtElqumBkfpuU- Received: from [66.228.162.52] by web142803.mail.bf1.yahoo.com via HTTP; Mon, 24 Mar 2014 13:06:53 PDT X-Rocket-MIMEInfo: 002.001, R29vZ2xlIHVzZWQgWE9BVVRIIGZvciBpdCdzIG9yaWdpbmFsIE9BdXRoIDEuMGEgYmFzZWQgbWVjaGFuaXNtLiDCoFRoZXkgdXNlZCBYT0FVVEgyIHRvIHNwZWNpZmljYWxseSBub3QgY29uZmxpY3Qgd2l0aCB3aGF0ZXZlciBuYW1lIHdlIHN0YW5kYXJkaXplZCBvbiBmb3IgdGhlIG1lY2hhbmlzbSBhcyBzdGFuZGFyZGl6ZWQuCgpUaGV5IHBsYW4sIGFjY29yZGluZyB0byBSeWFuIHdobydzIGJlZW4gcGFydGljaXBhdGluZyBvbiBsaXN0LCB0byBpbXBsZW1lbnQgdGhlIHN0YW5kYXJkaXplZCBtZWNoYW5pc20BMAEBAQE- X-Mailer: YahooMailWebService/0.8.181.645 References: <53308872.9030305@cs.tcd.ie> <533088AB.203@cs.tcd.ie> Message-ID: <1395691613.66133.YahooMailNeo@web142803.mail.bf1.yahoo.com> Date: Mon, 24 Mar 2014 13:06:53 -0700 (PDT) From: Bill Mills To: Stephen Farrell , "oauth@ietf.org" , "kitten@ietf.org" , "iana-questions@ietf.corg" In-Reply-To: <533088AB.203@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="905790552-1643390876-1395691613=:66133" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/jeQTR2rJOLzUHuwLPxYgAF5HvEk Subject: Re: [kitten] [OAUTH-WG] Fwd: [IANA #731918] SASL mechanism not listed X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 20:06:56 -0000 --905790552-1643390876-1395691613=:66133 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Google used XOAUTH for it's original OAuth 1.0a based mechanism. =A0They us= ed XOAUTH2 to specifically not conflict with whatever name we standardized = on for the mechanism as standardized.=0A=0AThey plan, according to Ryan who= 's been participating on list, to implement the standardized mechanism defi= nition under the OAUTHBEARER mechanism name so there should be no conflict.= =0A=0ARegards,=0A=0A-bill=0A=0A=0A=0AOn Monday, March 24, 2014 12:34 PM, St= ephen Farrell wrote:=0A =0A=0ASee below. I thin= k (not quite sure) that this is better=0Adiscussed on the kitten list.=0A= =0ATa,=0AS.=0A=0A=0A=0A-------- Original Message --------=0ASubject: [kitte= n] [IANA #731918] SASL mechanism not listed=0ADate: Mon, 24 Mar 2014 19:33:= 06 +0000=0AFrom: Stephen Farrell =0ATo: kitten@i= etf.org =0ACC: iana-questions@iana.org =0A=0A=0AHiya,=0A=0AIANA were asked the following question a while ba= ck, but I=0Adropped the ball;-)=0A=0AI'd appreciate your thoughts on the ma= tter. I'm not quite=0Asure which registries are meant exactly though.=0A=0A= (I'll also forward to the oauth WG, but not cross-post)=0A=0AThanks,=0AS.= =0A=0A=0A=0AThe following draft describes a SASL mechanism that is i= n use on=0AGMail and should not therefore be allocated to another scheme un= less=0Awe want bad things to happen.=0A=0Ahttp://tools.ietf.org/id/draft-mu= rchison-sasl-login-00.txt=0A=0AThe strings XOAUTH and XOAUTH2 are also bein= g used for a preliminary=0Aversion of the OAUTH spec as well.=0A=0AThe reas= on Google is using this particular mechanism rather than=0APLAIN is that it= is the one that has the widest client support:=0A=0Ahttp://www.fehcom.de/q= mail/smtpauth.html=0A=0ASo it would be a real disaster if this particular c= ode point was re-issued.=0A=0AIt would probably be a good idea if every reg= istry had a list of 'dirty'=0Acode points that must not be reused because t= here are existing applications.=0A=0A=0A=0A___________________________= ____________________=0AKitten mailing list=0AKitten@ietf.org=0Ahttps://www.= ietf.org/mailman/listinfo/kitten=0A=0A=0A=0A=0A____________________________= ___________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.iet= f.org/mailman/listinfo/oauth --905790552-1643390876-1395691613=:66133 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Google used XOAUTH for it's original OAuth 1.0a ba= sed mechanism.  They used XOAUTH2 to specifically not conflict with wh= atever name we standardized on for the mechanism as standardized.

They plan, according to Ryan w= ho's been participating on list, to implement the standardized mechanism de= finition under the OAUTHBEARER mechanism name so there should be no conflict.

Regards,

-bill


On Monday, March 24, 2014 12:34 PM, Stephen Farrell <= stephen.farrell@cs.tcd.ie> wrote:

See below. I think (not quite sure) that th= is is better
discussed on the kitten list.

Ta,
S.


-------- Original Message --------
Subject: [kitten] [IA= NA #731918] SASL mechanism not listed
Date: Mon, 24 Mar 2= 014 19:33:06 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>= ;
To: kitten@ietf.org <kitten@= ietf.org>
CC: iana-quest= ions@iana.org <iana-questions@iana.org= >


Hiya,

IANA were asked the following question a while= back, but I
dropped the ball;-)

I'd appreciate your thoughts on the matter. I'm not quite
sure which registries are meant exactly though.

(I'll also forward to the oauth WG, but not cross-post)

Tha= nks,
S.

<start>= ;

The following draft describes a SASL= mechanism that is in use on
GMail and should not therefo= re be allocated to another scheme unless
we want bad thin= gs to happen.

http://tools.ietf.org/id/draft-murchison-sasl-login-00.txt

The strings XOAUTH and XOAUTH2 are also bei= ng used for a preliminary
version of the OAUTH spec as we= ll.

The reason Google is using this pa= rticular mechanism rather than
PLAIN is that it is the on= e that has the widest client support:

= http:/= /www.fehcom.de/qmail/smtpauth.html

So it would be a real disaster if this particular code point was re-issued= .

It would probably be a good idea if = every registry had a list of 'dirty'
code points that mus= t not be reused because there are existing applications.
=
<end>

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





_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=


--905790552-1643390876-1395691613=:66133-- From nobody Tue Mar 25 10:19:02 2014 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407911A01F8 for ; Tue, 25 Mar 2014 10:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S56mKLJVJtpj for ; Tue, 25 Mar 2014 10:18:39 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B837B1A0203 for ; Tue, 25 Mar 2014 10:18:32 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz11so914951veb.33 for ; Tue, 25 Mar 2014 10:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SvOljOaYPsnYJ5UJjsU3YWth77S6B0z3vWZ2lFM7+o8=; b=J9Lu1Eba6MwOkYtw+3c56j36agC8oNEoESoJjnZIdrA+FofXS7Cw8ecnpO8wOFPnpW 1i/LBr1wsPZWxxDdlXfDa4IF/OvL9dmU3MNz0qFGQX/InsGTmBuTk9WgcyGUu7fnXvg+ regaVdZQjWgZlrM3ZAGgraEGUHNHMhUEK2wmGwdq3ByQgjZlk+4BPchGaNDokEO6nUuM Cza9oV/jDSfiTa/UjkRNa3k8u1DerMUL1yKwfDIEDHAaf2Gwhji72arxegD6F6REi2lS 8r0eHUzxnRbuBoYgI/YHKHga+/SfG99ImzjJ5DmfA97Io4uGC8fNyBikq6xHvgrpwKk3 DSFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SvOljOaYPsnYJ5UJjsU3YWth77S6B0z3vWZ2lFM7+o8=; b=L/um7xP/PEkgzUPrYueg0xQZSuJub3WacF/Giq041gBzvjVRfrCPw0sjFbtlV5vTfn dF42su6ECnFAJWFnQEYm1fSJhSwxAV70oOR5a/ycApeUvCevpcLxVTmNvFnfIvC7bkEF heYz1+YCJwjrSKOVwbvYzNwwE/RnH3CuCVEVBauWYmXvg/ER4WKOnU3bP6rUz/70xVJn CHmBXp6y6+W6E8OY1cZzY8mO3dHxrlNjdbi09qQEZZd3UsKJIW93CEfKULYk9qbTY5yc 2I6ZXedxsA+uUYm9ZO32B3g2myrARPQssTY2sfJPxvhllh/vWg66eYQu+ot4PWo6P8p1 tUbA== X-Gm-Message-State: ALoCoQlIpBnd4Uh9xPE8Cu6N27C6BvcBncJn3/gG5hIEGM17GayUwpBGiRNkH5rlA4fpQO60GLPzeZ3sS1Vp13NyIFi0whuab+TTvKTaMuA/Uc1uciIWigiud/qQO9h4Up8SOpuDStHZpt6g2tzKuxOaPKJL16xZimBNeVlRdD/Xubqy36YyzDZoZTyEXC/hOKqhbD9BDfKP X-Received: by 10.220.88.204 with SMTP id b12mr55724373vcm.3.1395767911287; Tue, 25 Mar 2014 10:18:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.74.168 with HTTP; Tue, 25 Mar 2014 10:18:00 -0700 (PDT) In-Reply-To: <1395691613.66133.YahooMailNeo@web142803.mail.bf1.yahoo.com> References: <53308872.9030305@cs.tcd.ie> <533088AB.203@cs.tcd.ie> <1395691613.66133.YahooMailNeo@web142803.mail.bf1.yahoo.com> From: =?UTF-8?B?SmFtaWUgTmljb2xzb24gKOWAquW/l+aYjik=?= Date: Tue, 25 Mar 2014 10:18:00 -0700 Message-ID: To: Bill Mills Content-Type: multipart/alternative; boundary=047d7b3a92ee8ab34304f5718a57 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/oTLwDJOXU6urlhH8LpjQtPdhc_o Cc: "kitten@ietf.org" , "iana-questions@ietf.corg" , "oauth@ietf.org" Subject: Re: [kitten] [OAUTH-WG] Fwd: [IANA #731918] SASL mechanism not listed X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 17:18:40 -0000 --047d7b3a92ee8ab34304f5718a57 Content-Type: text/plain; charset=UTF-8 To be clear, Google will continue to support XOAUTH and XOAUTH2 for some time, along with OAUTHBEARER, in order to support existing clients. On Mon, Mar 24, 2014 at 1:06 PM, Bill Mills wrote: > Google used XOAUTH for it's original OAuth 1.0a based mechanism. They > used XOAUTH2 to specifically not conflict with whatever name we > standardized on for the mechanism as standardized. > > They plan, according to Ryan who's been participating on list, to > implement the standardized mechanism definition under the OAUTHBEARER > mechanism name so there should be no conflict. > > Regards, > > -bill > > > On Monday, March 24, 2014 12:34 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > > See below. I think (not quite sure) that this is better > discussed on the kitten list. > > Ta, > S. > > > > -------- Original Message -------- > Subject: [kitten] [IANA #731918] SASL mechanism not listed > Date: Mon, 24 Mar 2014 19:33:06 +0000 > From: Stephen Farrell > To: kitten@ietf.org > CC: iana-questions@iana.org > > > Hiya, > > IANA were asked the following question a while back, but I > dropped the ball;-) > > I'd appreciate your thoughts on the matter. I'm not quite > sure which registries are meant exactly though. > > (I'll also forward to the oauth WG, but not cross-post) > > Thanks, > S. > > > > The following draft describes a SASL mechanism that is in use on > GMail and should not therefore be allocated to another scheme unless > we want bad things to happen. > > http://tools.ietf.org/id/draft-murchison-sasl-login-00.txt > > The strings XOAUTH and XOAUTH2 are also being used for a preliminary > version of the OAUTH spec as well. > > The reason Google is using this particular mechanism rather than > PLAIN is that it is the one that has the widest client support: > > http://www.fehcom.de/qmail/smtpauth.html > > So it would be a real disaster if this particular code point was re-issued. > > It would probably be a good idea if every registry had a list of 'dirty' > code points that must not be reused because there are existing > applications. > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > --047d7b3a92ee8ab34304f5718a57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To be clear, Google will continue to support XOAUTH and XO= AUTH2 for some time, along with OAUTHBEARER, in order to support existing c= lients.


= On Mon, Mar 24, 2014 at 1:06 PM, Bill Mills <wmills_92105@yahoo.com= > wrote:
Google used XOAUTH for it's original OAuth 1.0a based mechanism. = =C2=A0They used XOAUTH2 to specifically not conflict with whatever name we = standardized on for the mechanism as standardized.

They plan, according to= Ryan who's been participating on list, to implement the standardized m= echanism definition under the OAUTHBEARER mechanism name so there should be= no conflict.

Regards,

-bill


On Monday, March 24, 2014 12:34 PM= , Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

See below. I think (not quite sure) that this is better
d= iscussed on the kitten list.

Ta,
S.



-------- Original Message --------
Subject: [kitten] [IAN= A #731918] SASL mechanism not listed
Date: Mon, 24 Mar 20= 14 19:33:06 +0000
From: Stephen Farrell <stephen.fa= rrell@cs.tcd.ie>
To: kit= ten@ietf.org <kitten@ietf.org>
CC: iana-questions= @iana.org <iana-questions@iana.org>


Hiya,

IANA were asked the following question a while back, but I
dropped the ball;-)

I'd = appreciate your thoughts on the matter. I'm not quite
sure which registries are meant exactly though.

(I'll also forward to the oauth WG, but not cross-post)

Tha= nks,
S.

<start>= ;

The following draft describes a SASL= mechanism that is in use on
GMail and should not therefore be allocated to another scheme unless
we want bad things to happen.

http://tools.ietf.org/id/draft-murchison-s= asl-login-00.txt

The strings XOAUTH and XOAUTH2 are also being used for a= preliminary
version of the OAUTH spec as well.

The reason Google is using this particular mec= hanism rather than
PLAIN is that it is the one that has the widest client support:

http://www.fehcom.de/qmail/smtpauth.ht= ml

So it would be a real disaster if this particular code p= oint was re-issued.

It would probably = be a good idea if every registry had a list of 'dirty'
code points that must not be reused because there are existing applications= .

<end>

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





___________________________________________= ____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




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


--047d7b3a92ee8ab34304f5718a57--