From hartmans@mit.edu Tue Mar 1 14:33:34 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2BF3A6AB7 for ; Tue, 1 Mar 2011 14:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.941 X-Spam-Level: X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHjhO-wAL-WS for ; Tue, 1 Mar 2011 14:33:33 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 6DE1D3A6A46 for ; Tue, 1 Mar 2011 14:33:31 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 48E3E20220 for ; Tue, 1 Mar 2011 17:32:02 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6C5464307; Tue, 1 Mar 2011 17:34:27 -0500 (EST) From: Sam Hartman To: kitten@ietf.org Date: Tue, 01 Mar 2011 17:34:27 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] What does it take to send naming extensions forward X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 22:33:34 -0000 I haven't seen a lot of comments on the new versions of naming extensions that Leif posted. I'd like to see this move forward. Can we start a new last call for this either at the WG or IETF level as appropriate? From cantor.2@osu.edu Tue Mar 1 17:34:22 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BB9F3A6AC3 for ; Tue, 1 Mar 2011 17:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYB+AabHyQlt for ; Tue, 1 Mar 2011 17:34:18 -0800 (PST) Received: from defang4.it.ohio-state.edu (defang4.it.ohio-state.edu [128.146.216.84]) by core3.amsl.com (Postfix) with ESMTP id 8FCB33A6A30 for ; Tue, 1 Mar 2011 17:34:18 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu ([164.107.81.41]) by defang4.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id p221ZLSY011723 for ; Tue, 1 Mar 2011 20:35:21 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([2002:a46b:5129::a46b:5129]) with mapi; Tue, 1 Mar 2011 20:31:46 -0500 From: "Cantor, Scott E." To: "kitten@ietf.org" Thread-Topic: Updated SAML-EC draft Thread-Index: AQHL2HmZ36f9nENf5Uu4iDedSMxOlg== Date: Wed, 2 Mar 2011 01:35:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <31507a66-aeca-4890-a13f-f6d9cbc36f18> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.41; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.84 Subject: [kitten] Updated SAML-EC draft X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 01:34:22 -0000 I've revised my SAML-EC mechanism proposal: https://datatracker.ietf.org/doc/draft-cantor-ietf-kitten-saml-ec/ The -01 version updates the underlying ECP profile reference to a new draft version of this profile that is progressing at OASIS. The new version of the profile adds channel binding (at the SAML layer) and "holder-of-key" support as optional add-ons. (HoK, for the SAML-oblivious, is the term of art in SAML for binding assertion flows to cryptographic proof keys instead of using bearer tokens.) I think that the channel binding material, which is based on a long thread between myself and Nico Williams last year, is sound *at the SAML layer*. However, I'm fairly certain it needs to be modified or possibly just duplicated for proper integration at the GSS-API mechanism layer, but I will need some help from domain experts to make that happen. I can outline how the SAML-based CB support works in Prague, it's fairly simple to explain. -- Scott From shawn.emery@oracle.com Wed Mar 2 00:00:52 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931AA3A6A89 for ; Wed, 2 Mar 2011 00:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSwxWjM7if2z for ; Wed, 2 Mar 2011 00:00:51 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 9D9E23A68B3 for ; Wed, 2 Mar 2011 00:00:51 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2281sL1011089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Mar 2011 08:01:56 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p227K253020509 for ; Wed, 2 Mar 2011 08:01:54 GMT Received: from abhmt005.oracle.com by acsmt355.oracle.com with ESMTP id 1100559751299052913; Wed, 02 Mar 2011 00:01:53 -0800 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Mar 2011 00:01:52 -0800 Message-ID: <4D6DF96F.6090809@oracle.com> Date: Wed, 02 Mar 2011 01:01:51 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.13) Gecko/20110130 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: kitten@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4D6DF972.00D0,ss=1,fgs=0 Subject: Re: [kitten] What does it take to send naming extensions forward X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 08:00:52 -0000 I think there is sufficient changes in the 09 version of the draft to warrant another WGLC. Shawn, kitten WG chair -- On 03/ 1/11 03:34 PM, Sam Hartman wrote: > > I haven't seen a lot of comments on the new versions of naming > extensions that Leif posted. > I'd like to see this move forward. > Can we start a new last call for this either at the WG or IETF level as > appropriate? > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From shawn.emery@oracle.com Wed Mar 2 00:05:29 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7523A68B3 for ; Wed, 2 Mar 2011 00:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZn+mfUnQR77 for ; Wed, 2 Mar 2011 00:05:28 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 9DF953A6A43 for ; Wed, 2 Mar 2011 00:05:28 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2286ViF023613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Mar 2011 08:06:32 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2286UDa016380 for ; Wed, 2 Mar 2011 08:06:30 GMT Received: from abhmt009.oracle.com by acsmt354.oracle.com with ESMTP id 1050306951299053181; Wed, 02 Mar 2011 00:06:21 -0800 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Mar 2011 00:06:21 -0800 Message-ID: <4D6DFA7C.1080401@oracle.com> Date: Wed, 02 Mar 2011 01:06:20 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.13) Gecko/20110130 Lightning/1.0b2 Thunderbird/3.1.7 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: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4D6DFA87.0063,ss=1,fgs=0 Subject: [kitten] WGLC on draft-ietf-kitten-gssapi-naming-exts-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 08:05:29 -0000 This message officially starts the 2nd Kitten Working Group Last Call for the following document: GSS-API Naming Extensions http://tools.ietf.org/html/draft-ietf-kitten-gssapi-naming-exts-09 The Working Group Last Call for this document starts today on Wednesday, March 2nd and will end on Wednesday, March 16th. Please send any comments to the Kitten mailing list or directly to the chairs. Feed-back from reviews that found no issues are also welcome. Thank you, Shawn Emery, Kitten WG chair -- From simon@josefsson.org Wed Mar 2 02:39:00 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5083A63D2 for ; Wed, 2 Mar 2011 02:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.742 X-Spam-Level: X-Spam-Status: No, score=-103.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w6zP-kOL0-c for ; Wed, 2 Mar 2011 02:39:00 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id AB96E3A659B for ; Wed, 2 Mar 2011 02:38:59 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p22AdwVv010080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 2 Mar 2011 11:40:00 +0100 From: Simon Josefsson To: "kitten\@ietf.org" References: <4D6DFA7C.1080401__858.060739892785$1299053205$gmane$org@oracle.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110302:kitten@ietf.org::p0sNwZQv86evDmUe:1qKL X-Hashcash: 1:22:110302:shawn.emery@oracle.com::dpdxM8ZxYCM9Bl6A:RZB3 Date: Wed, 02 Mar 2011 11:39:58 +0100 In-Reply-To: <4D6DFA7C.1080401__858.060739892785$1299053205$gmane$org@oracle.com> (Shawn Emery's message of "Wed, 02 Mar 2011 01:06:20 -0700") Message-ID: <87wrkhbybl.fsf@latte.josefsson.org> User-Agent: Gnus/5.110014 (No Gnus v0.14) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Subject: Re: [kitten] WGLC on draft-ietf-kitten-gssapi-naming-exts-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 10:39:01 -0000 I believe this document needs more work on the API descriptions and it is not ready for publication. I started a review with details below, but stopped when I had found too many problems. Section 7.1: o name NAME, Should be INTERNAL NAME? o display_name STRING Should be OCTET STRING? Further, it should specify memory allocation considerations like RFC 2743 does. I suggest: o display_name OCTET STRING, -- caller must release -- with GSS_Release_buffer() Section 7.1.1 is just a sketch, compare with how RFC 2744 is written. Also, the C function name should be lower-cased. Section 7.2: o name NAME Should be INTERNAL NAME again? Memory de-allocation considerations should be added for the NM_MECH and ATTRS variables, compare how RFC 2743 is written. This function outputs the set (represented as a NULL terminated array of gss_buffer_t) of attributes of a name. I don't see how this works -- gss_buffer_t is a C-language specific construct and the size of the types involved may differ depending on architecture. You want to use a language independent format here. The gss_buffer_set_t type and associated API is defined in [GFD.024] This is a normative reference, so it would help if there were a URL to the stable document in the reference section. Right now I don't know how to find the latest version of the document. I believe it is important to review that document in the IETF. The use of C language constructs at the abstract GSS-API level seems confusing to me, and I wonder if it is fully baked. Section 7.2.1: int name_is_MN, You can't return values in C with a prameter like that, add a '*'. The section needs more text, compare RFC 2744. /Simon From wmills@yahoo-inc.com Wed Mar 2 13:08:48 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4C073A6850 for ; Wed, 2 Mar 2011 13:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.514 X-Spam-Level: X-Spam-Status: No, score=-17.514 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKvtnfM-1+YA for ; Wed, 2 Mar 2011 13:08:45 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id 8F9F63A6816 for ; Wed, 2 Mar 2011 13:08:42 -0800 (PST) Received: from SP2-EX07CAS02.ds.corp.yahoo.com (sp2-ex07cas02.corp.sp2.yahoo.com [98.137.59.38]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p22L9Siw088762 for ; Wed, 2 Mar 2011 13:09:28 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS02.ds.corp.yahoo.com ([98.137.59.38]) with mapi; Wed, 2 Mar 2011 13:09:28 -0800 From: William Mills To: "kitten@ietf.org" Date: Wed, 2 Mar 2011 13:09:24 -0800 Thread-Topic: Channel binding questions. Thread-Index: AcvZHht+wZKX6/NnREOFanUicDkjOw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FFDFD7371D517847AD71FBB08F9A3156384CFDCC64SP2EX07VS06ds_" MIME-Version: 1.0 Subject: [kitten] Channel binding questions. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 21:08:48 -0000 --_000_FFDFD7371D517847AD71FBB08F9A3156384CFDCC64SP2EX07VS06ds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For Channel Binding I have a few questions: In the standard mechanism (non-CB) is defense against downgrade attacks req= uired? (I think this is a yes). Is it OK to put the downgrade defense in the same message that auth credent= ials would go in, or is it required that the CB negotiation/messaging happe= n first before any credentials are transmitted? Would it be reasonable in the context of the OAUTH mechanism to overload th= e channel binding message into the HTTP Authorization header? For this I'd= probably define an Authorization scheme for this. Another alternative in the context of the tunneled HTTP that the OAUTH mech= anism is becoming is to define a pseudo location /channel-binding and have = a client that supports channel binding send that request first. The use of= HTTP style here is simply to fall back on a single, well understood, mess= age format. Thanks, -bill --_000_FFDFD7371D517847AD71FBB08F9A3156384CFDCC64SP2EX07VS06ds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For Channel Binding I have a few questions:=

 

In the standard mechanism (non-CB) is defense against = downgrade attacks required? (I think this is a yes).

 

Is it OK to put the downgrade defense in the same mess= age that auth credentials would go in, or is it required that the CB negotiation/messaging happen first before any credentials are transmitted?<= o:p>

 

Would it be reasonable in the context of the OAUTH mec= hanism to overload the channel binding message into the HTTP Authorization header?=   For this I’d probably define an Authorization scheme for this.  =

 

Another alternative in the context of the tunneled HTT= P that the OAUTH mechanism is becoming is to define a pseudo location /channel-bin= ding and have a client that supports channel binding send that request first.&nb= sp; The use of HTTP style here is simply to fall back on a single, well underst= ood,  message format.

 

Thanks,

 

-bill

--_000_FFDFD7371D517847AD71FBB08F9A3156384CFDCC64SP2EX07VS06ds_-- From hartmans@mit.edu Wed Mar 2 14:04:47 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6F73A67B5 for ; Wed, 2 Mar 2011 14:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.908 X-Spam-Level: X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uetF+1scBH34 for ; Wed, 2 Mar 2011 14:04:45 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 06BCB3A6889 for ; Wed, 2 Mar 2011 14:04:44 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 45D9A2011F; Wed, 2 Mar 2011 17:03:12 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8B0824307; Wed, 2 Mar 2011 17:05:36 -0500 (EST) From: Sam Hartman To: Simon Josefsson References: <4D6DFA7C.1080401__858.060739892785$1299053205$gmane$org@oracle.com> <87wrkhbybl.fsf@latte.josefsson.org> Date: Wed, 02 Mar 2011 17:05:36 -0500 In-Reply-To: <87wrkhbybl.fsf@latte.josefsson.org> (Simon Josefsson's message of "Wed, 02 Mar 2011 11:39:58 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-gssapi-naming-exts-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:04:48 -0000 >>>>> "Simon" == Simon Josefsson writes: Simon> I believe this document needs more work on the API Simon> descriptions and it is not ready for publication. I started Simon> a review with details below, but stopped when I had found too Simon> many problems. Simon, thanks for your feedback. I spoke to Nico and we believe that you've made a good case for reviewing section 7 of the draft prior to publication. I'll see if we can get you a copy of the buffer set proposal. If there is a good URI to include, I certainly would be happy to do that. Can I get you to take a look at http://www.ggf.org/documents/GFD.24.pdf and see if that's the right API? I believe it is. From simon@josefsson.org Fri Mar 4 06:44:43 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BDC43A6864 for ; Fri, 4 Mar 2011 06:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqeCDUU0hSPu for ; Fri, 4 Mar 2011 06:44:42 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 9BE503A67F4 for ; Fri, 4 Mar 2011 06:44:41 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p24EjhwS019648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 4 Mar 2011 15:45:45 +0100 From: Simon Josefsson To: Sam Hartman References: <4D6DFA7C.1080401__858.060739892785$1299053205$gmane$org@oracle.com> <87wrkhbybl.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110304:kitten@ietf.org::7c8DgX9zuFcB4/cu:6fhm X-Hashcash: 1:22:110304:hartmans-ietf@mit.edu::nl6tFxK2f+V6uVVJ:BGII Date: Fri, 04 Mar 2011 15:45:43 +0100 In-Reply-To: (Sam Hartman's message of "Wed, 02 Mar 2011 17:05:36 -0500") Message-ID: <87fwr3kkq0.fsf@latte.josefsson.org> User-Agent: Gnus/5.110014 (No Gnus v0.14) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-gssapi-naming-exts-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 14:44:43 -0000 Sam Hartman writes: > Can I get you to take a look at http://www.ggf.org/documents/GFD.24.pdf > and see if that's the right API? > I believe it is. Thanks for the link. That document says the latest version of it is available from https://forge.gridforum.org/projects/gsi-wg but if following that link and navigating to the documents I find draft-ggf-gss-extensions-12 linked from https://forge.gridforum.org/sf/docman/do/listDocuments/projects.gsi-wg/docman.root but that version looks somewhat different to the document above. Two concerns: 1) draft-ietf-kitten-gssapi-naming-exts is referencing the C-specific gss_buffer_set_t (I assume, it actually says gss_buffer_t but that looks like a typo) in the abstract GSS-API function definition. That looks like a layer violation to me, similar to a problem clarified in 5554. 2) What parts of GFD.024 are intended to be normative? It is a normative reference from our document. The PDF is marked as experimental and it dates from 2004. It hasn't gone through any IETF review. I would prefer it the normative and relevant parts of it could be extracted and submitted and published through the IETF, so we have a stable reference. It looks like the document could use some improvements as well -- for example, there is security considerations that applies to the buffer set API. Of course, the GGF needs to agree to re-licensing the document. /Simon From wmills@yahoo-inc.com Fri Mar 4 13:09:15 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32AA83A6A31 for ; Fri, 4 Mar 2011 13:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.523 X-Spam-Level: X-Spam-Status: No, score=-17.523 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1klyTVjgcR6 for ; Fri, 4 Mar 2011 13:09:14 -0800 (PST) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 874C53A6A2B for ; Fri, 4 Mar 2011 13:09:14 -0800 (PST) Received: from SP2-EX07CAS02.ds.corp.yahoo.com (sp2-ex07cas02.corp.sp2.yahoo.com [98.137.59.38]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p24LA5IE035518 for ; Fri, 4 Mar 2011 13:10:05 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS02.ds.corp.yahoo.com ([98.137.59.38]) with mapi; Fri, 4 Mar 2011 13:10:05 -0800 From: William Mills To: "kitten@ietf.org" Date: Fri, 4 Mar 2011 13:10:03 -0800 Thread-Topic: OAuth SASL mec hanism and Channel binding. Thread-Index: AcvasIflWG+ySTufSrqs8WzHvf7REA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FFDFD7371D517847AD71FBB08F9A3156384CFDD261SP2EX07VS06ds_" MIME-Version: 1.0 Cc: Tim Showalter Subject: [kitten] OAuth SASL mec hanism and Channel binding. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 21:09:15 -0000 --_000_FFDFD7371D517847AD71FBB08F9A3156384CFDD261SP2EX07VS06ds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There was some discussion about channel binding being a requirement for the= proposed OAuth SASL mechanism. The mechanism as it stands does not have = any message integrity guarantee. As I understand channel binding it requi= res message integrity guarantees to be provably correct, otherwise a MITM c= ould simply alter the channel binding messages if that MITM is able to pars= e down into the protocol. Some of the auth schemes on the OAuth 2 framework are capable of message in= tegrity, but not all. It would be possible to define channel binding for = just those auth schemes. Is removing channel binding from the OAuth mechanism a deal breaker? Thanks, -bill --_000_FFDFD7371D517847AD71FBB08F9A3156384CFDD261SP2EX07VS06ds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There was some discussion about channel binding being = a requirement for the proposed OAuth SASL mechanism.   The mechanis= m as it stands does not have any message integrity guarantee.   As I understand channel binding it requires message integrity guarantees to be p= rovably correct, otherwise a MITM could simply alter the channel binding messages i= f that MITM is able to parse down into the protocol.

 

Some of the auth schemes on the OAuth 2 framework are capable of message integrity, but not all.  It would be  possible= to define channel binding for just those auth schemes.

 

Is removing channel binding from the OAuth mechanism a= deal breaker? 

 

Thanks,

 

-bill

--_000_FFDFD7371D517847AD71FBB08F9A3156384CFDD261SP2EX07VS06ds_-- From shawn.emery@oracle.com Tue Mar 8 22:05:45 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1501C3A683F for ; Tue, 8 Mar 2011 22:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ki0XI4-bJCrc for ; Tue, 8 Mar 2011 22:05:44 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 11CCC3A683D for ; Tue, 8 Mar 2011 22:05:43 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2966veP020448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Mar 2011 06:06:58 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2966tp8005082 for ; Wed, 9 Mar 2011 06:06:55 GMT Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 1070400221299650726; Tue, 08 Mar 2011 22:05:26 -0800 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Mar 2011 22:05:26 -0800 Message-ID: <4D7718A4.4020409@oracle.com> Date: Tue, 08 Mar 2011 23:05:24 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.13) Gecko/20110214 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: multipart/alternative; boundary="------------060900000801070306070509" X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4D771900.00E9,ss=1,fgs=0 Subject: [kitten] IETF 80 - Kitten Agenda X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 06:05:45 -0000 This is a multi-part message in MIME format. --------------060900000801070306070509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here is the draft agenda for the upcoming session in Prague: http://www.ietf.org/proceedings/80/agenda/kitten.txt Please let us know if you would like to add items to the session by March 21st. Shawn - kitten co-chair -- --------------060900000801070306070509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Here is the draft agenda for the upcoming session in Prague:

http://www.ietf.org/proceedings/80/agenda/kitten.txt

Please let us know if you would like to add items to the session by March 21st.

Shawn - kitten co-chair
--
--------------060900000801070306070509-- From shawn.emery@oracle.com Tue Mar 8 22:59:43 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898553A683D for ; Tue, 8 Mar 2011 22:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4txRj+9AexCv for ; Tue, 8 Mar 2011 22:59:41 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E75D23A681F for ; Tue, 8 Mar 2011 22:59:40 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2970sgi024508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Mar 2011 07:00:56 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p293r7WV015607 for ; Wed, 9 Mar 2011 07:00:53 GMT Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 1070549411299654024; Tue, 08 Mar 2011 23:00:24 -0800 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Mar 2011 23:00:23 -0800 Message-ID: <4D772586.60409@oracle.com> Date: Wed, 09 Mar 2011 00:00:22 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.13) Gecko/20110214 Lightning/1.0b2 Thunderbird/3.1.7 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: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4D7725A6.0083,ss=1,fgs=0 Subject: [kitten] WGLC on draft-ietf-kitten-sasl-openid-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 06:59:43 -0000 This message officially starts the Kitten Working Group Last Call for the following document: A SASL & GSS-API Mechanism for OpenID http://tools.ietf.org/html/draft-ietf-kitten-sasl-openid-01 The Working Group Last Call for this document starts today on Wednesday, March 9th and will end on Wednesday, March 30th. Please send any comments to the Kitten mailing list or directly to the chairs. Feed-back from reviews that found no issues are also welcome. Thank you, Shawn - kitten co-chair -- From turners@ieca.com Wed Mar 9 07:07:30 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4803A6881 for ; Wed, 9 Mar 2011 07:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-RhHoFJrpa0 for ; Wed, 9 Mar 2011 07:07:29 -0800 (PST) Received: from nm24.bullet.mail.ac4.yahoo.com (nm24.bullet.mail.ac4.yahoo.com [98.139.52.221]) by core3.amsl.com (Postfix) with SMTP id 1765B3A6821 for ; Wed, 9 Mar 2011 07:07:29 -0800 (PST) Received: from [98.139.52.196] by nm24.bullet.mail.ac4.yahoo.com with NNFMP; 09 Mar 2011 15:08:42 -0000 Received: from [98.139.52.156] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 09 Mar 2011 15:08:42 -0000 Received: from [127.0.0.1] by omp1039.mail.ac4.yahoo.com with NNFMP; 09 Mar 2011 15:08:42 -0000 X-Yahoo-Newman-Id: 229315.89329.bm@omp1039.mail.ac4.yahoo.com Received: (qmail 39592 invoked from network); 9 Mar 2011 15:08:41 -0000 Received: from thunderfish.local (turners@71.191.3.104 with plain) by smtp115.biz.mail.mud.yahoo.com with SMTP; 09 Mar 2011 07:08:41 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: wQvcW0MVM1nhyPRSit0RRZFDIMv8Fl66YgUD1vl2ZsVnyB0 jLx3BOrCMYYVJ8dcdOAv3dPBpIb0ZhIDrza7EE4.xMPCsZGVZOc_D9ekx69v 5.PeWfa2gbIvwHBXYazrEbzEeu9gegepCP2D2M_Pr0MSSw2vCG6VYbbOhatw EbdlYLUwcdp67td8fDK.3fJzg2oK3wHaRNWEbkkrcsgYwcrVs8LeoV1GrJbJ UB9F4ireAZELYOmrvDoLq5gWCFWnhws4wSmxUcJWiI4izd6Bv1046f88h_Lf ojkWpLtExLly4Dj6fZKNSpSExnfmyc3UoBqpkdHEmpA.9dxwS81sXMOTA6hW bdIWhuW_9BgCg_CQtcIGP691M5gWiPNmMlui186dNxQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D7797F8.1000401@ieca.com> Date: Wed, 09 Mar 2011 10:08:40 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Simon Josefsson References: <4CF66B03.7030601@ieca.com> <7FCA3014207EFF8878A7FC5D__1181.61178329519$1291243077$gmane$org@96B2F16665FF96BAE59E9B90> <87bp54gdbi.fsf@latte.josefsson.org> <87lj47e60k.fsf@latte.josefsson.org> <87zkqv7vh1.fsf@latte.josefsson.org> In-Reply-To: <87zkqv7vh1.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5802 (2652) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:07:30 -0000 So to close the loop on this one: I'm going to edit the errata to replace the text suggested by Jehan with the text suggested by Simon. spt On 1/20/11 4:52 AM, Simon Josefsson wrote: > Jehan Pagès writes: > >> After: >> ---------------------------------- >> 9. Security Considerations >> >> >> >> If an attacker obtains the authentication information from the >> authentication repository and either eavesdrops on one authentication >> exchange or impersonates a server, the attacker gains the ability to >> impersonate that user to all servers providing SCRAM access using the >> same hash function, password, iteration count, and salt. For this >> reason, it is important to use randomly generated salt values. >> ----------------------------------- >> Add the following paragraph: >> ----------------------------------- >> Though an empty string is theoretically a perfectly valid random >> value, as long as it has the same probability to be generated as any >> other string, in practice this special case may weaken the salted >> password. Consequently a server implementation should wisely check a >> newly generated salt for not being empty, and generate it again if >> necessary before any further step, whereas a client implementation >> might refuse to authenticate when an empty salt is received. >> ----------------------------------- > > I think we should add something that implementations should have a > minimum accepted salt length, for security reasons. A 1 byte octet salt > does not make sense. I don't think we want to say that all strings > should have the same probability to be generated -- an implementation > that picks good random 15 character strings for salt is OK but there is > 0 probability for that implementation to generate a 14 character string, > so it would fail your language. > > I suggest to add a sentence after > > If an attacker obtains the authentication information from the > authentication repository and either eavesdrops on one authentication > exchange or impersonates a server, the attacker gains the ability to > impersonate that user to all servers providing SCRAM access using the > same hash function, password, iteration count, and salt. For this > reason, it is important to use randomly generated salt values. > > that says > > Further, implementations are RECOMMENDED to reject salt values > shorter than 2 characters and MAY reject even longer salt values if > they are considered to be insufficient. See [RFC4086] on generating > randomness. > > /Simon > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From jehan.marmottard@gmail.com Sun Mar 13 03:51:59 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CAAF3A69ED for ; Sun, 13 Mar 2011 03:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.177 X-Spam-Level: X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfRrOwg52D8K for ; Sun, 13 Mar 2011 03:51:58 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id ECDE23A68C6 for ; Sun, 13 Mar 2011 03:51:57 -0700 (PDT) Received: by wwa36 with SMTP id 36so3261489wwa.13 for ; Sun, 13 Mar 2011 03:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fFoHlbYRSJaBA/naIRDJPqA/J2+JOHZOaqGeKPCx7H8=; b=JBMJ6Tm2EG71P1xglInirZFekGSl03DGeXIKD1m1LFQ4K2yTMBrQZKDlu49VrGR0LM azOB9Hm3bpAXptA4ogmWVSrN1SpVhb4AzFjWVBB+oXOpeCwvyW07bXtFp+xZjCXkHnje hnpvA9oqUqtUrHdO5GRh4yhIWA2MeK28rwKWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ji3TKZhkpCwtchgOrcYC6+Jlk4+k+GKAUEps8EefbMI5sGXnlBTVoumPwJZ/Z+2jP/ jggyB2tgP9DAmsxqJTdt1SmqHxo9UaVOKRYYxJyzWdclQFYOZUYYtKf+Lc5tl94MoTSy nlEDU/yzNhgDAk/sm1/uhYHL0erMS3SwBVNng= MIME-Version: 1.0 Received: by 10.216.230.21 with SMTP id i21mr10755892weq.111.1300013599051; Sun, 13 Mar 2011 03:53:19 -0700 (PDT) Received: by 10.216.171.131 with HTTP; Sun, 13 Mar 2011 03:53:19 -0700 (PDT) In-Reply-To: <4D7797F8.1000401@ieca.com> References: <4CF66B03.7030601@ieca.com> <7FCA3014207EFF8878A7FC5D__1181.61178329519$1291243077$gmane$org@96B2F16665FF96BAE59E9B90> <87bp54gdbi.fsf@latte.josefsson.org> <87lj47e60k.fsf@latte.josefsson.org> <87zkqv7vh1.fsf@latte.josefsson.org> <4D7797F8.1000401@ieca.com> Date: Sun, 13 Mar 2011 19:53:19 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Sean Turner Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Simon Josefsson Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5802 (2652) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 10:51:59 -0000 Hi, On Thu, Mar 10, 2011 at 12:08 AM, Sean Turner wrote: > So to close the loop on this one: =A0I'm going to edit the errata to repl= ace > the text suggested by Jehan with the text suggested by Simon. I would say I agree. :-) Regards, Jehan > spt > > On 1/20/11 4:52 AM, Simon Josefsson wrote: >> >> Jehan Pag=E8s =A0writes: >> >>> After: >>> ---------------------------------- >>> 9. Security Considerations >>> >>> >>> >>> =A0 =A0If an attacker obtains the authentication information from the >>> =A0 =A0authentication repository and either eavesdrops on one authentic= ation >>> =A0 =A0exchange or impersonates a server, the attacker gains the abilit= y to >>> =A0 =A0impersonate that user to all servers providing SCRAM access usin= g the >>> =A0 =A0same hash function, password, iteration count, and salt. =A0For = this >>> =A0 =A0reason, it is important to use randomly generated salt values. >>> ----------------------------------- >>> Add the following paragraph: >>> ----------------------------------- >>> Though an empty string is theoretically a perfectly valid random >>> value, as long as it has the same probability to be generated as any >>> other string, in practice this special case may weaken the salted >>> password. Consequently a server implementation should wisely check a >>> newly generated salt for not being empty, and generate it again if >>> necessary before any further step, whereas a client implementation >>> might refuse to authenticate when an empty salt is received. >>> ----------------------------------- >> >> I think we should add something that implementations should have a >> minimum accepted salt length, for security reasons. =A0A 1 byte octet sa= lt >> does not make sense. =A0I don't think we want to say that all strings >> should have the same probability to be generated -- an implementation >> that picks good random 15 character strings for salt is OK but there is >> 0 probability for that implementation to generate a 14 character string, >> so it would fail your language. >> >> I suggest to add a sentence after >> >> =A0 =A0 If an attacker obtains the authentication information from the >> =A0 =A0 authentication repository and either eavesdrops on one authentic= ation >> =A0 =A0 exchange or impersonates a server, the attacker gains the abilit= y to >> =A0 =A0 impersonate that user to all servers providing SCRAM access usin= g the >> =A0 =A0 same hash function, password, iteration count, and salt. =A0For = this >> =A0 =A0 reason, it is important to use randomly generated salt values. >> >> that says >> >> =A0 =A0 Further, implementations are RECOMMENDED to reject salt values >> =A0 =A0 shorter than 2 characters and MAY reject even longer salt values= if >> =A0 =A0 they are considered to be insufficient. =A0See [RFC4086] on gene= rating >> =A0 =A0 randomness. >> >> /Simon >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten >> > From jehan.marmottard@gmail.com Sun Mar 13 04:48:46 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8FA33A69ED for ; Sun, 13 Mar 2011 04:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsWRwRvfAb+v for ; Sun, 13 Mar 2011 04:48:45 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 140333A6958 for ; Sun, 13 Mar 2011 04:48:43 -0700 (PDT) Received: by wwa36 with SMTP id 36so3278215wwa.13 for ; Sun, 13 Mar 2011 04:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mf8haAtX3uwPgMA4KhvkzFGxfHWuM2rQnurKmHEgHok=; b=gCt4JTueKnYQ5ji8hAYE3z7MQHL1yXv2zj+qBskF9LYHV9sOqKj61eBXU4cMnVfEuO xXVzLL4pU3wfO69YAvDquqCn4mUN3V1DbTPz6ORBlW5KIRDANDA4bLZgwNcbP6fkLAM+ cfHpGCJ29iUMBUi8Lcsb0n1ilADmAFR43IByE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Z0m5Mrp71TA33/a/KkriEabJD6Ebgb3n2putPrtSyzHw/hdG/RjidkaUpJM4OUzE6/ zqVRD6aFnP2Ikt4C0hb7I/woksPyjbGLMTIThbjTgIguheAiPZnZLvBJnqSeF/trt8T+ b5v+jsTkGWUtxkFv6lRz9HuFI9uYMWUK9cAWU= MIME-Version: 1.0 Received: by 10.216.230.21 with SMTP id i21mr10799950weq.111.1300017005401; Sun, 13 Mar 2011 04:50:05 -0700 (PDT) Received: by 10.216.171.131 with HTTP; Sun, 13 Mar 2011 04:50:05 -0700 (PDT) In-Reply-To: References: <4CF91652.2080104@googlemail.com> <25128_1291395225_oB3Griia031936_AANLkTi=NnaG=a-CaiNKFVSsx=8tzKd_Q87wnAJ3CbuXY@mail.gmail.com> <5A6498C4F1AEDE3EC2DDB578@minbar.fac.cs.cmu.edu> Date: Sun, 13 Mar 2011 20:50:05 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Jeffrey Hutzelman , kitten@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [kitten] RFC5802: question about unknown-user error X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 11:48:46 -0000 Hi, again I come after so long time. Sorry for the delay. 2011/1/20 Jehan Pag=E8s : > Hi, > > On Tue, Dec 7, 2010 at 6:52 AM, Jeffrey Hutzelman wrote: >> --On Saturday, December 04, 2010 01:53:39 AM +0900 Jehan Pag=E8s >> wrote: >> >>> I agree about this, but first we can fix this in SCRAM by removing the >>> unknown-user error >> >> No. =A0Not reporting unknown-user is a policy preference, and one which = the >> protocol already permits. =A0You now propose to encode your policy prefe= rence >> into the protocol, thereby usurping the operator's authority to set poli= cy. >> >> -- Jeff >> > > This is why in the end, I was proposing not to modify the protocol but > to make it a security note. I quote myself: The other day, I was rereading through the RFC 4422 (SASL) and I saw this line, section "3.6 Authentication Outcome". I don't know why it did not hit me before: =AB It is also important that the server can be configured such that the outcome message will not distinguish between a valid user with invalid credentials and an invalid user. =BB So that's basically exactly what I propose in SCRAM which, as a SASL mechanism should then follow its directives! Currently in SCRAM we drop a list of errors without any security directives on them. And one of these errors simply tell that the user is invalid (unknown-user)! I think it is worth to add the security directive for servers to be configurable for showing or not this error (the finale decision then later depending on the operator's choice, needs or policy preferences). > =AB > So I think this would deserve a security note telling implementers > they can implement this way to avoid data leak. I will try to make a > proposition later. > =BB > > Then it is up to the implementers and/or the configuration of the > server, then to the operators (for instance during installation, you > may like to test with more informative errors, then once in > production, you switch on "secure" configuration not to give away > username's information with errors). > So at least as a security note, expose this concern, give > alternatives, and leave implementers/operators decide how they wish to > do and what they set as higher importance. > > Without a security note about this, everybody would probably implement > it exactly as it is currently, then there will be no different "policy > preferences" to choose from by the operator. > > I will come later with a text proposition exposing both logics and > their respective advantages as discussed on this thread, then you can > tell me. > Thanks. So here is my proposition: in section 9. Security Considerations, add the following text: =AB As specified in [RFC4422] (section 3.6), "it is also important that the server can be configured such that the outcome message will not distinguish between a valid user with invalid credentials and an invalid user", hence in particular that the error value "unknown-user" may be easily replaced by "other-error" if required by an operator's policy. More generally a server should be configurable so that any error which could lead to information disclosure can be replaced by "other-error". =BB And as an additional note now. Actually when I re-re-read the RFC4422, it says clearly: =AB 3.6. Authentication Outcome At the conclusion of the authentication exchange, the server sends a message, the particulars of which are protocol specific, to the client indicating the outcome of the exchange. [...] The protocol may include an optional additional data field in this outcome message. *This field can only include additional data when the outcome is successful.* [...] The outcome message provided by the server can provide a way for the client to distinguish between errors [...] =BB What I understand here is that the error should not be dealt on SASL level but on the higher level protocol. For instance in XMPP, we indeed give error on XMPP level only. So I think the whole error list in SCRAM as additional data to be sent on failed outcome is violating the SASL RFC. If such an error is to be generated by the authentication module of the server, it should be meant to be informational for the server (which after does whatever it wants with it, like forwarding the error if the protocol allows sending errors on outcome, filtering out information-disclosure errors, and so on). Hence I wonder if this list should not be removed from the Formal Syntax (section 7) because it does not belong to the SASL exchange itself (as forbidden by RFC4422) and moved to another section as error information from an authentication module to a server. And the security consideration I propose still holds here if the server was to eventually forward this error. Regards, Jehan From simon@josefsson.org Sun Mar 13 05:02:46 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79F6B3A6958 for ; Sun, 13 Mar 2011 05:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.338 X-Spam-Level: X-Spam-Status: No, score=-103.338 tagged_above=-999 required=5 tests=[AWL=-1.039, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0L8rzGY8iex for ; Sun, 13 Mar 2011 05:02:45 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 3AA983A68CF for ; Sun, 13 Mar 2011 05:02:44 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p2DC3oAK018394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 13 Mar 2011 13:03:53 +0100 From: Simon Josefsson To: Jehan =?iso-8859-1?Q?Pag=E8s?= References: <4CF91652.2080104@googlemail.com> <25128_1291395225_oB3Griia031936_AANLkTi=NnaG=a-CaiNKFVSsx=8tzKd_Q87wnAJ3CbuXY@mail.gmail.com> <5A6498C4F1AEDE3EC2DDB578@minbar.fac.cs.cmu.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110313:jhutz@cmu.edu::zLJa6TujOqguqYEh:7cz X-Hashcash: 1:22:110313:jehan.marmottard@gmail.com::sh8rs3c0TgiuhKCc:2JoO X-Hashcash: 1:22:110313:kitten@ietf.org::n3rGf4aBN09HU75c:9nM7 Date: Sun, 13 Mar 2011 13:03:49 +0100 In-Reply-To: ("Jehan =?iso-8859-1?Q?Pag=E8s=22's?= message of "Sun, 13 Mar 2011 20:50:05 +0900") Message-ID: <874o775isa.fsf@latte.josefsson.org> User-Agent: Gnus/5.110014 (No Gnus v0.14) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] RFC5802: question about unknown-user error X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 12:02:46 -0000 Jehan Pagès writes: > The protocol may include an optional additional data field in this > outcome message. *This field can only include additional data when > the outcome is successful.* I believe you are right and that additional error codes aren't permitted. > Hence I wonder if this list should not be removed from the Formal > Syntax (section 7) because it does not belong to the SASL exchange > itself (as forbidden by RFC4422) and moved to another section as error > information from an authentication module to a server. My implementation (GNU SASL) never generates (or parse) error codes. How do other SCRAM implementations behave? I always thought of the error codes as an unnecessary complication of the protocol, but since they are optional I have mentally just ignored that part of the specification. I wouldn't oppose removing them from RFC 5802bis. /Simon From alexey.melnikov@isode.com Sun Mar 13 09:22:41 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA9D3A69DB for ; Sun, 13 Mar 2011 09:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLZY1bBKPe+Y for ; Sun, 13 Mar 2011 09:22:04 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 229ED3A69D7 for ; Sun, 13 Mar 2011 09:22:04 -0700 (PDT) Received: from [188.28.107.172] (188.28.107.172.threembb.co.uk [188.28.107.172]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 13 Mar 2011 16:23:23 +0000 Message-ID: <4D7CEF5B.9020202@isode.com> Date: Sun, 13 Mar 2011 16:22:51 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Simon Josefsson References: <4CF91652.2080104@googlemail.com> <25128_1291395225_oB3Griia031936_AANLkTi=NnaG=a-CaiNKFVSsx=8tzKd_Q87wnAJ3CbuXY@mail.gmail.com> <5A6498C4F1AEDE3EC2DDB578@minbar.fac.cs.cmu.edu> <874o775isa.fsf@latte.josefsson.org> In-Reply-To: <874o775isa.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] RFC5802: question about unknown-user error X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 16:22:41 -0000 Simon Josefsson wrote: >Jehan Pag=E8s writes: > =20 > >> The protocol may include an optional additional data field in this >> outcome message. *This field can only include additional data when >> the outcome is successful.* >> =20 >> >I believe you are right and that additional error codes aren't >permitted. > =20 > >>Hence I wonder if this list should not be removed from the Formal >>Syntax (section 7) because it does not belong to the SASL exchange >>itself (as forbidden by RFC4422) and moved to another section as error >>information from an authentication module to a server. >> =20 >> >My implementation (GNU SASL) never generates (or parse) error codes. >How do other SCRAM implementations behave? > =20 > My implementation doesn't do that either. I think Nico wanted to have them for GSS-API implementations. >I always thought of the error codes as an unnecessary complication of >the protocol, but since they are optional I have mentally just ignored >that part of the specification. I wouldn't oppose removing them from >RFC 5802bis. > I wouldn't be opposed to that either but I want to hear what Nico has to=20 say first. From simon@josefsson.org Mon Mar 14 10:28:42 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9D703A6DD3 for ; Mon, 14 Mar 2011 10:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.494 X-Spam-Level: X-Spam-Status: No, score=-103.494 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFI6Xq6e9jiG for ; Mon, 14 Mar 2011 10:28:38 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id A4E423A6D9D for ; Mon, 14 Mar 2011 10:28:37 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p2EHTsKT015736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 14 Mar 2011 18:29:55 +0100 X-Hashcash: 1:22:110314:kitten@ietf.org::2GCAc5JTpzpqlu3Q:U7Jz From: Simon Josefsson To: kitten@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Mon, 14 Mar 2011 18:29:54 +0100 Message-ID: <87d3ltfw4t.fsf@latte.josefsson.org> User-Agent: Gnus/5.110014 (No Gnus v0.14) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Subject: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 17:28:42 -0000 I know this document has expired, but I don't recall if there were any discussion or conclusion on it. The APIs are implemented and deployed in Heimdal and Shishi for some time now (years), and the calls are useful for GS2 implementers. Is there interest in moving this forward in this WG? I believe it makes sense to at least publish it as informational because it is widely deployed. http://tools.ietf.org/html/draft-josefsson-gss-capsulate-01 /Simon From chris.newman@oracle.com Mon Mar 14 14:02:54 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6D4B3A6EE1 for ; Mon, 14 Mar 2011 14:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.35 X-Spam-Level: X-Spam-Status: No, score=-104.35 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HxyWmzPPkwD for ; Mon, 14 Mar 2011 14:02:54 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id C39D43A6AA5 for ; Mon, 14 Mar 2011 14:02:53 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p2EL4HHl004967 for ; Mon, 14 Mar 2011 21:04:17 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.4) with ESMTP id p2EL4Hqk010425 for ; Mon, 14 Mar 2011 14:04:17 -0700 (PDT) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=utf-8; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.sfbay.sun.com (Oracle Communications Messaging Exchange Server 7u5-2.03 64bit (built Feb 6 2011)) with ESMTPA id <0LI200M30FV29S00@gotmail.sfbay.sun.com> for kitten@ietf.org; Mon, 14 Mar 2011 14:04:16 -0700 (PDT) Date: Mon, 14 Mar 2011 14:04:14 -0700 From: Chris Newman To: =?UTF-8?Q?Jehan_Pag=C3=A8s?= , Jeffrey Hutzelman , kitten@ietf.org Message-id: <0083F29703B421CF922D1CA7@96B2F16665FF96BAE59E9B90> In-reply-to: References: <4CF91652.2080104@googlemail.com> <25128_1291395225_oB3Griia031936_AANLkTi=NnaG=a-CaiNKFVSsx=8tzKd_Q87wnAJ3CbuXY@mail.gmail.com> <5A6498C4F1AEDE3EC2DDB578@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-transfer-encoding: quoted-printable Subject: Re: [kitten] RFC5802: question about unknown-user error X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 21:02:55 -0000 --On March 13, 2011 20:50:05 +0900 Jehan Pag=C3=A8s=20 wrote: > =C2=AB > It is also > important that the server can be configured such that the outcome > message will not distinguish between a valid user with invalid > credentials and an invalid user. > =C2=BB > > So that's basically exactly what I propose in SCRAM which, as a SASL > mechanism should then follow its directives! Currently in SCRAM we > drop a list of errors without any security directives on them. Of course to implement SCRAM according to specification, one also has to=20 implement RFC 4422 so the above rule applies. Having the error as an option = is not contradictory to the rule. I'm supportive of repeating the RFC 4422=20 security advice in SCRAM or making the reference to it clearer. > =C2=AB > 3.6. Authentication Outcome > > > At the conclusion of the authentication exchange, the server sends a > message, the particulars of which are protocol specific, to the > client indicating the outcome of the exchange. > [...] > The protocol may include an optional additional data field in this > outcome message. *This field can only include additional data when > the outcome is successful.* > [...] > The outcome message provided by the server can provide a way for the > client to distinguish between errors [...] > =C2=BB > > What I understand here is that the error should not be dealt on SASL > level but on the higher level protocol. For instance in XMPP, we > indeed give error on XMPP level only. > So I think the whole error list in SCRAM as additional data to be sent > on failed outcome is violating the SASL RFC. It's not an RFC violation (particularly due to the wording of 5.2-2b in RFC = 5802), one merely has to add an additional round-trip to the SASL exchange=20 in order to communicate the error information. If I implement the error=20 codes (and I might since I'm a big fan of additional diagnostics and the=20 application protocols that use SASL don't always have enough standardized=20 authentication diagnostics) then there will be an option to turn the extra=20 round trip off. I'm not opposed to removing the SCRAM-layer errors in a revision,=20 particularly if they fail the multiple interoperable implementation test=20 (and there's a good chance they will since SCRAM clients may not handle the = extra round-trip correctly if they've never been tested against a server to = does it). - Chris From hartmans@mit.edu Tue Mar 15 05:07:01 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59AD23A6BC3 for ; Tue, 15 Mar 2011 05:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eul8psub9ZZ4 for ; Tue, 15 Mar 2011 05:07:00 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 428303A6ACA for ; Tue, 15 Mar 2011 05:07:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9AF2020239; Tue, 15 Mar 2011 08:05:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CEE944331; Tue, 15 Mar 2011 08:07:41 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <87d3ltfw4t.fsf@latte.josefsson.org> Date: Tue, 15 Mar 2011 08:07:41 -0400 In-Reply-To: <87d3ltfw4t.fsf@latte.josefsson.org> (Simon Josefsson's message of "Mon, 14 Mar 2011 18:29:54 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 12:07:01 -0000 I was not aware of the existence of this draft before now. It does seem like a good thing to standardize. From jehan.marmottard@gmail.com Tue Mar 15 11:32:18 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 040473A6B1C for ; Tue, 15 Mar 2011 11:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgUVkcBP0HPp for ; Tue, 15 Mar 2011 11:32:16 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 76F683A6974 for ; Tue, 15 Mar 2011 11:32:16 -0700 (PDT) Received: by wyb42 with SMTP id 42so928663wyb.31 for ; Tue, 15 Mar 2011 11:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1RszbXHq9ebNFVTx0VWuiDaSpqyer92lktHL1Pqs9Ps=; b=hLNquRAaUAKfLFXqgQRylSOwApVnV5y7+ktmlTOEj2Zmqnp45BPnY22cWjaa/19kDr W1h0je7Nq/LvYjVLJWBJLvdDQBvRep7iBrBQdXAqr9gUF34rVIUHliWDg5ndFavjo5Zk PQEEwN4OWhUYRhYnDgmY3/w6m08ZlG8PTm1m4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RCs54u9BCCPo894jdy4EsLH+w2PqLCVrkf/ZlSw4HJREkivztg5+8FxxU2UxX6xIG9 CFLWWhah/ejLS2OXb7WMeTUX7F1/4lhzS/wmdhtYJgZcXtJh7fnUIgedTRyxq2bujczJ 7hyBpwomsThCynpUjQE5nvL5sAL9jm3kpySKM= MIME-Version: 1.0 Received: by 10.216.59.139 with SMTP id s11mr3838930wec.109.1300214021057; Tue, 15 Mar 2011 11:33:41 -0700 (PDT) Received: by 10.216.175.20 with HTTP; Tue, 15 Mar 2011 11:33:40 -0700 (PDT) In-Reply-To: <0083F29703B421CF922D1CA7@96B2F16665FF96BAE59E9B90> References: <4CF91652.2080104@googlemail.com> <25128_1291395225_oB3Griia031936_AANLkTi=NnaG=a-CaiNKFVSsx=8tzKd_Q87wnAJ3CbuXY@mail.gmail.com> <5A6498C4F1AEDE3EC2DDB578@minbar.fac.cs.cmu.edu> <0083F29703B421CF922D1CA7@96B2F16665FF96BAE59E9B90> Date: Wed, 16 Mar 2011 03:33:40 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Chris Newman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] RFC5802: question about unknown-user error X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 18:32:18 -0000 Hi, On Tue, Mar 15, 2011 at 6:04 AM, Chris Newman wro= te: > --On March 13, 2011 20:50:05 +0900 Jehan Pag=E8s > wrote: >> >> =AB >> =A0 It is also >> =A0 important that the server can be configured such that the outcome >> =A0 message will not distinguish between a valid user with invalid >> =A0 credentials and an invalid user. >> =BB >> >> So that's basically exactly what I propose in SCRAM which, as a SASL >> mechanism should then follow its directives! Currently in SCRAM we >> drop a list of errors without any security directives on them. > > Of course to implement SCRAM according to specification, one also has to > implement RFC 4422 so the above rule applies. Having the error as an opti= on > is not contradictory to the rule. I'm supportive of repeating the RFC 442= 2 > security advice in SCRAM or making the reference to it clearer. Good. >> =AB >> 3.6. Authentication Outcome >> >> >> At the conclusion of the authentication exchange, the server sends a >> =A0 message, the particulars of which are protocol specific, to the >> =A0 client indicating the outcome of the exchange. >> =A0 [...] >> =A0 The protocol may include an optional additional data field in this >> =A0 outcome message. =A0*This field can only include additional data whe= n >> =A0 the outcome is successful.* >> =A0 [...] >> =A0 The outcome message provided by the server can provide a way for the >> =A0 client to distinguish between errors [...] >> =BB >> >> What I understand here is that the error should not be dealt on SASL >> level but on the higher level protocol. For instance in XMPP, we >> indeed give error on XMPP level only. >> So I think the whole error list in SCRAM as additional data to be sent >> on failed outcome is violating the SASL RFC. > > It's not an RFC violation (particularly due to the wording of 5.2-2b in R= FC > 5802), one merely has to add an additional round-trip to the SASL exchang= e > in order to communicate the error information. If I implement the error > codes (and I might since I'm a big fan of additional diagnostics and the > application protocols that use SASL don't always have enough standardized > authentication diagnostics) then there will be an option to turn the extr= a > round trip off. As for my own, the more I read the SASL RFC, the more I become sure this is a violation to RFC4422. What I understand from the SASL RFC is that there is NO error code at the SASL level, but it says that there can be at the higher protocol level. That's indeed what we do in XMPP for instance: The error is an XML tag because it is at XMPP level (oppositely to a SASL success's additional data which would be an a base64-encoded data inside the tags, and when decoded, it will be whatever syntax the SASL mechanism requires). I think that's also why at least already 3 implementations (Alexey Melnikov, Simon Josefsson and mine) don't implement them. Obviously we first implemented SASL as a generic library and over this, we implemented SCRAM. Then it is how I understood that there is simply "no place" for errors in a SASL implementation written following the RFC! As I said, we can keep the error list, but I think it must be a list of error that we propose for the protocol above to eventually send it in its own syntax (with appropriate security warning about information disclosure as we discussed first), but it cannot be part of the SASL syntax. That's how I read this all at least. Jehan > I'm not opposed to removing the SCRAM-layer errors in a revision, > particularly if they fail the multiple interoperable implementation test > (and there's a good chance they will since SCRAM clients may not handle t= he > extra round-trip correctly if they've never been tested against a server = to > does it). > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Chris > > From chris.newman@oracle.com Tue Mar 15 16:14:34 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937683A6F09 for ; Tue, 15 Mar 2011 16:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.35 X-Spam-Level: X-Spam-Status: No, score=-104.35 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tV4RG5b651D for ; Tue, 15 Mar 2011 16:14:33 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 83D873A6ED4 for ; Tue, 15 Mar 2011 16:14:33 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p2FNFvOa020316 for ; Tue, 15 Mar 2011 23:15:57 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.4) with ESMTP id p2FNFrHE029241 for ; Tue, 15 Mar 2011 16:15:56 -0700 (PDT) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=utf-8; format=flowed Received: from [10.159.58.85] (dhcp-rmdc-twvpn-2-vpnpool-10-159-52-59.vpn.oracle.com [10.159.52.59]) by gotmail.sfbay.sun.com (Oracle Communications Messaging Exchange Server 7u5-2.03 64bit (built Feb 6 2011)) with ESMTPA id <0LI400F3GGMD7J00@gotmail.sfbay.sun.com> for kitten@ietf.org; Tue, 15 Mar 2011 16:15:53 -0700 (PDT) Date: Tue, 15 Mar 2011 16:15:48 -0700 From: Chris Newman To: =?UTF-8?Q?Jehan_Pag=C3=A8s?= Message-id: In-reply-to: References: <4CF91652.2080104@googlemail.com> <25128_1291395225_oB3Griia031936_AANLkTi=NnaG=a-CaiNKFVSsx=8tzKd_Q87wnAJ3CbuXY@mail.gmail.com> <5A6498C4F1AEDE3EC2DDB578@minbar.fac.cs.cmu.edu> <0083F29703B421CF922D1CA7@96B2F16665FF96BAE59E9B90> X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-transfer-encoding: quoted-printable Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] RFC5802: question about unknown-user error X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 23:14:34 -0000 --On March 16, 2011 3:33:40 +0900 Jehan Pag=C3=A8s = =20 wrote: > As for my own, the more I read the SASL RFC, the more I become sure > this is a violation to RFC4422. Violation is far too strong a word. RFC 4422 reports primary errors in the=20 application protocol and not in the security mechanisms. This is obvious=20 from the design of the early SASL profiles and mechanisms. But there's=20 nothing in the specification forbidding additional diagnostics at the=20 mechanism layer and it would be a mistake for SASL to add such a=20 restriction as it would reduce the flexibility and adaptability of SASL. Application protocols have limited diagnostics and it's certainly more=20 difficult to add a new helpful diagnostic to every application with a SASL=20 profile than it is to include additional diagnostics in a new SASL=20 mechanism. > I think that's also why at least already 3 implementations (Alexey > Melnikov, Simon Josefsson and mine) don't implement them. Obviously we > first implemented SASL as a generic library and over this, we > implemented SCRAM. Then it is how I understood that there is simply > "no place" for errors in a SASL implementation written following the > RFC! A SASL mechanism is encapsulated as a bag of bits with arbitrary round=20 trips in an application profile. A mechanism can put anything it wants in=20 that bag of bits unless it's explicitly forbidden with a MUST NOT in RFC=20 4422. > As I said, we can keep the error list, but I think it must be a list > of error that we propose for the protocol above to eventually send it > in its own syntax (with appropriate security warning about information > disclosure as we discussed first), but it cannot be part of the SASL > syntax. Having a "best practice" document of authentication errors that most=20 application protocols should implement is something I'd find useful. I find = the piecemeal approach to improving application error codes (RFC 5530, RFC=20 3206, RFC 3463) rather unsatisfactory. It would also be a cleaner design if = all application protocols had the 20 or so most useful authentication=20 diagnostics. But they don't and I don't see volunteers to write specs to=20 update all of them. So having a way to provide ancillary diagnostics in a=20 mechanism for those profiles with too few authentication diagnostics seems=20 pragmatic to me. I'm not sure any of the diagnostics in SCRAM are compelling so if they get=20 removed as part of interop testing for advancement to draft status, I don't = care (the simplicity improvement is roughly equivalent to the diagnostic=20 benefit in my opinion). But I would strongly oppose altering SASL to forbid = mechanism-layer diagnostics. - Chris From sova+ietf@cesnet.cz Sun Mar 20 08:46:01 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1B13A692C for ; Sun, 20 Mar 2011 08:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAClFRG1Y5Bx for ; Sun, 20 Mar 2011 08:46:01 -0700 (PDT) Received: from katz.cesnet.cz (katz.cesnet.cz [195.113.134.170]) by core3.amsl.com (Postfix) with ESMTP id A4DD73A6903 for ; Sun, 20 Mar 2011 08:46:00 -0700 (PDT) Received: from [192.168.111.102] (unknown [122.146.41.220]) by katz.cesnet.cz (Postfix) with ESMTP id F034C4FDA7; Sun, 20 Mar 2011 16:47:29 +0100 (CET) Message-ID: <4D862187.3020108@cesnet.cz> Date: Sun, 20 Mar 2011 16:47:19 +0100 From: Milan Sova User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: multipart/mixed; boundary="------------030306070306070802020609" Subject: [kitten] [Fwd: New Version Notification for draft-sova-sasl-exturi-00] X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 15:46:02 -0000 This is a multi-part message in MIME format. --------------030306070306070802020609 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi. I have uploaded an initial sketch of yet another SASL mechanism re-using external AA infrastructures. Do you think we might discuss it in Prague? Regards -- Milan Sova sova+ietf@cesnet.cz --------------030306070306070802020609 Content-Type: message/rfc822; name="New Version Notification for draft-sova-sasl-exturi-00.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-sova-sasl-exturi-00.eml" Return-Path: X-Original-To: sova+ietf@katz.cesnet.cz Delivered-To: sova+ietf@katz.cesnet.cz Received: from mail.cesnet.cz (mail.cesnet.cz [195.113.144.234]) by katz.cesnet.cz (Postfix) with ESMTP id 477704FDA7 for ; Mon, 7 Mar 2011 16:46:22 +0100 (CET) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mail.cesnet.cz (Postfix) with ESMTP id 96F06188740 for ; Mon, 7 Mar 2011 16:46:22 +0100 (CET) Received: by core3.amsl.com (Postfix, from userid 30) id 776B028C0ED; Mon, 7 Mar 2011 07:45:07 -0800 (PST) From: IETF I-D Submission Tool To: sova+ietf@cesnet.cz Cc: sova+ietf@cesnet.cz Subject: New Version Notification for draft-sova-sasl-exturi-00 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110307154507.776B028C0ED@core3.amsl.com> Date: Mon, 7 Mar 2011 07:45:07 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on katz X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.7 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 A new version of I-D, draft-sova-sasl-exturi-00.txt has been successfully submitted by Milan Sova and posted to the IETF repository. Filename: draft-sova-sasl-exturi Revision: 00 Title: SASL External URI Mechanism Creation_date: 2011-03-07 WG ID: Independent Submission Number_of_pages: 12 Abstract: Simple Authentication and Security Layer (SASL) is a framework for providing authentication to connection-oriented protocols. This memo specifies a SASL mechanism leveraging an existing external authentication infrastructure built for access control for URL- identified resources. The IETF Secretariat. --------------030306070306070802020609-- From alexey.melnikov@isode.com Sun Mar 20 08:47:52 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D140A3A692C for ; Sun, 20 Mar 2011 08:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFzLXyxNQcCL for ; Sun, 20 Mar 2011 08:47:52 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0F8923A6903 for ; Sun, 20 Mar 2011 08:47:52 -0700 (PDT) Received: from [192.168.20.2] ((unknown) [212.183.140.35]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 20 Mar 2011 15:49:22 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D8621CB.4000703@isode.com> Date: Sun, 20 Mar 2011 15:48:27 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Simon Josefsson References: <87d3ltfw4t.fsf@latte.josefsson.org> In-Reply-To: <87d3ltfw4t.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 15:47:52 -0000 Hi Simon, Simon Josefsson wrote: >I know this document has expired, but I don't recall if there were any >discussion or conclusion on it. The APIs are implemented and deployed >in Heimdal and Shishi for some time now (years), and the calls are >useful for GS2 implementers. Is there interest in moving this forward >in this WG? I believe it makes sense to at least publish it as >informational because it is widely deployed. > >http://tools.ietf.org/html/draft-josefsson-gss-capsulate-01 > This is a fine document and I am happy to serve as the document shepherd for it. From ghudson@mit.edu Mon Mar 21 08:34:52 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C97C3A687E for ; Mon, 21 Mar 2011 08:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAyFRXK2UjU6 for ; Mon, 21 Mar 2011 08:34:51 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id 712BE3A687D for ; Mon, 21 Mar 2011 08:34:51 -0700 (PDT) X-AuditID: 12074423-b7c3fae000000a15-15-4d87707a486e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 2A.4F.02581.A70778D4; Mon, 21 Mar 2011 11:36:26 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p2LFaNSW030611 for ; Mon, 21 Mar 2011 11:36:23 -0400 Received: from localhost (EQUAL-RITES.MIT.EDU [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p2LFaMoV014307 for ; Mon, 21 Mar 2011 11:36:22 -0400 (EDT) Date: Mon, 21 Mar 2011 11:36:22 -0400 (EDT) From: ghudson@MIT.EDU Message-Id: <201103211536.p2LFaMoV014307@outgoing.mit.edu> To: kitten@ietf.org X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUixG6noltV0O5rsHaitsXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsenaEdaCNXwVl799Y29gvMrdxcjJISFgInF89hJGCFtM4sK9 9WxdjFwcQgL7GCXmrp8A5RxjlFj3YQ0ThNPHJDFn7w4WkBYWAW2Jrr4eZhCbTUBU4sOHC6xd jBwcvAJWEufmyIOERQSEJXZvfQdWIixgIDH7yFe2CYxcCxgZVjHKpuRW6eYmZuYUpybrFicn 5uWlFuma6eVmluilppRuYgR7z0V5B+Ofg0qHGAU4GJV4eA8ItvkKsSaWFVfmHmKU5GBSEuX9 n9/uK8SXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEtzEAKMebklhZlVqUD5OS5mBREuedK6nuKySQ nliSmp2aWpBaBJOV4eBQkuA9DjJUsCg1PbUiLTOnBCHNxMEJMpwHaDg/SA1vcUFibnFmOkT+ FKOilDjvJZCEAEgiozQPrhcWXa8YxYFeEeY9ClLFA4xMuO5XQIOZgAbv3dICMrgkESEl1cDI zdHf1ivIZTnxfIsk4/cpRwzjK9KvnHN8pG5efaxeoPn9zJiYu2kJN35Zzd0b/blc6I5y1hHx FLvrttNv3OwNEPJ5JtwU8+rjkd+Wr+XM/ov+fibmtrBJ4v7M7ImMJlw/N5n9diyKKIn7pqp6 UCCjRWmrZ0mK1IN8bwcT4e3PIx7XCBrerFdiKc5INNRiLipOBADJ/d9qiQIAAA== Subject: [kitten] Delayed credential resolution in GSSAPI X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 15:34:53 -0000 GSSAPI has the concept of a default credential. You can use it by passing GSS_C_NO_CREDENTIAL to init/accept_sec_context, and you can acquire a handle to one by passing GSS_C_NO_NAME to acquire_cred. It is sometimes advantageous not to decide right away on an identity for the default credential (or even for non-default credentials, but I won't cover that case here). When accepting, you might want to determine the server identity based on the initiator tokens; this behavior is sanctioned in RFC 2743 section 1.1.1.3. When initiating, you might have multiple identities available and might want to choose one based on the target name or other information. The GSSAPI allows callers to query the name of a credential. For an initiator cred, RFC 2744 section 5.5 mandates that the returned name (if canonicalized to an MN) match the src_name seen by any acceptor. For an acceptor cred, I'm not sure if RFC 2743 or 2744 lay down any specific rules beyond that some name be returned. My questions for the working group are these: 1. Suppose I implement delayed resolution for the default initiator credential. If the app inquires the name of the cred, my understanding is that I should pick a default identity and constrain the cred to only act as that identity. (So, by asking the question in advance of calling gss_init_sec_context, you may change the answer.) Does that seem correct? 2. We already implement delayed resolution for the default acceptor cred. If the app inquires the name of the cred, we should determine a name (currently we return GSS_C_NO_NAME, which is probably wrong). Is it enough that this name by *a* name which an initiator could use to authenticate to the service, or should the credential also be constrained to *only* accept tokens authenticating to that name? From hartmans@mit.edu Mon Mar 21 10:01:45 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802DF28C0F2 for ; Mon, 21 Mar 2011 10:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8AKTEMFPZQh for ; Mon, 21 Mar 2011 10:01:45 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id E16CF28C0EC for ; Mon, 21 Mar 2011 10:01:44 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4C874207D6; Mon, 21 Mar 2011 13:00:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 032A04547; Mon, 21 Mar 2011 13:03:13 -0400 (EDT) From: Sam Hartman To: Milan Sova References: <4D862187.3020108@cesnet.cz> Date: Mon, 21 Mar 2011 13:03:12 -0400 In-Reply-To: <4D862187.3020108@cesnet.cz> (Milan Sova's message of "Sun, 20 Mar 2011 16:47:19 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" Subject: Re: [kitten] [Fwd: New Version Notification for draft-sova-sasl-exturi-00] X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:01:45 -0000 I'd prefer that we not spend more time on SASL mechanisms that offer neither security layers nor channel binding. This particular approach does not seem promising for adding either. So my preference is that if you want to go forward with this you do so outside the IETF process. From shawn.emery@oracle.com Mon Mar 21 11:01:56 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192B528C19F for ; Mon, 21 Mar 2011 11:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znIRLYuxOEV1 for ; Mon, 21 Mar 2011 11:01:55 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 35E2228C19D for ; Mon, 21 Mar 2011 11:01:55 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2LI3P6J032612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Mar 2011 18:03:27 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2LI3OAU029799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Mar 2011 18:03:24 GMT Received: from abhmt010.oracle.com (abhmt010.oracle.com [141.146.116.19]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p2LI3OPE030625 for ; Mon, 21 Mar 2011 13:03:24 -0500 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Mar 2011 11:03:23 -0700 Message-ID: <4D8792EA.20501@oracle.com> Date: Mon, 21 Mar 2011 12:03:22 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.13) Gecko/20110228 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: kitten@ietf.org References: <87d3ltfw4t.fsf@latte.josefsson.org> In-Reply-To: <87d3ltfw4t.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt358.oracle.com [141.146.40.158] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4D8792ED.000A,ss=1,fgs=0 Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 18:01:56 -0000 On 03/14/11 11:29 AM, Simon Josefsson wrote: > I know this document has expired, but I don't recall if there were any > discussion or conclusion on it. The APIs are implemented and deployed > in Heimdal and Shishi for some time now (years), and the calls are > useful for GS2 implementers. Is there interest in moving this forward > in this WG? I believe it makes sense to at least publish it as > informational because it is widely deployed. > > http://tools.ietf.org/html/draft-josefsson-gss-capsulate-01 The draft looks straight forward. I've added this to the agenda: http://www.ietf.org/proceedings/80/agenda/kitten.txt (to make a consensus call on whether we should adopt). Shawn. -- From prvs=106173b250=jaltman@secure-endpoints.com Mon Mar 21 16:54:48 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D219D28C106 for ; Mon, 21 Mar 2011 16:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBY3j+beJJjQ for ; Mon, 21 Mar 2011 16:54:41 -0700 (PDT) Received: from www.secure-endpoints.com (peju.ad.secure-endpoints.com [208.125.0.227]) by core3.amsl.com (Postfix) with ESMTP id 464B328C102 for ; Mon, 21 Mar 2011 16:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1300751773; x=1301356573; q=dns/txt; h=DomainKey-Signature:Received:Message-ID:Date:From: Organization:User-Agent:MIME-Version:To:Subject:References: In-Reply-To:OpenPGP:Content-Type:Reply-To; bh=R7C9Lut0V4/ooZRWyU ebcWvw6Ia407QWXzMlqPIfMNo=; b=lS7HG4yip7/OtE/wfIJmhCKUpahdDUIR/B MURiVR8IIHYCbIHBRqpRp2VfEbUSmA6JYBIKQ2AMKvQwS1AbRdNjXX9Ppx9spu1G k79W//ijU/8IWZ5Yworae7MTcicuiJQei+VWkG2ZWkxIrn3XeqcYo3NlgF3SI6xR 7U8rv2avY= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=secure-endpoints.com; c=simple; q=dns; h=message-id:from; b=RL4dot/IjOXty175X6ND6ENbnhIaYm1NjP8uDlVoIIMZz9f4FJ+w7jQAp0Mp dO8gE6z6Es/YF/vViLSYrjL5ju6sd+BTy3uh4t7cV9MEKxE5HGsc8MMyR 5q3A1s8K41vVlIHNH6NCmXvpShh8Hnke0EinADiLKnXjFPZlfQ1hFc=; X-MDAV-Processed: www.secure-endpoints.com, Mon, 21 Mar 2011 19:56:13 -0400 Received: from [172.17.16.77] by secure-endpoints.com (Cipher TLSv1:-SHA:128) (MDaemon PRO v12.0.0) with ESMTP id md50000092426.msg for ; Mon, 21 Mar 2011 19:56:13 -0400 X-Spam-Processed: www.secure-endpoints.com, Mon, 21 Mar 2011 19:56:13 -0400 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: jaltman@secure-endpoints.com X-MDRemoteIP: 75.99.247.221 X-Return-Path: prvs=106173b250=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <4D87E595.2060902@secure-endpoints.com> Date: Mon, 21 Mar 2011 19:56:05 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: kitten@ietf.org References: <87d3ltfw4t.fsf@latte.josefsson.org> <4D8792EA.20501@oracle.com> In-Reply-To: <4D8792EA.20501@oracle.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://pgp.mit.edu Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEEE9C4BF5B4CDA0241CFF30E" Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 23:54:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEEE9C4BF5B4CDA0241CFF30E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/21/2011 2:03 PM, Shawn Emery wrote: > On 03/14/11 11:29 AM, Simon Josefsson wrote: >> I know this document has expired, but I don't recall if there were any= >> discussion or conclusion on it. The APIs are implemented and deployed= >> in Heimdal and Shishi for some time now (years), and the calls are >> useful for GS2 implementers. Is there interest in moving this forward= >> in this WG? I believe it makes sense to at least publish it as >> informational because it is widely deployed. >> >> http://tools.ietf.org/html/draft-josefsson-gss-capsulate-01 >=20 > The draft looks straight forward. I've added this to the agenda: >=20 > http://www.ietf.org/proceedings/80/agenda/kitten.txt >=20 > (to make a consensus call on whether we should adopt). >=20 > Shawn. As Simon indicates, the APIs are implemented and deployed. The draft should be republished and submitted for last call as an independent submission. I don't think it needs to be added to the agenda. Just my two cents ... Jeffrey Altman --------------enigEEE9C4BF5B4CDA0241CFF30E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJNh+WXAAoJENxm1CNJffh4jNYH/R+7qiv0iCpLxmOKoXMcpkS8 9CfXyyRWzPfKA8ieVzYqqKzexW4caOga4kMRzzsX0rNK71Bekda8cN4bnlr72Ha/ vt+v36rUQc88JI3MOAi7L1PUV6i5ToZZs0p1e12XZ77WyEvqZ2RdO7tf1vkpGpYt WiChqeQ9ywfb85+8+oE5BNuanMjNfEPGOhLzvYvrJvAiPextLwOiMHhU387sL0EU wmC0NaVZg3CLcmvXjgIPx80nXfncvTgaL+MDlpUSpD+NZlMAGBgunZA7PVI+URDr yrBrmzXC1YsNP3qIg3gKCbYyXK4P0rhJv5QrRzmosiNenK/JZpN1ik85ZsLTmoY= =5DwX -----END PGP SIGNATURE----- --------------enigEEE9C4BF5B4CDA0241CFF30E-- From lukeh@padl.com Mon Mar 21 17:39:19 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5DE528C1C2 for ; Mon, 21 Mar 2011 17:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDcG+GsTZNBu for ; Mon, 21 Mar 2011 17:39:19 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 1655828C1C1 for ; Mon, 21 Mar 2011 17:39:19 -0700 (PDT) Received: by us.padl.com with ESMTP id p2M0eeLF030426; Mon, 21 Mar 2011 20:40:43 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Luke Howard In-Reply-To: <4D87E595.2060902@secure-endpoints.com> Date: Tue, 22 Mar 2011 11:40:46 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <8D59CC0D-14AA-4E2B-8A0D-A2751CFCA313@padl.com> References: <87d3ltfw4t.fsf@latte.josefsson.org> <4D8792EA.20501@oracle.com> <4D87E595.2060902@secure-endpoints.com> To: kitten@ietf.org X-Mailer: Apple Mail (2.1082) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 00:39:19 -0000 > As Simon indicates, the APIs are implemented and deployed. The draft > should be republished and submitted for last call as an independent > submission. I don't think it needs to be added to the agenda. I've added an implementation of this to MIT Kerberos in the = users/lhoward/moonshot-mechglue-fixes branch. -- Luke= From lukeh@padl.com Mon Mar 21 18:44:34 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2C13A6914 for ; Mon, 21 Mar 2011 18:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NtzrM9yC2lx for ; Mon, 21 Mar 2011 18:44:33 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 411653A6912 for ; Mon, 21 Mar 2011 18:44:33 -0700 (PDT) Received: by us.padl.com with ESMTP id p2M1js4Z003716; Mon, 21 Mar 2011 21:45:57 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Luke Howard In-Reply-To: <8D59CC0D-14AA-4E2B-8A0D-A2751CFCA313@padl.com> Date: Tue, 22 Mar 2011 12:46:00 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87d3ltfw4t.fsf@latte.josefsson.org> <4D8792EA.20501@oracle.com> <4D87E595.2060902@secure-endpoints.com> <8D59CC0D-14AA-4E2B-8A0D-A2751CFCA313@padl.com> To: kitten@ietf.org X-Mailer: Apple Mail (2.1082) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 01:44:34 -0000 On 22/03/2011, at 11:40 AM, Luke Howard wrote: >> As Simon indicates, the APIs are implemented and deployed. The draft >> should be republished and submitted for last call as an independent >> submission. I don't think it needs to be added to the agenda. >=20 > I've added an implementation of this to MIT Kerberos in the = users/lhoward/moonshot-mechglue-fixes branch. ... and the Cyrus SASL GS2 implementation in the Moonshot GIT repository = now uses draft-josefsson-gss-capsulate-01 APIs if present. -- Luke= From shawn.emery@oracle.com Tue Mar 22 00:08:02 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121203A68EC for ; Tue, 22 Mar 2011 00:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce8q-KoTLIjH for ; Tue, 22 Mar 2011 00:08:01 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 528223A67CF for ; Tue, 22 Mar 2011 00:08:01 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2M79WN6010663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Mar 2011 07:09:33 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2M79VYI031059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Mar 2011 07:09:32 GMT Received: from abhmt015.oracle.com (abhmt015.oracle.com [141.146.116.24]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p2M79V80027434 for ; Tue, 22 Mar 2011 02:09:31 -0500 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Mar 2011 00:09:31 -0700 Message-ID: <4D884B29.4010605@oracle.com> Date: Tue, 22 Mar 2011 01:09:29 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.13) Gecko/20110228 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: kitten@ietf.org References: <87d3ltfw4t.fsf@latte.josefsson.org> <4D8792EA.20501@oracle.com> <4D87E595.2060902@secure-endpoints.com> <8D59CC0D-14AA-4E2B-8A0D-A2751CFCA313@padl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4D884B2C.004C,ss=1,fgs=0 Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 07:08:02 -0000 On 03/21/11 07:46 PM, Luke Howard wrote: > On 22/03/2011, at 11:40 AM, Luke Howard wrote: >>> As Simon indicates, the APIs are implemented and deployed. The draft >>> should be republished and submitted for last call as an independent >>> submission. I don't think it needs to be added to the agenda. >> I've added an implementation of this to MIT Kerberos in the users/lhoward/moonshot-mechglue-fixes branch. > ... and the Cyrus SASL GS2 implementation in the Moonshot GIT repository now uses draft-josefsson-gss-capsulate-01 APIs if present. All good points for leaving as an individual submission. Removing from the agenda. Shawn. -- From nico@cryptonector.com Tue Mar 22 14:32:39 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86E728C166 for ; Tue, 22 Mar 2011 14:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBNtvBilcOZ7 for ; Tue, 22 Mar 2011 14:32:38 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 8A8FF28C0D9 for ; Tue, 22 Mar 2011 14:32:38 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id E9F9F21DE6F for ; Tue, 22 Mar 2011 14:34:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=ZRUOqbfo93ImtCGlNU3oNKT1NmjeGOsVGioEbanvN2X2 5nuIkHZ65M1ml90TIAj2d2bmft0IVx7++xDYl1IsEYjRZVI34IJBtsu/hWxn1siA wXRWt1DFi73GtkQ1zAbBXZ7W0wcEeew5+xGZv9Uwyxmuo/NENJpES8L+Y7fF/3I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=VeGHN88IDeN1oP1uMgEgo8vYZHg=; b=IEV9KDAu5kj 6whwIjxufFVmy00Nqb8sbITXvudIDYuv2y64VLIRt9E3gK5onsxFnp/7KpEoTF/B 3VvX7LMwTYUjDyhyTEOZa5TmZgYgQzhyPq7eUDHsQm7EXpiiE5osDziGJ+2TDphi YxiEDMcXBROaVudUow7K0HGrpkPneNFE= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id B129B21DE58 for ; Tue, 22 Mar 2011 14:34:11 -0700 (PDT) Received: by vxg33 with SMTP id 33so6912537vxg.31 for ; Tue, 22 Mar 2011 14:34:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.18.6 with SMTP id s6mr4751387vdd.144.1300829650843; Tue, 22 Mar 2011 14:34:10 -0700 (PDT) Received: by 10.52.159.4 with HTTP; Tue, 22 Mar 2011 14:34:10 -0700 (PDT) In-Reply-To: <4D7CEF5B.9020202@isode.com> References: <4CF91652.2080104@googlemail.com> <25128_1291395225_oB3Griia031936_AANLkTi=NnaG=a-CaiNKFVSsx=8tzKd_Q87wnAJ3CbuXY@mail.gmail.com> <5A6498C4F1AEDE3EC2DDB578@minbar.fac.cs.cmu.edu> <874o775isa.fsf@latte.josefsson.org> <4D7CEF5B.9020202@isode.com> Date: Tue, 22 Mar 2011 16:34:10 -0500 Message-ID: From: Nico Williams To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Simon Josefsson Subject: Re: [kitten] RFC5802: question about unknown-user error X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 21:32:39 -0000 On Sun, Mar 13, 2011 at 11:22 AM, Alexey Melnikov wrote: > Simon Josefsson wrote: >> Jehan Pag=C3=A8s writes: >> >>> >>> =C2=A0The protocol may include an optional additional data field in thi= s >>> =C2=A0outcome message. =C2=A0*This field can only include additional da= ta when >>> =C2=A0the outcome is successful.* >>> >> >> I believe you are right and that additional error codes aren't >> permitted. >> >>> >>> Hence I wonder if this list should not be removed from the Formal >>> Syntax (section 7) because it does not belong to the SASL exchange >>> itself (as forbidden by RFC4422) and moved to another section as error >>> information from an authentication module to a server. >>> >> >> My implementation (GNU SASL) never generates (or parse) error codes. >> How do other SCRAM implementations behave? >> > > My implementation doesn't do that either. > I think Nico wanted to have them for GSS-API implementations. Highly informative errors are a security problem. They are also a debug to= ol. I would prefer that by default implementations use only the most generic error codes that convey the minimum absolutely necessary information. But they could/should be configurable to return more informative error codes. I would also prefer that implementations of _applications_ send error messages instead of, say, simply closing a connection (because in some protocols one may want to retry), but I'd be fine with application implementations that just close the connection. That's a large range of permitted behavior. I'm not at all opposed to it, and, indeed, would be happy to see that explicitly allowed in the erratum. >> I always thought of the error codes as an unnecessary complication of >> the protocol, but since they are optional I have mentally just ignored >> that part of the specification. =C2=A0I wouldn't oppose removing them fr= om >> RFC 5802bis. >> > I wouldn't be opposed to that either but I want to hear what Nico has to = say > first. For me they are entirely optional. I would rather they stay. Indeed, we can't really remove them in an erratum -- we can only really add guidance -- and I'm not willing to do the work of re-publishing this RFC nor any update, not for this sort of issue. Others might well be willing to do that work though. Nico -- From nico@cryptonector.com Tue Mar 22 14:42:44 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEDEA3A6403 for ; Tue, 22 Mar 2011 14:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.608 X-Spam-Level: X-Spam-Status: No, score=-1.608 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsMCe+hC0dPD for ; Tue, 22 Mar 2011 14:42:43 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id B840D3A63C9 for ; Tue, 22 Mar 2011 14:42:43 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 5F8EE2C806E for ; Tue, 22 Mar 2011 14:44:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=fLLUec/bQVicMpg//W9MhHyQzn+8yHi0IemIO4oxg7HB tuEQHe5XXxnVfnunfKVzPyvf1kN8V2Gjc8tLrVZ4DhoLWmBwkfzFzQ7/EI6JhZSy KSHeLRcRXx6+50hhNM30IJQ25Gi47jNWMOr5CkV0/uBCY7K3EvmRfHVzelbHfYg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=z/eNN6X1Mt+c8u53xXZDHEk8KEI=; b=KAj1UDuPg1E +jqIHES34UTtwRjwK48m2WE2F5ORFwjzDGZjY4b7W64jOVHidFgtlgjpDru9Lv/G n148APdGa+AIjPkoa4qIvbWkCPiSC6I8eOMEurTj0E4hbyEB8P4b95ktUAFEI0hM cL9xRqRVyt0Prr60y1HJLUyVzUluw+wk= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 2C1AD2C806C for ; Tue, 22 Mar 2011 14:44:17 -0700 (PDT) Received: by vxg33 with SMTP id 33so6920557vxg.31 for ; Tue, 22 Mar 2011 14:44:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.74.226 with SMTP id x2mr5958840vdv.264.1300830256605; Tue, 22 Mar 2011 14:44:16 -0700 (PDT) Received: by 10.52.159.4 with HTTP; Tue, 22 Mar 2011 14:44:16 -0700 (PDT) In-Reply-To: References: <4CF91652.2080104@googlemail.com> <25128_1291395225_oB3Griia031936_AANLkTi=NnaG=a-CaiNKFVSsx=8tzKd_Q87wnAJ3CbuXY@mail.gmail.com> <5A6498C4F1AEDE3EC2DDB578@minbar.fac.cs.cmu.edu> <0083F29703B421CF922D1CA7@96B2F16665FF96BAE59E9B90> Date: Tue, 22 Mar 2011 16:44:16 -0500 Message-ID: From: Nico Williams To: Chris Newman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] RFC5802: question about unknown-user error X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 21:42:44 -0000 2011/3/15 Chris Newman : > --On March 16, 2011 3:33:40 +0900 Jehan Pag=C3=A8s > wrote: >> >> As for my own, the more I read the SASL RFC, the more I become sure >> this is a violation to RFC4422. > > Violation is far too strong a word. RFC 4422 reports primary errors in th= e > application protocol and not in the security mechanisms. This is obvious > from the design of the early SASL profiles and mechanisms. But there's > nothing in the specification forbidding additional diagnostics at the > mechanism layer and it would be a mistake for SASL to add such a restrict= ion > as it would reduce the flexibility and adaptability of SASL. +1. It is quite a stretch to say that SCRAM is in violation of SASL here. It is NOT a stretch to say that more guidance on when to use which error code (only one code is mentioned in the text) should have been provided, so let's do that. > Application protocols have limited diagnostics and it's certainly more > difficult to add a new helpful diagnostic to every application with a SAS= L > profile than it is to include additional diagnostics in a new SASL > mechanism. +1. And, as Alexey pointed out, there's the GSS-API side of SCRAM. Unlike SASL, GSS-API applications don't usually have any sort of free-form application protocol field via which to transmit any kind of detailed error information. (Also, SASL apps that do have such a thing usually can't localize it, which is another reason for wanting to have detailed error codes.) For this reason I'd oppose removal of these error codes. >> I think that's also why at least already 3 implementations (Alexey >> Melnikov, Simon Josefsson and mine) don't implement them. Obviously we >> first implemented SASL as a generic library and over this, we >> implemented SCRAM. Then it is how I understood that there is simply >> "no place" for errors in a SASL implementation written following the >> RFC! > > A SASL mechanism is encapsulated as a bag of bits with arbitrary round tr= ips > in an application profile. A mechanism can put anything it wants in that = bag > of bits unless it's explicitly forbidden with a MUST NOT in RFC 4422. And via GS2, we also get any bits that any GSS-API mechanism might want to put in there as well. That's another side of the coin mentioned by Alexey. I am opposed to any language in SASL/GS2 that says that GSS-API mechanisms (which SCRAM is) MUST NOT send detailed error information -- that would be a layering violation. Note that the same rationale that leads one to want SASL mechanisms to by default provide minimal error information also leads to the same conclusion in the GSS-API. But this is not a get-out-of-jail-free card for the layering violation that would occur if we insisted on prohibiting detailed error information in SASL itself. >> As I said, we can keep the error list, but I think it must be a list >> of error that we propose for the protocol above to eventually send it >> in its own syntax (with appropriate security warning about information >> disclosure as we discussed first), but it cannot be part of the SASL >> syntax. Absolutely not. See above. I am opposed to any requirements that entail changes to application protocols in the cases of applications where detailed error codes are ever desirable. > Having a "best practice" document of authentication errors that most > application protocols should implement is something I'd find useful. I fi= nd > the piecemeal approach to improving application error codes (RFC 5530, RF= C > 3206, RFC 3463) rather unsatisfactory. It would also be a cleaner design = if > all application protocols had the 20 or so most useful authentication > diagnostics. But they don't and I don't see volunteers to write specs to > update all of them. So having a way to provide ancillary diagnostics in a > mechanism for those profiles with too few authentication diagnostics seem= s > pragmatic to me. > > I'm not sure any of the diagnostics in SCRAM are compelling so if they ge= t > removed as part of interop testing for advancement to draft status, I don= 't > care (the simplicity improvement is roughly equivalent to the diagnostic > benefit in my opinion). But I would strongly oppose altering SASL to forb= id > mechanism-layer diagnostics. +1. Nico -- From nico@cryptonector.com Tue Mar 22 14:46:43 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1B33A67AA for ; Tue, 22 Mar 2011 14:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlxi+LwuuliT for ; Tue, 22 Mar 2011 14:46:42 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 35F253A67A2 for ; Tue, 22 Mar 2011 14:46:41 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 7D899778061 for ; Tue, 22 Mar 2011 14:48:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=elYPyuCa2pfnl6oS/iQZX 94jzpBTmMwsS11SyQr+jizpQcCpUauoKeRnSby3lH9+grKiR3KV2+HcayzplZM9b Qxd1WpjmjItEuGgBRzVzZP24BrHvLNU8TyG25X9xfXV+InUwOEfeXo9LQh26iGSi GFj43PUqp3VpraFqrKM3Es= 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=sSAmcPRvEYBzk8i4fnpP zUv+WqM=; b=BGS4vAqtCXEfjWeuVM260X6XJfdheiY8H/0ZxHc6k005FaOBRB50 EaO00G5cvu7lZIGYn7EFyXFugiz6A0rz63EQaHwpNLrcsQeoVe/JHyWcqsEsTQRd TLKApHZZL9cN3Q/qe/kpPQheKkstllK/d8Y1as6XZD7VP60htoE3yEQ= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (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 512D477805B for ; Tue, 22 Mar 2011 14:48:15 -0700 (PDT) Received: by vxg33 with SMTP id 33so6923959vxg.31 for ; Tue, 22 Mar 2011 14:48:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.168.8 with SMTP id zs8mr5956571vdb.184.1300830494729; Tue, 22 Mar 2011 14:48:14 -0700 (PDT) Received: by 10.52.159.4 with HTTP; Tue, 22 Mar 2011 14:48:14 -0700 (PDT) In-Reply-To: References: <4CF91652.2080104@googlemail.com> <25128_1291395225_oB3Griia031936_AANLkTi=NnaG=a-CaiNKFVSsx=8tzKd_Q87wnAJ3CbuXY@mail.gmail.com> <5A6498C4F1AEDE3EC2DDB578@minbar.fac.cs.cmu.edu> <0083F29703B421CF922D1CA7@96B2F16665FF96BAE59E9B90> Date: Tue, 22 Mar 2011 16:48:14 -0500 Message-ID: From: Nico Williams To: Chris Newman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] RFC5802: question about unknown-user error X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 21:46:43 -0000 This thread has gone on long enough. IMO we do not have consensus on prohibiting the use of or removing the detailed error codes. IMO we do have consensus on adding guidance indicating that by default implementations should send the most general / least informative error codes (the one exception, I think would be for the extensions-not-supported case). My position, after an already lengthy thread, is not likely to change materially, so either I end up on the rough side of consensus or we all settle for adding guidance. If need be let's have a consensus call and see what happens. Nico -- From dave@cridland.net Tue Mar 22 15:10:23 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B839B3A67D9 for ; Tue, 22 Mar 2011 15:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al24+c8KIsm4 for ; Tue, 22 Mar 2011 15:10:22 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 442893A67D7 for ; Tue, 22 Mar 2011 15:10:22 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id B86991168087; Tue, 22 Mar 2011 22:11:52 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MewWMBhyK8No; Tue, 22 Mar 2011 22:11:49 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 83E8F1168067; Tue, 22 Mar 2011 22:11:49 +0000 (GMT) References: <4CF91652.2080104@googlemail.com> =?US-ASCII?Q?<25128_12913?= =?US-ASCII?Q?5225_oB3Griia031936_AANLkTi=3DNnaG=3Da-CaiNKFVSsx?= =?US-ASCII?Q?8tzKd_Q87wnAJ3CbuXY@mail.gmail.com>?= <5A6498C4F1AEDE3EC2DDB578@minbar.fac.cs.cmu.edu> <0083F29703B421CF922D1CA7@96B2F16665FF96BAE59E9B90> =?US-ASCII?Q??= In-Reply-To: MIME-Version: 1.0 Message-Id: <6266.1300831909.510612@puncture> Date: Tue, 22 Mar 2011 22:11:49 +0000 From: Dave Cridland To: Nico Williams , Common Authentication Technologies - Next Generation , Jeffrey Hutzelman , Chris Newman Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [kitten] RFC5802: question about unknown-user error X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 22:10:23 -0000 On Tue Mar 22 21:48:14 2011, Nico Williams wrote: > This thread has gone on long enough. IMO we do not have consensus > on > prohibiting the use of or removing the detailed error codes. IMO we > do have consensus on adding guidance indicating that by default > implementations should send the most general / least informative > error > codes (the one exception, I think would be for the > extensions-not-supported case). > > I'd argue that it's already present, by inheritance from §3.6 of RFC 4422: [...] The outcome message provided by the server can provide a way for the client to distinguish between errors that are best dealt with by re- prompting the user for her credentials, errors that are best dealt with by telling the user to try again later, and errors where the user must contact a system administrator for resolution (see the SYS and AUTH POP Response Codes [RFC3206] specification for an example). This distinction is particularly useful during scheduled server maintenance periods as it reduces support costs. It is also important that the server can be configured such that the outcome Melnikov & Zeilenga Standards Track [Page 11] RFC 4422 SASL June 2006 message will not distinguish between a valid user with invalid credentials and an invalid user. I'd say that was enough, but if a specific reference back to that is wanted, I won't stand against that either. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From nico@cryptonector.com Thu Mar 24 01:06:38 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FE53A682C for ; Thu, 24 Mar 2011 01:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K98Ntb6yqeGN for ; Thu, 24 Mar 2011 01:06:38 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id ED29D3A681F for ; Thu, 24 Mar 2011 01:06:37 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 8AE51674059 for ; Thu, 24 Mar 2011 01:08:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=XDGD+qX4SW07S+annA8DSqVATnYblMMGNDqJpkGB8cUW NJ1rxzzQGQ8ehwyDXMvZkOsh0HBPP9wFzdoA4wGsz8y9nkka6aYR1tVcrWz///PK kSRwiUthtKAofE+3YLx1IoypLEQSHYO/KiDKyA7y0y2/575/OWRF583mzpEITl0= 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=INtUTzA9CzvPXYdCddsd2XuqbUU=; b=MXQ6oU7+SV0 TTJoBck58ucCbx9UpqizfBOeKanycqUR4RSa5pCF+XYiOQkRPk3ACAVJcA8dQOnG 5XqisxrOmWD+wIYdku3oMKyalqn+CxxQHAFcedWeNoTAhgXkoHu98X8T5ffkQg6j X2zY3r+73okITV8nvQJDPTULI/TW580E= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 5EF5A674058 for ; Thu, 24 Mar 2011 01:08:12 -0700 (PDT) Received: by vws12 with SMTP id 12so7365312vws.31 for ; Thu, 24 Mar 2011 01:08:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.4 with SMTP id 4mr1976243vda.104.1300954091651; Thu, 24 Mar 2011 01:08:11 -0700 (PDT) Received: by 10.52.159.4 with HTTP; Thu, 24 Mar 2011 01:08:11 -0700 (PDT) Date: Thu, 24 Mar 2011 03:08:11 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] PGSSAPI, take two X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 08:06:39 -0000 A few years ago there was a proposal for a "PGSSAPI" where GSS functions were augmented with an additional caller context argument. I then proposed overloading the minor_status argument, but no one liked that. Later I proposed a GSS-APIv3, but that won't happen anytime soon. Then Love proposed just adding an additional context argument to a small handful of new functions. I'm starting to think that we need so badly to add such this feature (caller contexts) to the API real soon. Here's an idea: if apps define a C macro called, say, GSS_C_APPLICATION_PROFILE, then GSS_C_NO_NAME and GSS_C_NO_CREDENTIAL could expand into function calls. For convenience we could also add new a version of gss_import_name() that takes a profile name, plus a way to call it to get a gss_name_t that is equivalent to GSS_C_NO_NAME. The rest would follow. I.e., something like this in the GSS C header: #ifdnef GSS_C_APPLICATION_PROFILE #define GSS_C_NO_NAME ((gss_name_t)NULL) #define GSS_C_NO_CREDENTIAL((gss_cred_id_t)NULL) #else #define GSS_C_NO_NAME (__gss_c_no_name(GSS_C_APPLICATION_PROFILE)) #define GSS_C_NO_CREDENTIAL (__gss_c_no_credential(GSS_C_APPLICATION_PROFILE)) #endif then have those __gss_c_no_*() functions use thread-local storage to store thread-local name/cred object handles. Apps would: #define GSS_C_APPLICATION_PROFILE "imap-client" #include No other application changes would be needed, so this would be quite an unintrusive change. For completeness we might want to define a macro to indicate support for this feature. The mechglue SPI would be extended with entry points corresponding to these new functions (__gss_c_no_name() and so on), of course. What the mechglue and mechanisms do with the profile would be up to them. But quite a bit of policy that various folks have been needing to profile could be referred to in this way. If we need something more complex than a profile name, well, we could do something about that too (or we could do that later). Nico -- From jhutz@cmu.edu Thu Mar 24 07:45:52 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7933A68E9 for ; Thu, 24 Mar 2011 07:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2uXfbThpPz5 for ; Thu, 24 Mar 2011 07:45:51 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 575C03A68E8 for ; Thu, 24 Mar 2011 07:45:51 -0700 (PDT) Received: from [128.2.184.182] (JHUTZ-DYN5.PC.CS.CMU.EDU [128.2.184.182]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p2OElNOG008089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Mar 2011 10:47:23 -0400 (EDT) From: Jeffrey Hutzelman To: Nico Williams In-Reply-To: <12791_1300954096_p2O88F3Y020419_AANLkTinTG151J_FPgFv3wy_hzgERNGyLPB+DGptYvXM5@mail.gmail.com> References: <12791_1300954096_p2O88F3Y020419_AANLkTinTG151J_FPgFv3wy_hzgERNGyLPB+DGptYvXM5@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 24 Mar 2011 10:47:29 -0400 Message-ID: <1300978049.3985.79.camel@destiny> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] PGSSAPI, take two X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 14:45:52 -0000 On Thu, 2011-03-24 at 03:08 -0500, Nico Williams wrote: > A few years ago there was a proposal for a "PGSSAPI" where GSS > functions were augmented with an additional caller context argument. > I then proposed overloading the minor_status argument, but no one > liked that. Later I proposed a GSS-APIv3, but that won't happen > anytime soon. Then Love proposed just adding an additional context > argument to a small handful of new functions. > > I'm starting to think that we need so badly to add such this feature > (caller contexts) to the API real soon. What problem are you trying to solve? -- Jeff From mrex@sap.com Thu Mar 24 18:51:32 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615C03A6921 for ; Thu, 24 Mar 2011 18:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.924 X-Spam-Level: X-Spam-Status: No, score=-9.924 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+XHEXcVloVJ for ; Thu, 24 Mar 2011 18:51:31 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id DEBC93A6920 for ; Thu, 24 Mar 2011 18:51:30 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2P1quB5018733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Mar 2011 02:53:01 +0100 (MET) From: Martin Rex Message-Id: <201103250152.p2P1quAR010648@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Fri, 25 Mar 2011 02:52:56 +0100 (MET) In-Reply-To: from "Nico Williams" at Mar 24, 11 03:08:11 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] PGSSAPI, take two X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 25 Mar 2011 01:51:32 -0000 Nico Williams wrote: > > A few years ago there was a proposal for a "PGSSAPI" where GSS > functions were augmented with an additional caller context argument. Admittedly, my memories about this discussion are quite weak. > > I'm starting to think that we need so badly to add such this feature > (caller contexts) to the API real soon. Here's an idea: if apps > define a C macro called, say, GSS_C_APPLICATION_PROFILE, then > GSS_C_NO_NAME and GSS_C_NO_CREDENTIAL could expand into function > calls. For convenience we could also add new a version of > gss_import_name() that takes a profile name, plus a way to call it to > get a gss_name_t that is equivalent to GSS_C_NO_NAME. The rest would > follow. > > I.e., something like this in the GSS C header: > > #ifdnef GSS_C_APPLICATION_PROFILE > #define GSS_C_NO_NAME ((gss_name_t)NULL) > #define GSS_C_NO_CREDENTIAL((gss_cred_id_t)NULL) > #else > #define GSS_C_NO_NAME (__gss_c_no_name(GSS_C_APPLICATION_PROFILE)) > #define GSS_C_NO_CREDENTIAL (__gss_c_no_credential(GSS_C_APPLICATION_PROFILE)) > #endif I completely fail to understand the motivation behind this. Do you have any specific example about the purpose or what exactly you're trying to achieve. The use of these particular constants is limited to very specific purposes, so if you desire is to get an additional context handle, this would leave all other usage scenarios of the gss-api calls out in the cold. To me, this particular example looks quite incompatible to the GSS-API v2 architecture and design. GSS_C_NO_NAME and GSS_C_NO_CREDENTIAL are really only shortcuts to represent the _absence_ of a parameter -- on both, input to a GSS-API call as well as output of a GSS-API call. When used as input, the absence of a credentials parameter is supposed to indicate a request for a "default credential", a concept described here: http://tools.ietf.org/html/rfc2743#page-8 GSS_C_NO_NAME is somewhat different, but related to GSS_C_NO_CREDENTIALS. There is no such thing as a "default name" in GSS-API, but in order to be able to acquire an explicit credentials handle to a credential with "default credential behaviour", gss_acquire_cred() was modified to allow not passing a name on input (dubbed "GSS_C_NO_NAME") to obtain an explicit credentials handle to a credential that exhibits default credential behaviour. GSS_C_NO_NAME is not allowed for other gss-api calls with a gss_name_t input parameter (such as gss_compare_name, gss_canonicalize_name or gss_export_name), because of this. GSS-API functions are allowed to fail, and still return output parameters, so it is really important to be able to recognize whether an output parameter is present (which implies it must be released by the caller later on) or absent. e.g. gss_init_sec_context() and gss_acccept_sec_context() should always return a mech_OID when either of the calls fails and returns a minor_status value, so that gss_display_status() has a clue which mechanism needs to translate the minor_status value into readable text. similarly, message unprotection call gss_unwrap() may fail and still return unprotected data in a buffer. It is at the discretion of the GSS-API mechanism to fail with e.g. (GSS_S_FAILURE|GSS_S_GAP_TOKEN) and no unprotected data buffer or (GSS_S_COMPLETE|GSS_S_GAP_TOKEN) and unprotected data similar for other message sequencing related status codes DUPLICATE, OLD, UNSEQ also a gss-api mechanism may or may not return unprotected data from gss_unwrap() that failes with GSS_S_CONTEXT_EXPIRED. > > then have those __gss_c_no_*() functions use thread-local storage to > store thread-local name/cred object handles. > > Apps would: > > #define GSS_C_APPLICATION_PROFILE "imap-client" > #include YUCK! An approach that provides binary plug-n-play capabilities would be so much more useful. Having to completely recompile everything from scratch every time something is changed in a gssapi mechanism would be extremely annoying. Also, expecting applications to #include a mechanism-specific header file during compilation of the application is a huge problem by itself. A design that limits an application to access only a single gssapi mechanism per application binary seems awkward to me. You really want your application binary to be independent from any particular gssapi mechanism (or worse, a very specific version of that mechanism). Binary plug-n-play means all gssapi header files must be 100% binary compatible to each other, and at that point, the app simply compiles with its own gssapi header file exclusively. For us, binary plug-n-play of GSS-API mechanisms has been working extremely well throughout the last 15 years with more than a dozen independent products. (Except maybe for the hosed Apples Kerberos 5 on Mac OS X 64-bit, which has been compiled with a #pragma pack(push,2) misalignment, defying binary interop with mechanism-independent apps and more reasonably compiled gssapi mechanism for that platform). Some background info why the use of #pragma pack(push,2) for a public API might not be a terribly good idea: http://blogs.msdn.com/ce_base/archive/2008/06/27/when-not-to-pack-structures.aspx -Martin From nico@cryptonector.com Fri Mar 25 09:57:44 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BAE03A67D4 for ; Fri, 25 Mar 2011 09:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXlucxEpz73M for ; Fri, 25 Mar 2011 09:57:43 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 5235A3A67B7 for ; Fri, 25 Mar 2011 09:57:43 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id AECCF35005B for ; Fri, 25 Mar 2011 09:59:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=y4TIhfWsMSPnZ3P8ghmECVfF6znLwsUwFDF6nPMYDQ0N ZFkIWSSIaCvp3ia67NidvjEKSMKvNFUqMJ8hfBC2TVmXva1fX2oXuMxHDRMYBFYf rYzHkGl+ILbM6pOL9EAQfgzxa2DIYAG7Z2w2HHcFW8oh0VotqxzA4W8AGhC36JU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=VcdW6qdsi7Y/FbyVOJXQU8jjFyQ=; b=l6Xy47nQpeN zD6jabt7ul3RfchCm1+PAVJX+LxG2V8u9TWSItB/HdwaO5rl9+Rixa4nayDJrymO aCeHou0HMo8uj6c3AveLXRsreGhxNzk6d8bEiYNP3hbpzt/qBuHfpNLHkJr3dfjp eDqd2I+9wcYNxWktPvnNIhj11mwtC4XU= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 8C25D35007F for ; Fri, 25 Mar 2011 09:59:18 -0700 (PDT) Received: by vws12 with SMTP id 12so1051123vws.31 for ; Fri, 25 Mar 2011 09:59:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.168.8 with SMTP id zs8mr1433559vdb.184.1301072357757; Fri, 25 Mar 2011 09:59:17 -0700 (PDT) Received: by 10.52.159.4 with HTTP; Fri, 25 Mar 2011 09:59:17 -0700 (PDT) In-Reply-To: <1300978049.3985.79.camel@destiny> References: <12791_1300954096_p2O88F3Y020419_AANLkTinTG151J_FPgFv3wy_hzgERNGyLPB+DGptYvXM5@mail.gmail.com> <1300978049.3985.79.camel@destiny> Date: Fri, 25 Mar 2011 11:59:17 -0500 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] PGSSAPI, take two X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 16:57:44 -0000 On Thu, Mar 24, 2011 at 9:47 AM, Jeffrey Hutzelman wrote: > On Thu, 2011-03-24 at 03:08 -0500, Nico Williams wrote: >> A few years ago there was a proposal for a "PGSSAPI" where GSS >> functions were augmented with an additional caller context argument. >> I then proposed overloading the minor_status argument, but no one >> liked that. =C2=A0Later I proposed a GSS-APIv3, but that won't happen >> anytime soon. =C2=A0Then Love proposed just adding an additional context >> argument to a small handful of new functions. >> >> I'm starting to think that we need so badly to add such this feature >> (caller contexts) to the API real soon. > > What problem are you trying to solve? A set of problems that keeps coming up, ALL related to layered software. The layered software context is: one process with two or more uses of the GSS-API, one or more of which is buried in various libraries (or plugins to libraries), and where two or more of those need different mechglue or mechanism configurations. The layered software problem has become rather pervasive in recent years. Anyone with experience with Apache, PAM, LDAP, and so on can attest to this. The layered software problem is related to DLL Hell, except that we need not have two or more GSS-API implementations involved here. And no, it's not a good idea to address the layered software problem by resorting to DLL Hell :) (i.e., have multiple distinct GSS implementations so that each layered use of the GSS-API can get its own GSS implementation). In the original PGSSAPI proposal the poster needed to be able to configure the mechglue differently so that they could have different providers for the same mechanism in two consumers of the GSS-API in the same process. In more recent cases there are desires to specify policy that must be passed to the provider. For example, enctype policy, though there are many other example policies. Sam et. al. seem likely to resort to all sorts of credentials options type extensions to address some of these. But in most if not all cases it would suffice to have the policy stored in a file (or whatever, just not specified in detail in the API itself) and then name this policy to the API. My modest proposal achieves that and allows the application code (well, the GSS-API consumer) to remain quite simple. In the GSS-APIv3 prototype I started on and abandoned a couple of years ago I had a caller context handle as an input to all functions (and no minor_status, that being subsumed into the caller context handle), and a variety of functions by which one could profile the mechglue/mechanisms via this caller context. I think such a thing would still be useful, but it's obviously way too late to the market, which motivates me to pursue something much simpler now as a bandaid. Nico -- From nico@cryptonector.com Fri Mar 25 10:41:07 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4243A680B for ; Fri, 25 Mar 2011 10:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIa7T8Szyfpo for ; Fri, 25 Mar 2011 10:41:06 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 699E73A680A for ; Fri, 25 Mar 2011 10:41:06 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id E8BF842807B for ; Fri, 25 Mar 2011 10:42:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=nkYKScSVY3XRbf7dvf+NgjsXce4sD4cKrX3xoRGQ6c+k gOm97zSnQV7eSP6MuNPHfOSb3nCh75fAoToeuFfF0QO3FXizosUCybC9ARtD+9C2 lBSWWIfE0HSa+3lqSH4ogkgJ2riw7Z/XRAF5L7ioACN55Fr7l6OBy5biWEHNIDE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=fDIOk6MLMU3eI1+A5eeD4+2Xu60=; b=iReYUPI2AiP OZ8aKAStBQ3ZtaGFy25xRF8ZPr5f/ieyIn9zA9XWAqyexhhM05QpH2oenhbd7O7h XepT3fEArD2ez7lC5FIrwtQ8ZCe7ob8SSkfBvruN39oWlDu4660d/DfK1tkFlQHR vJMkYY+RsG2WRwkW9VZHtpjZcZXXn9RE= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (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 B5F44428072 for ; Fri, 25 Mar 2011 10:42:41 -0700 (PDT) Received: by vxg33 with SMTP id 33so1091987vxg.31 for ; Fri, 25 Mar 2011 10:42:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.179.69 with SMTP id de5mr1475681vdc.304.1301074959100; Fri, 25 Mar 2011 10:42:39 -0700 (PDT) Received: by 10.52.159.4 with HTTP; Fri, 25 Mar 2011 10:42:39 -0700 (PDT) In-Reply-To: <201103250152.p2P1quAR010648@fs4113.wdf.sap.corp> References: <201103250152.p2P1quAR010648@fs4113.wdf.sap.corp> Date: Fri, 25 Mar 2011 12:42:39 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] PGSSAPI, take two X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 17:41:07 -0000 On Thu, Mar 24, 2011 at 8:52 PM, Martin Rex wrote: > Nico Williams wrote: >> >> A few years ago there was a proposal for a "PGSSAPI" where GSS >> functions were augmented with an additional caller context argument. > > Admittedly, my memories about this discussion are quite weak. > > [...] > > I completely fail to understand the motivation behind this. > Do you have any specific example about the purpose or what exactly > you're trying to achieve. =C2=A0The use of these particular constants > is limited to very specific purposes, so if you desire is to get > an additional context handle, this would leave all other usage > scenarios of the gss-api calls out in the cold. See my follow-up to Jeff. I should have included that background information when I posted this. > To me, this particular example looks quite incompatible to the > GSS-API v2 architecture and design. > > GSS_C_NO_NAME and GSS_C_NO_CREDENTIAL are really only shortcuts > to represent the _absence_ of a parameter -- on both, input to > a GSS-API call as well as output of a GSS-API call. In the C bindings they are also implementation-specific (since the gss_name_t and gss_cred_id_t types are also implementation-specific). Thus it seems perfectly fair for these values to be macros that expand into function calls (not too unlike what happened to 'errno' in the world of pthreads). I'd worry more about comparisons of GSS_C_NO_{NAME, CREDENTIAL} to values of gss_name_t/gss_cred_id_t output by inquiry functions (and deleg_cred in the gss_accept_sec_context() case). But the implementation can easily arrange for that to work out. (This means that these values cannot be thread-specific, but must be process-global. It also means that they leak until the GSS-API library de-initializes, which only really happens implicitly when the shared object is unloaded, which mostly only happens when the process exits. I'm willing to live with this.) > GSS_C_NO_NAME is somewhat different, but related to GSS_C_NO_CREDENTIALS. > There is no such thing as a "default name" in GSS-API, but in order to > be able to acquire an explicit credentials handle to a credential > with "default credential behaviour", gss_acquire_cred() was modified > to allow not passing a name on input (dubbed "GSS_C_NO_NAME") to > obtain an explicit credentials handle to a credential that exhibits > default credential behaviour. > > GSS_C_NO_NAME is not allowed for other gss-api calls with a > gss_name_t input parameter (such as gss_compare_name, > gss_canonicalize_name or gss_export_name), because of this. GSS_C_NO_NAME is allowed as an input to gss_acquire_cred/gss_add_cred(). A credential whose desired_name is GSS_C_NO_NAME is akin to GSS_C_NO_CREDENTIAL (cred-usage, desired_mechs, and so on can be different from those of GSS_C_NO_CREDENTIAL). In any case, no one passes GSS_C_NO_NAME to gss_compare_name() and so on, but it's perfectly possible for the implementor to check input values of gss_name_t to see that they are not any known value of GSS_C_NO_NAME. For example, an implementation whose gss_name_t is a pointer type could use values 1-4095 to encode values of GSS_C_NO_NAME corresponding to specific profiles, or it could use the two least significant bits of the pointer value to do the same. Similarly for GSS_C_NO_CREDENTIAL. (Technically such tricks are non-portable, in practice they are perfectly portable to all the major OSes and C compilers I know of, and should even be portable to strange architectures such as the Burrows, none of which really exist today, and even if not, implementors on such architectures should be able to find workable ways to encode these things.) > GSS-API functions are allowed to fail, and still return output > parameters, so it is really important to be able to recognize > whether an output parameter is present (which implies it must > be released by the caller later on) or absent. See above! >> Apps would: >> >> #define GSS_C_APPLICATION_PROFILE "imap-client" >> #include > > YUCK! > > An approach that provides binary plug-n-play capabilities would > be so much more useful. =C2=A0Having to completely recompile everything > from scratch every time something is changed in a gssapi mechanism > would be extremely annoying. Why would this not be binary compatible with prior versions of the same implementation? Of course it is! Older object code will be using the original GSS_C_NO_{NAME, CREDENTIAL} value (almost everywhere NULL, or 0), which the new implementation should gladly accept and treat as intended. Look ma! ABI compatible! > Also, expecting applications to #include a mechanism-specific > header file during compilation of the application is a huge problem > by itself. =C2=A0A design that limits an application to access only > a single gssapi mechanism per application binary seems awkward to me. Who said anything about a mechanism-specific header?! I didn't. > You really want your application binary to be independent from > any particular gssapi mechanism (or worse, a very specific version > of that mechanism). =C2=A0Binary plug-n-play means all gssapi header > files must be 100% binary compatible to each other, and at that > point, the app simply compiles with its own gssapi header file > exclusively. Remember, the header in RFC2744 is NOT complete. RFC2744 does NOT specify an ABI. (Some of us wish it had, but that's another story.) Nico -- From mrex@sap.com Fri Mar 25 11:56:34 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B4E3A6784 for ; Fri, 25 Mar 2011 11:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.921 X-Spam-Level: X-Spam-Status: No, score=-9.921 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zei7QK0QCx92 for ; Fri, 25 Mar 2011 11:56:33 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 3AAA93A63D2 for ; Fri, 25 Mar 2011 11:56:32 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2PIw2eO027225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Mar 2011 19:58:02 +0100 (MET) From: Martin Rex Message-Id: <201103251858.p2PIw12r013906@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Fri, 25 Mar 2011 19:58:01 +0100 (MET) In-Reply-To: from "Nico Williams" at Mar 25, 11 12:42:39 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] PGSSAPI, take two X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 25 Mar 2011 18:56:34 -0000 Nico Williams wrote: > > > You really want your application binary to be independent from > > any particular gssapi mechanism (or worse, a very specific version > > of that mechanism).  Binary plug-n-play means all gssapi header > > files must be 100% binary compatible to each other, and at that > > point, the app simply compiles with its own gssapi header file > > exclusively. > > Remember, the header in RFC2744 is NOT complete. RFC2744 does NOT > specify an ABI. (Some of us wish it had, but that's another story.) Are you refering to these 4 definitions: typedef gss_ctx_id_t; typedef gss_cred_id_t; typedef gss_name_t; typedef gss_uint32; that portable apps (that started out with 16-bit Windows support in 1995) defined like this: typedef void FAR * gss_ctx_id_t; typedef void FAR * gss_cred_id_t; typedef void FAR * gss_name_t; #include #if UINT_MAX >= 0x10000ul /* Win 16-bit with 16-bit ints */ typedef unsigned int gss_uint32; #else typedef unsigned long gss_uint32; #endif Nope, the interop problem I've encountered didn't affect any of those, but instead this one: typedef struct gss_OID_desc_struct { OM_uint32 length; void FAR * elements; } gss_OID_desc, FAR * gss_OID; Which requires a padding between "length" and "elements" on 64-bit platforms, and there had a differing definition been used by X/Open (which caused very brief interop problems on HP-UX 11.0, but HP was quick to fix this), and reliably causes bus errors on Mac OS X due to the #pragma pack(push,2) in Apple's weird gssapi.h header. -Martin From nico@cryptonector.com Fri Mar 25 12:51:31 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79EB73A6838 for ; Fri, 25 Mar 2011 12:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jad9-8qnUAvn for ; Fri, 25 Mar 2011 12:51:30 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id 5F0493A682D for ; Fri, 25 Mar 2011 12:51:30 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id DE8A450807C for ; Fri, 25 Mar 2011 12:53:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=jXNeuIvt3FAra5xS3STuXMy8pfHeG4DulbbOxr7GcGvm +XI1OKVF1uAAbIfgMfnu4uVePslgSWAz5v4hhUJVEISANO6c7qXeymx9w35RBxog +E1pvSWVeIhCqXLY3hxsCnpRuaFA9EoK6b8mU2kP+QraZN1hmCMmKN8DCgSgqak= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=fbjEa4ISXq8VEsNjmlieBIw5gIY=; b=ESJVy1BKk7G ZO9rGz8FKvMj3OLJu9fszbfCJY8PJE8BhwbepETgHkCv5hlycH74DNRBuYPwz+NG /dvgMiOgFkztBRQev1nwH5Dy1hjA1YhnocD62XNqV7IWSry+L3D6rHP2J6N4SwYc AR9wavWI4qesh6Qhwz6LMSYMfVjja1Oc= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (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 A6CF2508078 for ; Fri, 25 Mar 2011 12:53:05 -0700 (PDT) Received: by vxg33 with SMTP id 33so1188417vxg.31 for ; Fri, 25 Mar 2011 12:53:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.200 with SMTP id 8mr1668057vdg.70.1301082785080; Fri, 25 Mar 2011 12:53:05 -0700 (PDT) Received: by 10.52.162.70 with HTTP; Fri, 25 Mar 2011 12:53:04 -0700 (PDT) In-Reply-To: <201103251858.p2PIw12r013906@fs4113.wdf.sap.corp> References: <201103251858.p2PIw12r013906@fs4113.wdf.sap.corp> Date: Fri, 25 Mar 2011 14:53:04 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] PGSSAPI, take two X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 19:51:31 -0000 On Fri, Mar 25, 2011 at 1:58 PM, Martin Rex wrote: > Nico Williams wrote: >> >> > You really want your application binary to be independent from >> > any particular gssapi mechanism (or worse, a very specific version >> > of that mechanism). =C2=A0Binary plug-n-play means all gssapi header >> > files must be 100% binary compatible to each other, and at that >> > point, the app simply compiles with its own gssapi header file >> > exclusively. >> >> Remember, the header in RFC2744 is NOT complete. =C2=A0RFC2744 does NOT >> specify an ABI. =C2=A0(Some of us wish it had, but that's another story.= ) > > Are you refering to these 4 definitions: > > =C2=A0 typedef gss_ctx_id_t; > =C2=A0 typedef gss_cred_id_t; > =C2=A0 typedef gss_name_t; > > =C2=A0 typedef gss_uint32; > > > that portable apps (that started out with 16-bit Windows support in 1995) > defined like this: > > =C2=A0 typedef void FAR * gss_ctx_id_t; > =C2=A0 typedef void FAR * gss_cred_id_t; > =C2=A0 typedef void FAR * gss_name_t; Yes, though implementations nowadays define them like this instead: typedef struct gss_ctx_id *gss_ctx_id_t; typedef struct gss_cred_id *gss_cred_id_t; typedef struct gss_name *gss_name_t; That's from Solaris. MIT krb5 does the same thing, with more lines: struct gss_name_struct; typedef struct gss_name_struct * gss_name_t; struct gss_cred_id_struct; typedef struct gss_cred_id_struct * gss_cred_id_t; struct gss_ctx_id_struct; typedef struct gss_ctx_id_struct * gss_ctx_id_t; This is *much* better than void * because you actually get static type safety this way. With void * if you pass in a gss_cred_id_t value where a gss_name_t was expected, the compiler does not complain, whereas with pointers to incomplete structs the compiler does. > =C2=A0 #include > =C2=A0 #if UINT_MAX >=3D 0x10000ul > =C2=A0 =C2=A0 =C2=A0/* Win 16-bit with 16-bit ints */ > =C2=A0 =C2=A0 typedef =C2=A0unsigned int =C2=A0gss_uint32; > =C2=A0 #else > =C2=A0 =C2=A0 typedef =C2=A0unsigned long gss_uint32; > =C2=A0 #endif This is different and unrelated. (With C99 we could use uint_least_32_t or whatever it is, except that I'd rather go whole hog for 64 bits for such things in version 3 of the API, but that's another story, for another day.) > Nope, the interop problem I've encountered didn't affect any of those, > but instead this one: > > typedef struct gss_OID_desc_struct { > =C2=A0 =C2=A0 =C2=A0OM_uint32 =C2=A0 =C2=A0 =C2=A0 length; > =C2=A0 =C2=A0 =C2=A0void =C2=A0 =C2=A0 =C2=A0FAR * elements; > } gss_OID_desc, FAR * gss_OID; > > Which requires a padding between "length" and "elements" on 64-bit platfo= rms, > and there had a differing definition been used by X/Open (which caused > very brief interop problems on HP-UX 11.0, but HP was quick to fix this), > and reliably causes bus errors on Mac OS X due to the #pragma pack(push,2= ) > in Apple's weird gssapi.h header. Right. Exposing structs' fields and sizes in APIs is a recipe for disaster. One of the biggest issues in writing a pluggable mechglue with a public plugin interface is memory management, and that's the result of the API having a gss_buffer_t type that is not extensible. Buffers (and OIDs, and OID sets) should have been opaque, with function accessors. Sound heavy-weight? But this is a library whose plugins do _crypto_ operations, and I/O too (network I/O in some cases, no less, with no async version of the relevant functions), so, no, opaque-everything-plus-accessor-functions is not to heavy-weight. Of course, it would have been possible to design public structs that didn't create these memory management problems, but it'd have been easier to just go the opaque route. Nico -- From nico@cryptonector.com Fri Mar 25 14:42:34 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC83028C0FB for ; Fri, 25 Mar 2011 14:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWc0mPRKGXjm for ; Fri, 25 Mar 2011 14:42:33 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id EC78E28C0CE for ; Fri, 25 Mar 2011 14:42:33 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 8870D1B406E for ; Fri, 25 Mar 2011 14:44:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=L5zfvjfQKSSvpu0+Pvlt5 umW4/o4ykrU3oIrxQEYWSce3AT6oDjGQP705FuAqVABS/DzTRxZpggzOyVfNveUq 04O0MlefxSjlUgn8pjMjP5uEtHc9/gxqd/QfMs23myRlDRA+F7f73KH1odu2SJT3 OVXAuq1Fjy+IzTPhVlhnwM= 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=T3oLWA1t05dkrkW5uGMv OZp+o3M=; b=KgSGaEE5pynXMbCGquCOYxn7PjwdV+loa179AdT83tJ6DTwy9hiI +7Jm6atFgtTFYZ98LZtDg8vWjt7EFsntg7K/WAXRkg76xJerVmvPAaS/6pEsaWp5 kvNyPY9UH/3cU8p8yIBqVLzVuvs4+QLIxCZoU5P+BKGhNXjujCHtqjQ= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 6422E1B406B for ; Fri, 25 Mar 2011 14:44:09 -0700 (PDT) Received: by vws12 with SMTP id 12so1252535vws.31 for ; Fri, 25 Mar 2011 14:44:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.200 with SMTP id 8mr1815774vdg.70.1301089448663; Fri, 25 Mar 2011 14:44:08 -0700 (PDT) Received: by 10.52.162.70 with HTTP; Fri, 25 Mar 2011 14:44:08 -0700 (PDT) In-Reply-To: References: <201103251858.p2PIw12r013906@fs4113.wdf.sap.corp> Date: Fri, 25 Mar 2011 16:44:08 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] PGSSAPI, take two X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 21:42:34 -0000 To be fair, this proposal would break if there were libraries that export interfaces that take or return gss_name_t or gss_cred_id_t values and GSS_C_NO_NAME/CREDENTIAL can be used, but the break would only happen if the application and the library use this new feature and use different profiles, else there'd be no break. I think that's a reasonable limitation. From william.polk@nist.gov Sun Mar 27 05:40:58 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D401328C137 for ; Sun, 27 Mar 2011 05:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.632 X-Spam-Level: X-Spam-Status: No, score=-6.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvD27B977LGA for ; Sun, 27 Mar 2011 05:40:58 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 0596C28C136 for ; Sun, 27 Mar 2011 05:40:57 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p2RCgFZr020868; Sun, 27 Mar 2011 08:42:15 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Sun, 27 Mar 2011 08:41:45 -0400 From: "Polk, William T." To: "kitten@ietf.org" Date: Sun, 27 Mar 2011 08:41:25 -0400 Thread-Topic: Welcoming Alexey Melnikov as third chair for kitten Thread-Index: AQHL7HxIOflE3FMQIk6DYlexBIzYJA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: [kitten] Welcoming Alexey Melnikov as third chair for kitten X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 12:40:58 -0000 Folks, Sean, Stephen, and I have asked Alexey Melnikov to be the third chair for the kitten working group after receiving a suggestion from Shawn and Tom. This will allow all three of them to balance day job workloads and schedules with those of the IETF. We are very pleased that Alexey has accepted our offer, and are looking forward to his continued contributions in kitten. (Almost as important, this means Alexey has to stay on Security Directorate review team!) Thanks, Tim Polk From stpeter@stpeter.im Mon Mar 28 07:03:40 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E172E3A6820 for ; Mon, 28 Mar 2011 07:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7entVbjhfGl for ; Mon, 28 Mar 2011 07:03:40 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0EC513A63EB for ; Mon, 28 Mar 2011 07:03:40 -0700 (PDT) Received: from dhcp-12cb.meeting.ietf.org (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8EE8740022 for ; Mon, 28 Mar 2011 08:06:52 -0600 (MDT) Message-ID: <4D90959B.6030406@stpeter.im> Date: Mon, 28 Mar 2011 16:05:15 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "kitten@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060300000805000401010503" Subject: [kitten] SCRAM implementations in the XMPP community X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 14:03:41 -0000 This is a cryptographically signed message in MIME format. --------------ms060300000805000401010503 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just so you know, at the XMPP WG interim meeting last month I asked the participating developers about who had implemented SCRAM (RFC 5802). I then also asked the question on the main discussion list for developers in the XMPP community. As a result, I can say that we have a number of implementations (probably not limited to the following)... Servers M-Link Prosody SoapBox Server Libraries CAXL Jabber-Net MatriX Telepathy Clients Empathy Gajim Pidgin Pandion Psi SoapBox Communicator Swift Some of these even support channel bindings, although I don't have a good count of those. I'm sure there are more on the way, too. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060300000805000401010503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMy ODE0MDUxNVowIwYJKoZIhvcNAQkEMRYEFF+xJZycA3zlMxwQZNvSzVpjW3ZfMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBT8OXdwQAdzNYYtIs9wjgc1D2BsFq+DDdVbfZ/Re+HKis+y7QiSa8QCoFu Cb9tKgac3Bpa+Cs4O+VqpeIvP3Ad1rATpnMne8DPSxQBzhX+StaqEsXM18vKC100nwTHTM/P kTUP37vPZKp/l9WZnmdOqzWGxJmkzC2eSE6DgcD0t3ZgMouSjQIOolo63fbj97tHXI8gA0bc +6ZQjjileETQm6KqNKVjYUdPlgIsK1lhhXoNuVLIp+zyljS+EecvTScdBwRvvSUHGy1h/PGA kJdfga/38aS7HHbg4QfiHYjVn08BbGpF0RiIRLVoRsxFuPS6o1za+VVX3sidGEu63ArvAAAA AAAA --------------ms060300000805000401010503-- From dave@cridland.net Mon Mar 28 07:17:31 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AADB3A681E for ; Mon, 28 Mar 2011 07:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EayYTCpk+I29 for ; Mon, 28 Mar 2011 07:17:30 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id C33B03A6810 for ; Mon, 28 Mar 2011 07:17:29 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 8770A116808D for ; Mon, 28 Mar 2011 15:19:06 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkX1hVBoY1gu for ; Mon, 28 Mar 2011 15:19:04 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 3A62A1168067 for ; Mon, 28 Mar 2011 15:19:04 +0100 (BST) References: <4D90959B.6030406@stpeter.im> In-Reply-To: <4D90959B.6030406@stpeter.im> MIME-Version: 1.0 Message-Id: <4126.1301321944.211198@puncture> Date: Mon, 28 Mar 2011 15:19:04 +0100 From: Dave Cridland To: Common Authentication Technologies - Next Generation Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [kitten] SCRAM implementations in the XMPP community X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 14:17:31 -0000 On Mon Mar 28 15:05:15 2011, Peter Saint-Andre wrote: > Servers > M-Link Supports channel bindings, same code in M-Box, an IMAP server, interop tested with a GNU SASL based client. > Prosody > SoapBox Server > > Libraries > CAXL > Jabber-Net > MatriX > Telepathy > > Clients > Empathy > Gajim I'd note for the record that I wrote this support into Gajim, and based it on the code from Polymer - however it's simpler, and doesn't do channel bindings. > Pidgin > Pandion > Psi > SoapBox Communicator > Swift > > Swift also supports channel bindings, interop tested against M-Link (and maybe others). Swift actually has a library Swiften which contains the code. Finally, both M-Link and M-Box were also tested against my implementation (developed independently), Polymer, which also does channel bindings. Polymer was also tested against a GNU SASL based IMAP server. So there are at least three clients and two servers known to interoperate in various combinations with SCRAM-SHA1-PLUS. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From jehan.marmottard@gmail.com Mon Mar 28 08:17:29 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0769E3A67FB for ; Mon, 28 Mar 2011 08:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBLYIXVAIOzE for ; Mon, 28 Mar 2011 08:17:27 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 460963A67D6 for ; Mon, 28 Mar 2011 08:17:27 -0700 (PDT) Received: by wyb29 with SMTP id 29so2762753wyb.31 for ; Mon, 28 Mar 2011 08:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=93mOXnKLDuqFrNW3e/4TVasig3/n3pz9hDSw51sTdF0=; b=HIP1Hu8XDbOcqs6gXjUJKRRl3L/sdPqaVN+S/jlruPBK2yJUJvaLEvE6/+qzity/gS ugFIgydocMwKwq2ttIHiVNAcImygf9WWcreEr2AGf8VjspIhOHk5nVOCR8dup442/hOF e9EltDkox3sr4+wyrZaCKEyWFSuiSaCx1NL4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sRvSO0AmHrQqTAXi6c1OUaAvEgvbdsYHoiKJElSN/zAmBRB4Mt6GZ+a6FFmjqrQCyd 242ba6IzZM2i5M3wURZyfQXNJ7GSoxeddlP5oqlbUkSkXcmEIVxyMRbtE9j/BoaFFlTR rrkCJ+guEXd6+RC+BdUhFh0qFGq4JXW5v6Jcw= MIME-Version: 1.0 Received: by 10.216.134.230 with SMTP id s80mr3665595wei.74.1301325544217; Mon, 28 Mar 2011 08:19:04 -0700 (PDT) Received: by 10.216.246.69 with HTTP; Mon, 28 Mar 2011 08:19:04 -0700 (PDT) In-Reply-To: <4D90959B.6030406@stpeter.im> References: <4D90959B.6030406@stpeter.im> Date: Tue, 29 Mar 2011 00:19:04 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] SCRAM implementations in the XMPP community X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 15:17:29 -0000 Hi Peter, I have implemented SCRAM (no channel binding yet) for a XMPP library as well. It was not done when you asked on the list so I didn't answered, plus the library itself is not usable yet: OX (OCaml XMPP): http://ox.tuxfamily.org/ Just to add to the list of existing SCRAM implementations. Jehan On Mon, Mar 28, 2011 at 11:05 PM, Peter Saint-Andre wr= ote: > Just so you know, at the XMPP WG interim meeting last month I asked the > participating developers about who had implemented SCRAM (RFC 5802). I > then also asked the question on the main discussion list for developers > in the XMPP community. As a result, I can say that we have a number of > implementations (probably not limited to the following)... > > Servers > =A0M-Link > =A0Prosody > =A0SoapBox Server > > Libraries > =A0CAXL > =A0Jabber-Net > =A0MatriX > =A0Telepathy > > Clients > =A0Empathy > =A0Gajim > =A0Pidgin > =A0Pandion > =A0Psi > =A0SoapBox Communicator > =A0Swift > > Some of these even support channel bindings, although I don't have a > good count of those. > > I'm sure there are more on the way, too. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > From alexey.melnikov@isode.com Tue Mar 29 03:49:08 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7623A6948 for ; Tue, 29 Mar 2011 03:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.126 X-Spam-Level: X-Spam-Status: No, score=-102.126 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, SARE_OBFU_PART_INA=0.786, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAiBMk1AYKz3 for ; Tue, 29 Mar 2011 03:49:07 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2F26628C0E7 for ; Tue, 29 Mar 2011 03:49:07 -0700 (PDT) Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 29 Mar 2011 11:50:44 +0100 Message-ID: <4D91B96D.60901@isode.com> Date: Tue, 29 Mar 2011 12:50:21 +0200 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: kitten@ietf.org References: <20110222221502.2162.22327.idtracker@localhost> In-Reply-To: <20110222221502.2162.22327.idtracker@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [kitten] Comments on draft-josefsson-kitten-crotp-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 10:49:08 -0000 Internet-Drafts@ietf.org wrote: [...] >The CROTP mechanism family provide support for two-factor >authentication using a static long-term password and a single use >changing one-time password (OTP) in the SASL and GSS-API frameworks. >The design of CROTP is based on SCRAM described in RFC 5802. CROTP >works with several OTP system, including the Open AuTHentication HOTP >algorithm described in RFC 4226. > > Some quick comments on the draft (which looks quite reasonable otherwise): 4. Protocol ;; variant used by CROTP otp = "o=" saslname What is the exact semantics of this field? Does it need an IANA registry? [TODO: Require TLS for OTP protection, or derive keys from the SCRAM negotiation and GSS_Wrap the OTP?] I would personally prefer the latter, to keep this more generic. 7. IANA Considerations IANA has added the following family of SASL mechanisms to the SASL I think this should use future tense for now. Mechanism registry established by [RFC4422]: Note: The family names are intended to match the SCRAM names, and uses the same (but separate) registration policy. Registration of CROTP names should be reviewed for alignment with similar SCRAM names. XXX: registration policy? Yes, something needs to be done about that :-). From simon@josefsson.org Tue Mar 29 05:15:25 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB5E28C0D7 for ; Tue, 29 Mar 2011 05:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.813 X-Spam-Level: X-Spam-Status: No, score=-101.813 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_OBFU_PART_INA=0.786, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAEtw3VQZ-W5 for ; Tue, 29 Mar 2011 05:15:25 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id A47613A68FD for ; Tue, 29 Mar 2011 05:15:24 -0700 (PDT) Received: from latte.josefsson.org ([130.129.18.87]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p2TCGrYe031609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Mar 2011 14:16:57 +0200 From: Simon Josefsson To: Alexey Melnikov In-Reply-To: <4D91B96D.60901__39246.3626609699$1301395857$gmane$org@isode.com> (Alexey Melnikov's message of "Tue, 29 Mar 2011 12:50:21 +0200") References: <20110222221502.2162.22327.idtracker@localhost> <4D91B96D.60901__39246.3626609699$1301395857$gmane$org@isode.com> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110329:kitten@ietf.org::Nt5J2Tcr+HLm5q/D:CD8Z X-Hashcash: 1:22:110329:alexey.melnikov@isode.com::UdDifa56nK7+fIxA:6sv6 Date: Tue, 29 Mar 2011 14:16:18 +0200 Message-ID: <87aage15rh.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-josefsson-kitten-crotp-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:15:26 -0000 Alexey Melnikov writes: > Internet-Drafts@ietf.org wrote: > [...] > >>The CROTP mechanism family provide support for two-factor >>authentication using a static long-term password and a single use >>changing one-time password (OTP) in the SASL and GSS-API frameworks. >>The design of CROTP is based on SCRAM described in RFC 5802. CROTP >>works with several OTP system, including the Open AuTHentication HOTP >>algorithm described in RFC 4226. >> >> > Some quick comments on the draft (which looks quite reasonable otherwise): > > 4. Protocol > > ;; variant used by CROTP > otp = "o=" saslname > > What is the exact semantics of this field? > Does it need an IANA registry? My experience is that the semantics of OTP values are the same as semantics for passwords: they are site-specific. Thus I don't know what more could be said here. Maybe you could give an example of what you are thinking of here? Are you thinking of some kind of "OTP vendor" field? Hm. What _would_ be useful is for the server be able to specify, in server-first-message, a vendor and token identifier, or similar. That will allow the client (or user) to locate the proper OTP token. This also aligns well with draft-ietf-krb-wg-otp-preauth-16. > [TODO: Require TLS for OTP protection, or derive keys from the SCRAM > negotiation and GSS_Wrap the OTP?] > > I would personally prefer the latter, to keep this more generic. If it can be done without modifying the protocol flow (2 complete round-trips) I would agree -- and I think that can be done. However a bigger question is whether an OTP needs to be more than integrity protected at all. > 7. IANA Considerations > > IANA has added the following family of SASL mechanisms to the SASL > > I think this should use future tense for now. > > Mechanism registry established by [RFC4422]: > > Note: The family names are intended to match the SCRAM names, > and uses the same (but separate) registration policy. > Registration of CROTP names should be reviewed for alignment > with similar SCRAM names. XXX: registration policy? > > Yes, something needs to be done about that :-). Thanks, I'll revisit this part if this is going forward at all. /Simon From alexey.melnikov@isode.com Tue Mar 29 05:50:39 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BEEA3A6867 for ; Tue, 29 Mar 2011 05:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.117 X-Spam-Level: X-Spam-Status: No, score=-102.117 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, SARE_OBFU_PART_INA=0.786, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ID5W2rLRsxC for ; Tue, 29 Mar 2011 05:50:38 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 330053A67C3 for ; Tue, 29 Mar 2011 05:50:38 -0700 (PDT) Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 29 Mar 2011 13:52:15 +0100 Message-ID: <4D91D5E7.9040605@isode.com> Date: Tue, 29 Mar 2011 14:51:51 +0200 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Simon Josefsson References: <20110222221502.2162.22327.idtracker@localhost> <4D91B96D.60901__39246.3626609699$1301395857$gmane$org@isode.com> <87aage15rh.fsf@latte.josefsson.org> In-Reply-To: <87aage15rh.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-josefsson-kitten-crotp-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:50:39 -0000 Simon Josefsson wrote: >Alexey Melnikov writes: > > >>Internet-Drafts@ietf.org wrote: >>[...] >> >> >>>The CROTP mechanism family provide support for two-factor >>>authentication using a static long-term password and a single use >>>changing one-time password (OTP) in the SASL and GSS-API frameworks. >>>The design of CROTP is based on SCRAM described in RFC 5802. CROTP >>>works with several OTP system, including the Open AuTHentication HOTP >>>algorithm described in RFC 4226. >>> >>> >>Some quick comments on the draft (which looks quite reasonable otherwise): >> >>4. Protocol >> >> ;; variant used by CROTP >> otp = "o=" saslname >> >>What is the exact semantics of this field? >>Does it need an IANA registry? >> >> >My experience is that the semantics of OTP values are the same as >semantics for passwords: they are site-specific. Thus I don't know what >more could be said here. Maybe you could give an example of what you >are thinking of here? Are you thinking of some kind of "OTP vendor" >field? > > After seeing "saslname", I was expecting some kind of OTP mechanism name here. I actually not entirely sure what you want to put here, so at least seeing some examples would be useful. >Hm. What _would_ be useful is for the server be able to specify, in >server-first-message, a vendor and token identifier, or similar. > Yes, I was expecting this as well. >That >will allow the client (or user) to locate the proper OTP token. This >also aligns well with draft-ietf-krb-wg-otp-preauth-16. > > [...] From simon@josefsson.org Tue Mar 29 05:57:58 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E861F3A683A for ; Tue, 29 Mar 2011 05:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.813 X-Spam-Level: X-Spam-Status: No, score=-101.813 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_OBFU_PART_INA=0.786, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JgEjPDWYWC3 for ; Tue, 29 Mar 2011 05:57:58 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id AB7093A6452 for ; Tue, 29 Mar 2011 05:57:57 -0700 (PDT) Received: from latte.josefsson.org ([130.129.18.87]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p2TCxRbC001039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Mar 2011 14:59:31 +0200 From: Simon Josefsson To: Alexey Melnikov References: <20110222221502.2162.22327.idtracker@localhost> <4D91B96D.60901__39246.3626609699$1301395857$gmane$org@isode.com> <87aage15rh.fsf@latte.josefsson.org> <4D91D5E7.9040605__2707.88193815879$1301403150$gmane$org@isode.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110329:alexey.melnikov@isode.com::0dd6e0uyjd+QOkIV:4AmI X-Hashcash: 1:22:110329:kitten@ietf.org::LA2DaYLnGlDKW06A:C6CQ Date: Tue, 29 Mar 2011 14:58:52 +0200 In-Reply-To: <4D91D5E7.9040605__2707.88193815879$1301403150$gmane$org@isode.com> (Alexey Melnikov's message of "Tue, 29 Mar 2011 14:51:51 +0200") Message-ID: <87tyemytf7.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-josefsson-kitten-crotp-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:57:59 -0000 Alexey Melnikov writes: > Simon Josefsson wrote: > >>Alexey Melnikov writes: >> >> >>>Internet-Drafts@ietf.org wrote: >>>[...] >>> >>> >>>>The CROTP mechanism family provide support for two-factor >>>>authentication using a static long-term password and a single use >>>>changing one-time password (OTP) in the SASL and GSS-API frameworks. >>>>The design of CROTP is based on SCRAM described in RFC 5802. CROTP >>>>works with several OTP system, including the Open AuTHentication HOTP >>>>algorithm described in RFC 4226. >>>> >>>> >>>Some quick comments on the draft (which looks quite reasonable otherwise): >>> >>>4. Protocol >>> >>> ;; variant used by CROTP >>> otp = "o=" saslname >>> >>>What is the exact semantics of this field? >>>Does it need an IANA registry? >>> >>> >>My experience is that the semantics of OTP values are the same as >>semantics for passwords: they are site-specific. Thus I don't know what >>more could be said here. Maybe you could give an example of what you >>are thinking of here? Are you thinking of some kind of "OTP vendor" >>field? >> >> > After seeing "saslname", I was expecting some kind of OTP mechanism > name here. > > I actually not entirely sure what you want to put here, so at least > seeing some examples would be useful. OK -- the intention was just to re-use the ABNF for 'saslname': saslname = 1*(value-safe-char / "=2C" / "=3D") Possibly I should rename this to avoid confusion. Examples values would be something like this: otp=234020 otp=dteffujedcflcindvdbrblehecuitvjkjevvehjd >>Hm. What _would_ be useful is for the server be able to specify, in >>server-first-message, a vendor and token identifier, or similar. >> > Yes, I was expecting this as well. Will add something. Thanks, Simon From nico@cryptonector.com Tue Mar 29 06:55:19 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4093A68FC for ; Tue, 29 Mar 2011 06:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzCK6japuoYy for ; Tue, 29 Mar 2011 06:55:18 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id E78323A6824 for ; Tue, 29 Mar 2011 06:55:16 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 16A3450806D for ; Tue, 29 Mar 2011 06:56:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=VUEEQiaqni/yKdP+vIikz ulDFxrkkMjgE3kd9C5/ZXYuibSaRGAg0dRyKq17IKxXjYRe/E+3fC0SXR+bh8t6k SSQY0nID+ck7lrZ50K++A9z0KfkeDZ9AhdUszWDlhurvv9rgc1R3xxtnOCjxcL5v xMck+FQUrPZquU33PSiLZk= 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=V8ViaAV8+ox26Qxubc/4 RS7k+Rk=; b=tkFUQYD/3BOCVQua2im9jGSsYx73zWxNgw5ba/A9YgvMXqX0ZAhN hRz3344Wwiq+UgwmqeKlqmoyzfQZevQ/PZp1SXNdRDpL7FzqaJ82CVPnfQoCj68z GXgjN2w5Vg490AkFMSg6GdMCgjrJcII0gKoSyO9Pq95h/LpiMetkVe0= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (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 E651F508071 for ; Tue, 29 Mar 2011 06:56:54 -0700 (PDT) Received: by vxg33 with SMTP id 33so166306vxg.31 for ; Tue, 29 Mar 2011 06:56:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.169.39 with SMTP id ab7mr7396649vdc.230.1301407014196; Tue, 29 Mar 2011 06:56:54 -0700 (PDT) Received: by 10.52.162.70 with HTTP; Tue, 29 Mar 2011 06:56:54 -0700 (PDT) Received: by 10.52.162.70 with HTTP; Tue, 29 Mar 2011 06:56:54 -0700 (PDT) In-Reply-To: <87aage15rh.fsf@latte.josefsson.org> References: <20110222221502.2162.22327.idtracker@localhost> <4D91B96D.60901__39246.3626609699$1301395857$gmane$org@isode.com> <87aage15rh.fsf@latte.josefsson.org> Date: Tue, 29 Mar 2011 08:56:54 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: multipart/alternative; boundary=bcaec53f9069ca185c049f9f6ecf Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-josefsson-kitten-crotp-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:55:19 -0000 --bcaec53f9069ca185c049f9f6ecf Content-Type: text/plain; charset=UTF-8 When do OTPs _not_ need confidentiality protection? I believe they always do. Moreover, for those doing two-factor authentication, protecting the OTP with a pasword-derived key is out (since an attwacker that knows the password can MITM the user). In other words, OTP really wants TLS or PKU2U in the GSS context. It also wants another mech to do password-based auth (SCRAM, IAKERB, ...). IOW, OTP in GSS really wants to be like a pseudo-mechanism that combines two other concrete mechanisms. And yet it could be done in three round-trips, and with with some cleverness in just two! (the margins of this e-mail lack space for me to share that [or, rather, I'll explain later if t' still relevant, but also, it's fairly obvious.]). But I have to wonder, with GSS-EAP and IAKERB, do we _really_ need an OTP mech? (A: well, if you want krb5 preauth based on GSS... -ed. Oh, that's right!). Nico -- --bcaec53f9069ca185c049f9f6ecf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

When do OTPs _not_ need confidentiality protection?=C2=A0 I believe they= always do.=C2=A0 Moreover, for those doing two-factor authentication, prot= ecting the OTP with a pasword-derived key is out (since an attwacker that k= nows the password can MITM the user).

In other words, OTP really wants TLS or PKU2U in the GSS context. It als= o wants another mech to do password-based auth (SCRAM, IAKERB, ...).=C2=A0 = IOW, OTP in GSS really wants to be like a pseudo-mechanism that combines tw= o other concrete mechanisms.=C2=A0 And yet it could be done in three round-= trips, and with with some cleverness in just two! (the margins of this e-ma= il lack space for me to share that [or, rather, I'll explain later if t= ' still relevant, but also, it's fairly obvious.]).

But I have to wonder, with GSS-EAP and IAKERB, do we _really_ need an OT= P mech?=C2=A0 (A: well, if you want krb5 preauth based on GSS... -ed.=C2=A0= Oh, that's right!).

Nico
--

--bcaec53f9069ca185c049f9f6ecf-- From simon@josefsson.org Tue Mar 29 08:52:35 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2C43A6A4E for ; Tue, 29 Mar 2011 08:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.906 X-Spam-Level: X-Spam-Status: No, score=-101.906 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ja18ctouCkg for ; Tue, 29 Mar 2011 08:52:31 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 6281D3A67E4 for ; Tue, 29 Mar 2011 08:52:31 -0700 (PDT) Received: from latte.josefsson.org ([130.129.18.87]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p2TFrs3Y009179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Mar 2011 17:53:57 +0200 From: Simon Josefsson To: Nico Williams References: <20110222221502.2162.22327.idtracker@localhost> <4D91B96D.60901__39246.3626609699$1301395857$gmane$org@isode.com> <87aage15rh.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110329:kitten@ietf.org::RmsdihMVs5jwo8Iu:3Fl3 X-Hashcash: 1:22:110329:nico@cryptonector.com::UYvrZ3WeqsFIIeKg:SBDy Date: Tue, 29 Mar 2011 17:53:19 +0200 In-Reply-To: (Nico Williams's message of "Tue, 29 Mar 2011 08:56:54 -0500") Message-ID: <877hbh2aa8.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-josefsson-kitten-crotp-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 15:52:35 -0000 Nico Williams writes: > When do OTPs _not_ need confidentiality protection? I believe they always > do. Moreover, for those doing two-factor authentication, protecting the OTP > with a pasword-derived key is out (since an attwacker that knows the > password can MITM the user). Good point. > In other words, OTP really wants TLS or PKU2U in the GSS context. It also > wants another mech to do password-based auth (SCRAM, IAKERB, ...). IOW, OTP > in GSS really wants to be like a pseudo-mechanism that combines two other > concrete mechanisms. And yet it could be done in three round-trips, and > with with some cleverness in just two! (the margins of this e-mail lack > space for me to share that [or, rather, I'll explain later if t' still > relevant, but also, it's fairly obvious.]). In the extreme, you could have a multi-factor meta-GSS mechanism that combines several mechanism into providing multi-factor authentication. However, how to resolve the problem you brought up about deriving keys that are protecting the OTP from something other than the password? Perhaps TLS is necessary here after all. > But I have to wonder, with GSS-EAP and IAKERB, do we _really_ need an OTP > mech? (A: well, if you want krb5 preauth based on GSS... -ed. Oh, that's > right!). I guess it is an open question whether we need this. My use case is making some GSS-API and SASL applications support username+OTP. You can't always assume Kerberos is present in these environments. /Simon From hartmans@mit.edu Tue Mar 29 12:33:00 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D12F28C0E3 for ; Tue, 29 Mar 2011 12:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.319 X-Spam-Level: X-Spam-Status: No, score=-103.319 tagged_above=-999 required=5 tests=[AWL=-1.654, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrABtkhDGWk2 for ; Tue, 29 Mar 2011 12:32:59 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B7CAF28C0E4 for ; Tue, 29 Mar 2011 12:32:59 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-479c.meeting.ietf.org [130.129.71.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9A48920265; Tue, 29 Mar 2011 15:31:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CC66A4541; Tue, 29 Mar 2011 15:34:33 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <20110222221502.2162.22327.idtracker@localhost> <4D91B96D.60901__39246.3626609699$1301395857$gmane$org@isode.com> <87aage15rh.fsf@latte.josefsson.org> <877hbh2aa8.fsf@latte.josefsson.org> Date: Tue, 29 Mar 2011 15:34:33 -0400 In-Reply-To: <877hbh2aa8.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 29 Mar 2011 17:53:19 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-josefsson-kitten-crotp-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 19:33:00 -0000 >>>>> "Simon" == Simon Josefsson writes: >> But I have to wonder, with GSS-EAP and IAKERB, do we _really_ >> need an OTP mech? (A: well, if you want krb5 preauth based on >> GSS... -ed. Oh, that's right!). Simon> I guess it is an open question whether we need this. My use Simon> case is making some GSS-API and SASL applications support Simon> username+OTP. You can't always assume Kerberos is present in Simon> these environments. Well, perhaps not today. IN a couple of years I expect we'll have mini KDC libraries to link into applications Heimdal mostly already does although I suspect it's a bit heavy-weight on the app configuration side of things. However, Kerberos assumes a certain model about passwords. If you have a plaintext legacy password, Kerberos is out. Eap does have a more consistent story than GSS for combining keys. I have not formed a strong opinion; just thoughts on the issues. From hartmans@mit.edu Tue Mar 29 12:46:02 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D0B3A6AA6 for ; Tue, 29 Mar 2011 12:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.436 X-Spam-Level: X-Spam-Status: No, score=-103.436 tagged_above=-999 required=5 tests=[AWL=-1.171, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsg6agokPU51 for ; Tue, 29 Mar 2011 12:46:02 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id EDC123A6A2E for ; Tue, 29 Mar 2011 12:46:01 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-479c.meeting.ietf.org [130.129.71.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 32E5C20384; Tue, 29 Mar 2011 15:44:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 527F44541; Tue, 29 Mar 2011 15:47:38 -0400 (EDT) From: Sam Hartman To: Nico Williams References: Date: Tue, 29 Mar 2011 15:47:38 -0400 In-Reply-To: (Nico Williams's message of "Thu, 24 Mar 2011 03:08:11 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] PGSSAPI, take two X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 19:46:02 -0000 I do not think this solves any of the need for context parameters I've been running into lately. I do think I want context parameters but I don't think I want that so I can select between a compile-time set of profiles. Instead, I think I want it so I can have additional configuration functions (I.E. setters) for the context. So, at least for the use cases I know I have, this proposal would not help. I do share Martin's concern that you do not want to build more mechglue-specific information into gssapi.h without a lot more thought. From hartmans@mit.edu Tue Mar 29 12:52:09 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5D23A6ABB for ; Tue, 29 Mar 2011 12:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.319 X-Spam-Level: X-Spam-Status: No, score=-103.319 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1neJYFqqsJrT for ; Tue, 29 Mar 2011 12:52:08 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 534B53A6AB6 for ; Tue, 29 Mar 2011 12:52:08 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-479c.meeting.ietf.org [130.129.71.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7958D20384; Tue, 29 Mar 2011 15:50:40 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 906AD4541; Tue, 29 Mar 2011 15:53:44 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <4CF91652.2080104@googlemail.com> <25128_1291395225_oB3Griia031936_AANLkTi=NnaG=a-CaiNKFVSsx=8tzKd_Q87wnAJ3CbuXY@mail.gmail.com> <5A6498C4F1AEDE3EC2DDB578@minbar.fac.cs.cmu.edu> <0083F29703B421CF922D1CA7@96B2F16665FF96BAE59E9B90> Date: Tue, 29 Mar 2011 15:53:44 -0400 In-Reply-To: (Nico Williams's message of "Tue, 22 Mar 2011 16:44:16 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] RFC5802: question about unknown-user error X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 19:52:09 -0000 I've been thinking a lot about error handling lately. I don't think I've chimed into this thread. My position with my security geek hat firmly placed on is: There is significant value to reporting detailed error in the security mechanism not in the application protocol. You need the detailed errors to deal with a number of user interface issues, and in most deployments it has been my experience that the information an attacker could gain from detailed errors is already present elsewhere in the environment. You need the errors in the security mechanism not in the application protocol when your mechanisms are part of a platform, because a number of user experience items, such as the appropriate credentials to use for a given service, may be influenced at a platform level. So, the platform needs to be able to interpret the error reporting state. It's relatively easy to pass the error up to the application. It tends not to be the case that the error gets passed down effectively from the application to the platform. So, better behavior is possible for platforms to implement when errors are reported at the mechanism level. I agree there are environments where general error reporting is desirable. I suspect that if I reviewed the 4422 guidance I'd think it was too strong. I am not an implementor or user of scram: my comments are to the general issue. From mrex@sap.com Tue Mar 29 14:14:51 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463693A698F for ; Tue, 29 Mar 2011 14:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.218 X-Spam-Level: X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Av4lmtt0T-Pi for ; Tue, 29 Mar 2011 14:14:50 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 22E303A6825 for ; Tue, 29 Mar 2011 14:14:49 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2TLGIXn022866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Mar 2011 23:16:23 +0200 (MEST) From: Martin Rex Message-Id: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> To: hartmans-ietf@mit.edu (Sam Hartman) Date: Tue, 29 Mar 2011 23:16:18 +0200 (MEST) In-Reply-To: from "Sam Hartman" at Mar 29, 11 03:47:38 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] PGSSAPI, take two X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 21:14:51 -0000 Sam Hartman wrote: > > I do not think this solves any of the need for context parameters I've > been running into lately. I do think I want context parameters but I > don't think I want that so I can select between a compile-time set of > profiles. Instead, I think I want it so I can have additional > configuration functions (I.E. setters) for the context. > > So, at least for the use cases I know I have, this proposal would not > help. > > I do share Martin's concern that you do not want to build more > mechglue-specific information into gssapi.h without a lot more thought. I had exchanged two more private EMails with Nico on this, and as far as I understand, he is looking for a possibility to select between different sets/profiles of default credentials. I don't think that the "desired_name" parameter should be abused for this purpose, and I also don't like the idea of a compile time #define side effect rather than a programmatic feature. Ideally, the additional requirements that have been piling up (requesting specific attributes or selecting a profile, or offering a callback for password prompting a human user) should be implemented with a new GSS-API call gss_acquire_cred_ex(). New API calls may incur a certain overhead for extremely layered software stacks (including mechglue), so maybe Nico would prefer to overload the semantics of the existing API call and parameters. Personally, I would recommend to look at the gss_OID_set "desired_mechs" parameter to gss_acquire_cred() or the "desired_mech" parameter to gss_add_cred(). The ASN.1 OID space is virtually unlimited, and one might define OIDs that aren't OIDs itself, but rather request for certain attributes or profiles, so that this sequence of calls: def_cred = gss_acquire_cred( GSS_C_NO_NAME, GSS_C_NO_OID_SET) def_imap_cred = gss_add_cred( def_cred, IMAP_CRED_PROFILE_OID ); might be able to do what Nico is looking for (and the second call would fail for mechanisms that don't recognize that non-mech-OID) -Martin I just noticed an (editorial) defect in rfc2743 at the top of page 38 within 2.1.4: GSS_Add_cred call, where it lists two output parameters "cred_usage" and "mech_set" which probably should not be there. "cred_usage" is already listed under input parameters an a pure input parameter in the C-Bindings (rfc-2744), and "mech_set" appears to be a duplicate of the "acutal_mechs" output parameter. From mrex@sap.com Tue Mar 29 14:19:06 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C683A68FF for ; Tue, 29 Mar 2011 14:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.218 X-Spam-Level: X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBfi-jpU-p4w for ; Tue, 29 Mar 2011 14:19:04 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 3C25D3A6825 for ; Tue, 29 Mar 2011 14:19:04 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2TLKfWZ023682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Mar 2011 23:20:42 +0200 (MEST) From: Martin Rex Message-Id: <201103292120.p2TLKeDr004672@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Tue, 29 Mar 2011 23:20:40 +0200 (MEST) In-Reply-To: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> from "Martin Rex" at Mar 29, 11 11:16:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: [kitten] PGSSAPI, take two X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 21:19:06 -0000 I'm sorry for the typo. s/that aren't OIDs itself/that aren't Mechanism-OIDs/ already applied in the quoted text. Martin Rex wrote: > > Sam Hartman wrote: > > > > I do not think this solves any of the need for context parameters I've > > been running into lately. I do think I want context parameters but I > > don't think I want that so I can select between a compile-time set of > > profiles. Instead, I think I want it so I can have additional > > configuration functions (I.E. setters) for the context. > > > > So, at least for the use cases I know I have, this proposal would not > > help. > > > > I do share Martin's concern that you do not want to build more > > mechglue-specific information into gssapi.h without a lot more thought. > > > I had exchanged two more private EMails with Nico on this, > and as far as I understand, he is looking for a possibility to select > between different sets/profiles of default credentials. > > I don't think that the "desired_name" parameter should be abused > for this purpose, and I also don't like the idea of a compile time > #define side effect rather than a programmatic feature. > > > Ideally, the additional requirements that have been piling up > (requesting specific attributes or selecting a profile, or > offering a callback for password prompting a human user) > should be implemented with a new GSS-API call gss_acquire_cred_ex(). > > New API calls may incur a certain overhead for extremely layered > software stacks (including mechglue), so maybe Nico would prefer > to overload the semantics of the existing API call and parameters. > > Personally, I would recommend to look at the gss_OID_set "desired_mechs" > parameter to gss_acquire_cred() or the "desired_mech" parameter > to gss_add_cred(). > > The ASN.1 OID space is virtually unlimited, and one might define OIDs > that aren't Mechanism-OIDs, but rather request for certain attributes > or profiles, so that this sequence of calls: > > def_cred = gss_acquire_cred( GSS_C_NO_NAME, GSS_C_NO_OID_SET) > > def_imap_cred = gss_add_cred( def_cred, IMAP_CRED_PROFILE_OID ); > > might be able to do what Nico is looking for (and the second call > would fail for mechanisms that don't recognize that non-mech-OID) > > > -Martin > > > I just noticed an (editorial) defect in rfc2743 at the top of page 38 > within 2.1.4: GSS_Add_cred call, where it lists two output parameters > "cred_usage" and "mech_set" which probably should not be there. > "cred_usage" is already listed under input parameters an a pure input > parameter in the C-Bindings (rfc-2744), and "mech_set" appears to be > a duplicate of the "acutal_mechs" output parameter. From shawn.emery@oracle.com Thu Mar 31 01:11:11 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7DD28C280 for ; Thu, 31 Mar 2011 01:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h21Kn+uPyelC for ; Thu, 31 Mar 2011 01:11:10 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id EEC7328C27A for ; Thu, 31 Mar 2011 01:11:09 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2V8CmI0003385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 31 Mar 2011 08:12:49 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2V8ClOO032488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Mar 2011 08:12:47 GMT Received: from abhmt007.oracle.com (abhmt007.oracle.com [141.146.116.16]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p2V8CltF012144 for ; Thu, 31 Mar 2011 03:12:47 -0500 Received: from dhcp-16b2.meeting.ietf.org (/130.129.22.178) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 31 Mar 2011 01:12:46 -0700 Message-ID: <4D94377D.5040508@oracle.com> Date: Thu, 31 Mar 2011 02:12:45 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 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: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4D94377F.00B6:SCFSTAT5015188,ss=1,fgs=0 Subject: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:11:11 -0000 This message officially starts the Kitten Working Group Last Call for the following document: A SASL and GSS-API Mechanism for SAML http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-02 The Working Group Last Call for this document starts today on Thursday, March 31st and will end on Thursday, April 14th. Please send any comments to the Kitten mailing list or directly to the chairs. Feed-back from reviews that found no issues are also welcome. Thank you, Shawn. -- From stephen.farrell@cs.tcd.ie Thu Mar 31 09:32:28 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24A63A6B32 for ; Thu, 31 Mar 2011 09:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.885 X-Spam-Level: X-Spam-Status: No, score=-106.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlTFUq47X4QM for ; Thu, 31 Mar 2011 09:32:27 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by core3.amsl.com (Postfix) with ESMTP id D40903A6844 for ; Thu, 31 Mar 2011 09:32:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E45AA3E407D for ; Thu, 31 Mar 2011 17:34:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1301589243; bh=kaqMqc4qad209u0kvN++I2YU p0qn1Oc5o08M7XsWNfY=; b=17yKhmvY93h785VQXuHUHBAsVb+M5eeBx11hIHAB tQitVADpfqO5Fe0Du/S3D0by5JBIyDa6Q6fwomSUxlZaK+og730PYCCSMTW0sXZ4 hJXrTd9guPlCIjjWtzuLwqBEoGtcTWZdQ5+To9mXbmk5d++7TcZh4SM+ITFCnSUL rtLE9vBemEjG/NF/hqZczeGc9cMeElBZCTuLPt2RhXIcBjbdzBgWJYn9X0twYFY6 1OkDjmeo0DnV32Xu5sAGwWfxB48vljXzkJfuiFslPQlWcCS3z9dRj51KyEiS4/t/ GDtD/aP26MQ3VAPT2omuXua8SNfGLQDGpZ53YKhpUw/HrA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id q1eyW49f-98W for ; Thu, 31 Mar 2011 17:34:03 +0100 (IST) Received: from [130.129.39.94] (dhcp-275e.meeting.ietf.org [130.129.39.94]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id AFEDF3E406F for ; Thu, 31 Mar 2011 17:34:03 +0100 (IST) Message-ID: <4D94ACE6.4020203@cs.tcd.ie> Date: Thu, 31 Mar 2011 17:33:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [kitten] AD review of draft-ietf-kitten-digest-to-historic-03 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 16:32:28 -0000 This looks fine to me. Pretty comprehensive. One nit, two questions. 1. I'd get rid of the note after the abstract, but leaving it there is fine. 2. Why only pick DIGEST-MD5 and not e.g PLAIN as well? (I'm not complaining, any reasonable answer I can pass on if asked will be fine I think.) 3. Do you know if there are any uses of this mechanism that'd be badly affected by obsoleting this, and where new code is likely to be written/deployed? (As for point 2 above. Just saying "not that we know" is fine here.) There's no need for loads of responses, e.g. the shepherd could just answer giving folks a chance to disagree. Thanks, S. PS: This is my 1st doc to handle as AD. Apologies in advance if I muck up the process:-) From alexey.melnikov@isode.com Thu Mar 31 09:40:43 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803013A6844 for ; Thu, 31 Mar 2011 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvNcAMW1l-D2 for ; Thu, 31 Mar 2011 09:40:42 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6A89B3A6A33 for ; Thu, 31 Mar 2011 09:40:42 -0700 (PDT) Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 31 Mar 2011 17:42:21 +0100 Message-ID: <4D94AED4.4010602@isode.com> Date: Thu, 31 Mar 2011 18:41:56 +0200 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Stephen Farrell References: <4D94ACE6.4020203@cs.tcd.ie> In-Reply-To: <4D94ACE6.4020203@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-digest-to-historic-03 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 16:40:43 -0000 Stephen Farrell wrote: >This looks fine to me. Pretty comprehensive. > >One nit, two questions. > >1. I'd get rid of the note after the abstract, but leaving >it there is fine. > > Ok. Can I do this after IETF LC? >2. Why only pick DIGEST-MD5 and not e.g PLAIN as well? >(I'm not complaining, any reasonable answer I can pass >on if asked will be fine I think.) > > Because PLAIN is actually more interoperable ;-)? >3. Do you know if there are any uses of this mechanism >that'd be badly affected by obsoleting this, and where >new code is likely to be written/deployed? (As for >point 2 above. Just saying "not that we know" is fine >here.) > > Not that I know. I think there are enough SCRAM implementations now, so I expect more SCRAM implementations than DIGEST-MD5 to be written in the future. >There's no need for loads of responses, e.g. the shepherd >could just answer giving folks a chance to disagree. > >Thanks, >S. > >PS: This is my 1st doc to handle as AD. Apologies in >advance if I muck up the process:-) > You are doing fine so far. Have no doubts: I will tell you if you do something wrong ;-). From hartmans@mit.edu Thu Mar 31 10:12:46 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04EA43A6B7C for ; Thu, 31 Mar 2011 10:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=-1.478, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, J_CHICKENPOX_53=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJzPdk1C89+B for ; Thu, 31 Mar 2011 10:12:45 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 1AF753A6B7A for ; Thu, 31 Mar 2011 10:12:44 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-45ef.meeting.ietf.org [130.129.69.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 41A56202B2; Thu, 31 Mar 2011 13:11:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 78FB04541; Thu, 31 Mar 2011 13:14:22 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <4D94ACE6.4020203@cs.tcd.ie> Date: Thu, 31 Mar 2011 13:14:22 -0400 In-Reply-To: <4D94ACE6.4020203@cs.tcd.ie> (Stephen Farrell's message of "Thu, 31 Mar 2011 17:33:42 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-digest-to-historic-03 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 17:12:46 -0000 >>>>> "Stephen" == Stephen Farrell writes: Stephen> 3. Do you know if there are any uses of this mechanism Stephen> that'd be badly affected by obsoleting this, and where new Stephen> code is likely to be written/deployed? (As for point 2 Stephen> above. Just saying "not that we know" is fine here.) Stephen> There's no need for loads of responses, e.g. the shepherd Stephen> could just answer giving folks a chance to disagree. Stephen> Thanks, S. Stephen> PS: This is my 1st doc to handle as AD. Apologies in Stephen> advance if I muck up the process:-) Stephen> _______________________________________________ Kitten Stephen> mailing list Kitten@ietf.org Stephen> https://www.ietf.org/mailman/listinfo/kitten The pattern of plain+TLS is secure under the assumption that yo,u are talking to the right server and that server is adequately trusted. This pattern is very common on the web and for similar reasons in other application protocols. (sasl plain is not used on the web, but it would be silly to get rid of this pattern from say IMAP before we do with http) Consider for example what a server can do if its password store is backed by some hash function like the unix crypt() call. In such a case, where there is no challenge/response protocol standardized with the right hash function, you're kind of stuck with plain. This happens quite commonly. Other software deployment patterns, for example redirecting password authentication through some stack such as PAM, also ends up requiring a plaintext password on the server. While these patterns are not as secure they are very common. From hartmans@mit.edu Thu Mar 31 10:19:02 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BD73A6952 for ; Thu, 31 Mar 2011 10:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.029 X-Spam-Level: X-Spam-Status: No, score=-103.029 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd-yyciUZOrP for ; Thu, 31 Mar 2011 10:18:58 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 573BE3A69FC for ; Thu, 31 Mar 2011 10:18:58 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-45ef.meeting.ietf.org [130.129.69.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 909A7202B2; Thu, 31 Mar 2011 13:17:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AD2434541; Thu, 31 Mar 2011 13:20:35 -0400 (EDT) From: Sam Hartman To: mrex@sap.com References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> Date: Thu, 31 Mar 2011 13:20:35 -0400 In-Reply-To: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> (Martin Rex's message of "Tue, 29 Mar 2011 23:16:18 +0200 (MEST)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman Subject: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 17:19:02 -0000 As an FYI, I don't think a callback for obtaining a password is a good fit for use cases I care about. There are a number of reasons. One of the big ones has to do with common application design patterns. Particularly because GSS-API blocks, it is desirable to run GSS-API in separate threads from the user interface. On several (all?) platforms, the user-interface typically runs in a single thread with an event loop. Having a callback rather than an asynchronous interface that wants UI is problematic for these environments. You *can* do it. Graphical login programs that interact with the PAM stack are forced to do so. However, it significantly complicates the application design. Instead, I'd rather know that I could have initiated communication with a particular service had passwords been supplied. From Volker.Lendecke@SerNet.DE Thu Mar 31 10:22:53 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619E83A6B7C for ; Thu, 31 Mar 2011 10:22:53 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Date" X-Spam-Flag: NO X-Spam-Score: -5.004 X-Spam-Level: X-Spam-Status: No, score=-5.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, INVALID_DATE=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l28Sr-SHJRDf for ; Thu, 31 Mar 2011 10:22:52 -0700 (PDT) Received: from mail.SerNet.de (mail.SerNet.de [193.175.80.2]) by core3.amsl.com (Postfix) with ESMTP id 50DFE3A69FC for ; Thu, 31 Mar 2011 10:22:52 -0700 (PDT) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.69 #1) id 1Q5Lbh-0003sc-1R; Thu, 31 Mar 2011 19:24:29 +0200 Received: by intern.SerNet.DE id 1Q5Lbg-00Aw2j-P1; Thu, 31 Mar 2011 19:24:28 +0200 Received: by intern.SerNet.DE id 1Q5Lbg-00Aw2R-Hi; Thu, 31 Mar 2011 19:24:28 +0200 Date: Thu, 31 Mar 2011 19:24:23 +0200 Date: Thu, 31 Mar 2011 19:24:23 +0200 From: Volker Lendecke To: Sam Hartman References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Message-Id: Organization: SerNet GmbH, Goettingen, Germany Cc: kitten@ietf.org Subject: Re: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Volker.Lendecke@SerNet.DE List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 17:22:53 -0000 On Thu, Mar 31, 2011 at 01:20:35PM -0400, Sam Hartman wrote: > As an FYI, I don't think a callback for obtaining a password is a good > fit for use cases I care about. > > There are a number of reasons. > One of the big ones has to do with common application design patterns. > Particularly because GSS-API blocks, it is desirable to run GSS-API in > separate threads from the user interface. > On several (all?) platforms, the user-interface typically runs in a > single thread with an event loop. > Having a callback rather than an asynchronous interface that wants UI is > problematic for these environments. > > You *can* do it. Graphical login programs that interact with the PAM > stack are forced to do so. > However, it significantly complicates the application design. > > Instead, I'd rather know that I could have initiated communication with > a particular service had passwords been supplied. While there -- some years ago I have had some chat with a Kerberos developer about async non-blocking GSS-API. Is there any work being done in that direction? Thanks, Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen From nico@cryptonector.com Thu Mar 31 10:36:41 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B128D3A6A48 for ; Thu, 31 Mar 2011 10:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBblFLgVWgRC for ; Thu, 31 Mar 2011 10:36:40 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id D5B203A6A33 for ; Thu, 31 Mar 2011 10:36:40 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id C552C6B0079 for ; Thu, 31 Mar 2011 10:38:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=QONpSiWbPL+/R2w/n3glz aQKza2G1UyuuP4i3z5BjLW6r5A1ZMO3+sgxcUR2uG4OmxmKOHKAL3uQiMuZI2RT6 o/nLsN70/bZDUCGklaOM372Y5SBpjf31/COVy4ZJKf2YQB878R0WXghdhWvBtfbK QmE6BjmVVUSLtDHz04oYho= 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=zP0QahSAaAs27vq9ctvS gYlNEKw=; b=FQB0cvX4wTvtIOlIe0Mb332a6ISmDjln2qlBH1LPzgwt6tOqP+Wz q0dZyDkvT/3mT2Nhqb3AR/L3ZdUipAVGCK9q9p5hFmjV8op54XOX8UNn2GBa66uk dTy52huzOcWB7E1q+tb+Ghay0mO+4TE5AdRA5HVf35QgXzvBvUPzzpU= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 989A26B0070 for ; Thu, 31 Mar 2011 10:38:20 -0700 (PDT) Received: by vws12 with SMTP id 12so2410729vws.31 for ; Thu, 31 Mar 2011 10:38:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.200 with SMTP id 8mr3983697vdg.70.1301593100006; Thu, 31 Mar 2011 10:38:20 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Thu, 31 Mar 2011 10:38:19 -0700 (PDT) In-Reply-To: References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> Date: Thu, 31 Mar 2011 12:38:19 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 17:36:41 -0000 On Thu, Mar 31, 2011 at 12:20 PM, Sam Hartman wrote: > As an FYI, I don't think a callback for obtaining a password is a good > fit for use cases I care about. > > There are a number of reasons. > One of the big ones has to do with common application design patterns. > Particularly because GSS-API blocks, it is desirable to run GSS-API in > separate threads from the user interface. > On several (all?) platforms, the user-interface typically runs in a > single thread with an event loop. > Having a callback rather than an asynchronous interface that wants UI is > problematic for these environments. > > You *can* do it. Graphical login programs that interact with the PAM > stack are forced to do so. > However, it significantly complicates the application design. Well, PAM simply can't handle async anything. Specifically it cannot cancel current prompts (well, it might be possible to cancel the thread that is running the PAM conversation function, but thread cancellation in general seems like an iffy proposition). Ideally the API would have async built-in, including async prompt cancellation. What we need to do is: a) design portable and non-portable (well, portablish, using a libevent-ABI-compatible set of function pointers for hooking into the app's event loop) async GSS API, b) add in an extension for interaction callbacks, c) add a function by which to request cancellation of outstanding operations. > Instead, I'd rather know that I could have initiated communication with > a particular service had passwords been supplied. That pattern is not really available for all mechanisms. However, we could have a mechanism attribute that indicates whether the initial gss_init_sec_context() call succeeds only if there are target-specific credentials cached (I don't have time to check, but, IIRC, we do have such an attribute). Nico -- From nico@cryptonector.com Thu Mar 31 10:49:19 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EC5D3A6AA0 for ; Thu, 31 Mar 2011 10:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-wZLB+ExTkI for ; Thu, 31 Mar 2011 10:49:18 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 62B753A6952 for ; Thu, 31 Mar 2011 10:49:18 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id AF555678071 for ; Thu, 31 Mar 2011 10:50:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=yh8yblX3W39SV0YtpAYyV v4Nt+4Sx49cMcKMtobmqXRAhjCKC8lBC9UTNbupm7u6ZtsSJsAARI8YqAYDyuZNj oZ+Asyo2wGOd9PRkR+LLAtvjO5mrPfdIK7i5Sep+u09/QFb8kUio0mLJ7rOmlzpL 246rHCi4gnBzP+9LouFMko= 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=bsBvpIInLB1R1bFidAxz uZpICU8=; b=MWB6tfHZB6Ok3jOwuWCt/uvbgGYb9wF7eC9UhjUWWMwlGq+Yhkzq hIxVtAOhbXaP8x74Ozb+2JmZCK39Y7pwHyvJFy6RBlk1/F0uWxOyYtoJ/A5CQA0B Ug0twz5pPG2XsXxpWcwiFFQTsdODaYmuFHwv2j1HhSeQQ8kpWyDNSs8= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 7236167809C for ; Thu, 31 Mar 2011 10:50:13 -0700 (PDT) Received: by vws12 with SMTP id 12so2421250vws.31 for ; Thu, 31 Mar 2011 10:50:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.200 with SMTP id 8mr4002588vdg.70.1301593812293; Thu, 31 Mar 2011 10:50:12 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Thu, 31 Mar 2011 10:50:12 -0700 (PDT) In-Reply-To: References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> Date: Thu, 31 Mar 2011 12:50:12 -0500 Message-ID: From: Nico Williams To: Volker.Lendecke@sernet.de Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 17:49:19 -0000 On Thu, Mar 31, 2011 at 12:24 PM, Volker Lendecke wrote: > While there -- some years ago I have had some chat with a > Kerberos developer about async non-blocking GSS-API. Is > there any work being done in that direction? If async krb5 APIs materialize then it wouldn't be too hard to build async GSS interfaces. Last time I talked to Love I convinced him, I think (Love, correct me if I'm misremembering please!) that we could do something like this: - add a libevent function pointer set and event base argument to the functions we want to be async Apps that use libevent can be made to use such GSS async APIs trivially. Apss that don't use libevent need to provide libevent-ABI-compatible wrappers to their event loops. I.e., let's standardize the libevent API/ABI without having to force everyone to use libevent proper. Given the widespread ports of libevent, and its popularity, this seems like the best approach to me. Nico -- From wmills@yahoo-inc.com Thu Mar 31 10:57:33 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761DD3A6A48 for ; Thu, 31 Mar 2011 10:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzIWAwDLAvVz for ; Thu, 31 Mar 2011 10:57:32 -0700 (PDT) Received: from web32303.mail.mud.yahoo.com (web32303.mail.mud.yahoo.com [68.142.207.151]) by core3.amsl.com (Postfix) with SMTP id 950F83A6952 for ; Thu, 31 Mar 2011 10:57:32 -0700 (PDT) Received: (qmail 37975 invoked by uid 60001); 31 Mar 2011 17:59:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1301594349; bh=FppshJ0KNJXVsWHOeJ0KcI8W64D6VclU+5mFv0d+9Dc=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=B2/RSsF0EF+aJPHZR4yFqaT4VOoY+mUuKFzhyswdR41St0ZctHRRDFkd/wN6yw/PwfDtmgHVr+9XgzkK9drquC1WVsN2CC3CERhwNVVJW8WFar0hLdVpknSH+pZDEPP5NZ8HHTUFzMkx6eeuq8wLPb1/UqfrEdi1d2/sgZ0RXQM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=qfntNP7Znj/CVEY14V1JGomsT5Etr69JEofZKceKLQVvlly9W0GntStSTUpUrQZm1IH0QzDhrewAcQaDEu5VLr9PzPuurIm4qxBIHSDbraF5jQfD+xq9WMff9x5T8tLxFKvfbEwMbNtimUpAMzKlhI2JOM1Lw2LpChPHPiI0/1Y=; Message-ID: <631012.11217.qm@web32303.mail.mud.yahoo.com> X-YMail-OSG: On_ZeaQVM1lgSTlal38LfzmIlPF.RLuDL0Q8IuE1ZwZ2EAw HmgwKW8Q.1zNk8UNKBcwnNF9MLdmv0np59vqcyx7zLVxGBsHrsUQrpvQZF0m 51fr0reut0XTwoC5d2GT2QXoelTYgn_.CppJjKIwihxVkHK.Gd38c6eszryd h.u0TrDVhNb9M.bT0egMHfRwzP6roPIUMC6I4UDY1sgLknBWumMYJe3pVscs LhO5dVDutuEjoZTkuzdyQlYi8iukDSPSeBqgo5aL_OQXzo.xQKQ3qopWS2y0 6usT8yddbM89FuKPh3HijEQOluY1LREqjkOvliBsYMTyBOVRa19fQnDdLcyk VmWY4dJRqzMKB_xtAt7aRkg9OEKYW2u7W0MAz_BwE70qxUQ-- Received: from [216.145.52.206] by web32303.mail.mud.yahoo.com via HTTP; Thu, 31 Mar 2011 10:59:09 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <4D94377D.5040508@oracle.com> Date: Thu, 31 Mar 2011 10:59:09 -0700 (PDT) From: "William J. Mills" To: "kitten@ietf.org" In-Reply-To: <4D94377D.5040508@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-401891442-1301594349=:11217" Subject: [kitten] Channel binding requirements. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 17:57:33 -0000 --0-401891442-1301594349=:11217 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I asked this before but I did not see an answer.=A0 Is message integrity in= the mechanism a requirement for correct support of channel binding?=A0 I b= elieve the answer to this is yes, because an intelligent MITM can simply mo= dify the channel binding payload in flight otherwise, and this would be und= etectable to the endpoints.=0A=0AI ask because I am trying to determine how= to correctly allow for CB in the OAuth mechanism.=0A=0AThanks,=0A=0A-bill= =0A --0-401891442-1301594349=:11217 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I asked this before b= ut I did not see an answer.  Is message integrity in the mechanism a r= equirement for correct support of channel binding?  I believe the answ= er to this is yes, because an intelligent MITM can simply modify the channe= l binding payload in flight otherwise, and this would be undetectable to th= e endpoints.

I ask because I am trying to determine how to correctly= allow for CB in the OAuth mechanism.

Thanks,

-bill
= --0-401891442-1301594349=:11217-- From nico@cryptonector.com Thu Mar 31 11:05:58 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A7E3A6AA0 for ; Thu, 31 Mar 2011 11:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrgOPFt-dvtY for ; Thu, 31 Mar 2011 11:05:58 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id CF1163A69FC for ; Thu, 31 Mar 2011 11:05:57 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 35BAB67406A for ; Thu, 31 Mar 2011 11:07:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=xbZLtb7t98Tje85iMLwgsYvhiyMLMPyoBzRWPYp2XFbM 1NguW1Fk6mV5rGGCFhSHIx21eQNDDj77/mzpN7Iy2ctaOOIKrHUJ0sOm6fKgMVu8 kSz7IiYm0AqoJbx8CyMUu8jm7avJGxhMAxq2b5QuXk2F14Tfh1jyC8iS0xygzag= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=A7uNTyLayVR/OzNSZBlKpOfXLdk=; b=Uxupf9MnQnc 9O24XPL15ZbXh2amB6youtPQ6RuQigzDPtKuPPXd1FhV6OZ8EEsXYLqESQNJeWur Y2aQ7hUY3iJe8EfjXO02pSBnXmPocSJ8cWI/UPKVQG8aRpfQRbVaRqHMKOrbqvib zsorQILRZuhvT++9b9ui72A92KAohpoc= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 046A9674058 for ; Thu, 31 Mar 2011 11:07:36 -0700 (PDT) Received: by vws12 with SMTP id 12so2437713vws.31 for ; Thu, 31 Mar 2011 11:07:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.74.106 with SMTP id s10mr3971425vdv.150.1301594856402; Thu, 31 Mar 2011 11:07:36 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Thu, 31 Mar 2011 11:07:36 -0700 (PDT) In-Reply-To: <631012.11217.qm@web32303.mail.mud.yahoo.com> References: <4D94377D.5040508@oracle.com> <631012.11217.qm@web32303.mail.mud.yahoo.com> Date: Thu, 31 Mar 2011 13:07:36 -0500 Message-ID: From: Nico Williams To: "William J. Mills" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] Channel binding requirements. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 18:05:59 -0000 On Thu, Mar 31, 2011 at 12:59 PM, William J. Mills w= rote: > I asked this before but I did not see an answer.=C2=A0 Is message integri= ty in > the mechanism a requirement for correct support of channel binding?=C2=A0= I > believe the answer to this is yes, because an intelligent MITM can simply > modify the channel binding payload in flight otherwise, and this would be > undetectable to the endpoints. > > I ask because I am trying to determine how to correctly allow for CB in t= he > OAuth mechanism. You need something akin to integrity protection. If you have integrity protection, that will do. If you have any sort of key exchange then you can either add integrity protection OR mix the CB into the key derivation for the key exchange. OTOH, if you have no key exchange whatsoever, and no keying material of any sort (e.g., as we do in SCRAM, where we derive a key from a password, salt and iteration count), then you may not be able to do CB (I'm thinking though that if you have trusted third parties that can validate CB for you, then you can; presumably you'd be using TLS to authenticate the trusted third party). Nico -- From wmills@yahoo-inc.com Thu Mar 31 11:14:31 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155A628C0DD for ; Thu, 31 Mar 2011 11:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9umhByFaMlso for ; Thu, 31 Mar 2011 11:14:30 -0700 (PDT) Received: from web32303.mail.mud.yahoo.com (web32303.mail.mud.yahoo.com [68.142.207.151]) by core3.amsl.com (Postfix) with SMTP id 09C6B3A6B6A for ; Thu, 31 Mar 2011 11:14:29 -0700 (PDT) Received: (qmail 44827 invoked by uid 60001); 31 Mar 2011 18:16:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1301595365; bh=nQI5EozfLhdlKpWdj7xSU6MQmP4E0vKjiGR8DVydzz0=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=drLRLUcCB8DhW30mtM/X+1biTIS+0lancURkOsM0g6ORVSNCQtZmhjHqojev+i/QaXnj+Y3p+JuGm6TbenSsb3BKHESXuIf96Voi67Acg/Cn9Ld3UIvjzwyUO48WuCs9G4ZEaeZMgwf+Gux2FHXsyc7+jIeMrn81iFJNn8k/psY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qKDoB8CdJhoaxDeVhyDADC1brDSJRuJDqKYaUyxskICJSqBAPSm8UIWz4RMchTXYLx2ovbzOjTKP2p9mQFnb0RkK+ZEZlVEqkQiKJxr0CSC7nqLm+XsZHduRQoJzG+PlwNKXkYtL9lFpZYQ9Q19mYMzBNwm9L40WZzabJgZ2qcc=; Message-ID: <849940.11217.qm@web32303.mail.mud.yahoo.com> X-YMail-OSG: bB9hpkQVM1mhQggnONwHo8g2kXWwFt5Uvg_0z8liKCqc.s_ z_3tvyuXWLtEmBwnUGYXOt4KBJt6vvyI_x_NwvRgmwFsT1XVFhKot9vYurU4 It1KWD7s133KhThfNKSBdNxlHFIOnrvPimSymPUtwHzJunBQkzfrQ.v3f3qI 7vj2otPPv_Er6ahJ.YTgSGqs7QcJguhgKKA5xcAd6h0ksE59_Ruo0GfVcHcH PiIIRA5c.7v9Ruhc0dNpE6wacx0k3555UR0NgTwITfvoITb1z26teDY26lDx h1iRNEKt4HVqVxRTzHxE4k4eWh2U46kOzyLgXrHBim5.4HltsGQbAbE9EBDd Eg2hy8AvR8FbaMdDt4fX3fN.axcPi0D9T Received: from [216.145.52.206] by web32303.mail.mud.yahoo.com via HTTP; Thu, 31 Mar 2011 11:16:05 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <4D94377D.5040508@oracle.com> <631012.11217.qm@web32303.mail.mud.yahoo.com> Date: Thu, 31 Mar 2011 11:16:05 -0700 (PDT) From: "William J. Mills" To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1381498973-1301595365=:11217" Cc: "kitten@ietf.org" Subject: Re: [kitten] Channel binding requirements. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 18:14:31 -0000 --0-1381498973-1301595365=:11217 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OK, this makes sense.=A0 Some of the OAuth profiles within this mechanism h= ave a shared secret and sign the messages.=A0 In those cases we can perform= correct channel binding.=A0 I'll put that language into the mechanism draf= t spec.=A0 Thank you.=0A=0A-bill=0A=0A=0A=0A_______________________________= _=0AFrom: Nico Williams =0ATo: William J. Mills =0ACc: "kitten@ietf.org" =0ASent: Thursd= ay, March 31, 2011 11:07 AM=0ASubject: Re: [kitten] Channel binding require= ments.=0A=0AOn Thu, Mar 31, 2011 at 12:59 PM, William J. Mills wrote:=0A> I asked this before but I did not see an answer.=A0 I= s message integrity in=0A> the mechanism a requirement for correct support = of channel binding?=A0 I=0A> believe the answer to this is yes, because an = intelligent MITM can simply=0A> modify the channel binding payload in fligh= t otherwise, and this would be=0A> undetectable to the endpoints.=0A>=0A> I= ask because I am trying to determine how to correctly allow for CB in the= =0A> OAuth mechanism.=0A=0AYou need something akin to integrity protection.= =A0 If you have=0Aintegrity protection, that will do.=A0 If you have any so= rt of key=0Aexchange then you can either add integrity protection OR mix th= e CB=0Ainto the key derivation for the key exchange.=0A=0AOTOH, if you have= no key exchange whatsoever, and no keying material=0Aof any sort (e.g., as= we do in SCRAM, where we derive a key from a=0Apassword, salt and iteratio= n count), then you may not be able to do CB=0A(I'm thinking though that if = you have trusted third parties that can=0Avalidate CB for you, then you can= ; presumably you'd be using TLS to=0Aauthenticate the trusted third party).= =0A=0ANico=0A-- --0-1381498973-1301595365=:11217 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OK, this m= akes sense.  Some of the OAuth profiles within this mechanism have a s= hared secret and sign the messages.  In those cases we can perform cor= rect channel binding.  I'll put that language into the mechanism draft= spec.  Thank you.

= -bill

From: Nico Williams <nico@cryptonector.com>
To: William J. Mills <wmills@yahoo-inc.co= m>
Cc: "kitten@ietf.= org" <kitten@ietf.org>
Sent: Thursday, March 31, 2011 11:07 AM
Subject: Re: [kitten] Channel binding requirements.
<= /font>
=0AOn Thu, Mar 31, 2011 at 12:59 PM, William J. Mills <wm= ills@yahoo-inc.com> wrote:
> I asked this before but I did not= see an answer.  Is message integrity in
> the mechanism a requi= rement for correct support of channel binding?  I
> believe the = answer to this is yes, because an intelligent MITM can simply
> modif= y the channel binding payload in flight otherwise, and this would be
>= ; undetectable to the endpoints.
>
> I ask because I am trying = to determine how to correctly allow for CB in the
> OAuth mechanism.<= br>
You need something akin to integrity protection.  If you haveintegrity protection, that will do.  If you have any sort of key
= exchange then you can either add integrity protection OR mix the CB
into= the key derivation for the key exchange.

OTOH, if you have no key e= xchange whatsoever, and no keying material
of any sort (e.g., as we do in SCRAM= , where we derive a key from a
password, salt and iteration count), then= you may not be able to do CB
(I'm thinking though that if you have trus= ted third parties that can
validate CB for you, then you can; presumably= you'd be using TLS to
authenticate the trusted third party).

Nic= o
--


--0-1381498973-1301595365=:11217-- From lha@kth.se Thu Mar 31 11:15:30 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3EAF3A6B85 for ; Thu, 31 Mar 2011 11:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.38 X-Spam-Level: X-Spam-Status: No, score=-5.38 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFqvfOBpDn4k for ; Thu, 31 Mar 2011 11:15:30 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id AEFE53A69C2 for ; Thu, 31 Mar 2011 11:15:29 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 451AE156B36; Thu, 31 Mar 2011 20:16:38 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id QyQihiap3TqZ; Thu, 31 Mar 2011 20:16:36 +0200 (CEST) Received: from EXHUB1.ug.kth.se (exhub1.ug.kth.se [130.237.32.134]) by smtp-1.sys.kth.se (Postfix) with ESMTP id CFFC5156B2D; Thu, 31 Mar 2011 20:16:31 +0200 (CEST) Received: from EXDB1.ug.kth.se ([169.254.1.145]) by EXHUB1.ug.kth.se ([130.237.32.134]) with mapi id 14.01.0255.000; Thu, 31 Mar 2011 20:16:04 +0200 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= To: Sam Hartman Thread-Topic: [kitten] Callback for Password not so good Thread-Index: AQHL78f6DaOWjsC9sEaro3HoSov1FJRHnkgA Date: Thu, 31 Mar 2011 18:16:01 +0000 Message-ID: <4F8A1EBB-7C3C-4B94-BC2A-B9981DB68A61@kth.se> References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [99.52.202.108] Content-Type: multipart/signed; boundary="Apple-Mail-19--981869981"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 18:15:30 -0000 --Apple-Mail-19--981869981 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree with this, a callback will simply not work for the use cases = what I care about. This is esp true for GUI apps. Love 31 mar 2011 kl. 10.20 skrev Sam Hartman: > As an FYI, I don't think a callback for obtaining a password is a good > fit for use cases I care about. >=20 > There are a number of reasons. > One of the big ones has to do with common application design patterns. > Particularly because GSS-API blocks, it is desirable to run GSS-API in > separate threads from the user interface. > On several (all?) platforms, the user-interface typically runs in a > single thread with an event loop. > Having a callback rather than an asynchronous interface that wants UI = is > problematic for these environments. >=20 > You *can* do it. GrapAl > hical login programs that interact with the PAM > stack are forced to do so. > However, it significantly complicates the application design. >=20 > Instead, I'd rather know that I could have initiated communication = with > a particular service had passwords been supplied. > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --Apple-Mail-19--981869981 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQXzoqZKwXOvvxymIt KZOH2DANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDQwMTAwMDAwMFoXDTExMDQwMTIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxHzAdBgNVBAMUFkxvdmUgSPZy bnF1aXN0IMVzdHJhbmQxGTAXBgkqhkiG9w0BCQEWCmxoYUBrdGguc2UwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDExzsEl8kHec1Flo6WDOR55uZ9e526lJpegh+pnb7kUoiMc3+L+oTM HbAQs4hOjUV1+kwPsdnBFolLJ6CR5lkwyZBHjzdbHMXnxh2czeIDjaD1lWxnEPTPefGZ0LEUgbix pThFfdW6wA9z43J/1VsZeQU8ZEY50ZHSkhjM+1PFdgjL5RJv2j7sFgHVr7P2mvEFNTy+PCKW/1Gj agjSehjXvFCqs8O9Was/dEdQ8pyT216VBPi+S77qcbGYAH6yqQ0XqiF0ogBZE8jKnkUDhFZz60gC QqlClW6i7iczbalEjnvEx3z+tsUzIK2UGrwqv0BmCg0qz7T1RZgbTowy0D/BAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAF01Bxe7vzqE /pJ4hZ30dqxJDSjHVOSmKdAkHg/i0uKLbIs7C+RYDlOptqlrmXwE40cTjFk26XVimzYayfHev/mA lgqxPlQC28zhQTHi1VtwVUXwslphpGRJk/WK8esXu61gGgjEErcGtNB7G4KfymM3yQgIudUM4cZb Z+5Et5fzLd9WLHIqd5vb2IbC4Q/dg00lmIWmikQtjt9mi1EaUUIAiySzjI5e6Akq8uyeOw+7ccPg WZOPPfif8D0z0WDXpSwCyTo9SG/f1gvwPkuxfJ4pilIBVBPkS2zAb7a5ZM1xXdLIjbboFCLCzJhk VsK40ZdKTdMvp9t/M1O1D/b7U+MxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fYMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMzMTE4 MTYwMVowIwYJKoZIhvcNAQkEMRYEFOWXhzoMw3qkJhgMoMduuAP9M1/NMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEF86KmSsFzr78cpiLSmTh9gwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fY MA0GCSqGSIb3DQEBAQUABIIBALVAbLc2PYsZKT9txXFbQUYfJ1xrfNjv3mwlnnD+lqUFcV3Fivpg n8gICGkBuObDa6OXa6oEAMugtvCrhF8y8S+KAAsDOMDlljNGVEzj5EK3I5NZbM/sXOGqTnwm46lV 84pSQUcPz07PRULgg/Ml14SDae6J2vpXEbljLFn9Rz2vtI9lCzqZm+P+KTlc0aJruIPXASlqmzoi lxjjPKe0OPPK8MaB3CzQMrNzsQJe24rDJ5dqBBDsiIxl9p4A8N25kNqg69N0+V5G1ZNR95MjjcL/ /tx/b2yC0UMqe/Hsae3pITW4cqNvir2kdQobp40yRKD0bue4Krjx3LuWOXzBkW0AAAAAAAA= --Apple-Mail-19--981869981-- From lha@kth.se Thu Mar 31 11:18:18 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E97F28C0ED for ; Thu, 31 Mar 2011 11:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.664 X-Spam-Level: X-Spam-Status: No, score=-5.664 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmdopZ1Z5+MH for ; Thu, 31 Mar 2011 11:18:17 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 614E13A6B8C for ; Thu, 31 Mar 2011 11:18:17 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id AC9AC156B2D; Thu, 31 Mar 2011 20:19:26 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id CVXOFQ8KPfpm; Thu, 31 Mar 2011 20:19:25 +0200 (CEST) Received: from EXHUB2.ug.kth.se (exhub2.ug.kth.se [130.237.32.137]) by smtp-1.sys.kth.se (Postfix) with ESMTP id B0AEE156B36; Thu, 31 Mar 2011 20:19:18 +0200 (CEST) Received: from EXDB1.ug.kth.se ([169.254.1.145]) by EXHUB2.ug.kth.se ([130.237.32.137]) with mapi id 14.01.0255.000; Thu, 31 Mar 2011 20:19:02 +0200 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= To: Nico Williams Thread-Topic: [kitten] Callback for Password not so good Thread-Index: AQHL78f6DaOWjsC9sEaro3HoSov1FJRHj92AgAAHNgCAAAgKAA== Date: Thu, 31 Mar 2011 18:19:01 +0000 Message-ID: <6E55A187-4E26-4B85-92D1-D070D6324EBB@kth.se> References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [99.52.202.108] Content-Type: multipart/signed; boundary="Apple-Mail-20--981691926"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" , "" , Sam Hartman Subject: Re: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 18:18:18 -0000 --Apple-Mail-20--981691926 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 31 mar 2011 kl. 10.50 skrev Nico Williams: > Last time I talked to Love I convinced him, I think (Love, correct me > if I'm misremembering please!) that we could do something like this: Standardizing on libevent is a non starter for me. Love --Apple-Mail-20--981691926 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQXzoqZKwXOvvxymIt KZOH2DANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDQwMTAwMDAwMFoXDTExMDQwMTIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxHzAdBgNVBAMUFkxvdmUgSPZy bnF1aXN0IMVzdHJhbmQxGTAXBgkqhkiG9w0BCQEWCmxoYUBrdGguc2UwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDExzsEl8kHec1Flo6WDOR55uZ9e526lJpegh+pnb7kUoiMc3+L+oTM HbAQs4hOjUV1+kwPsdnBFolLJ6CR5lkwyZBHjzdbHMXnxh2czeIDjaD1lWxnEPTPefGZ0LEUgbix pThFfdW6wA9z43J/1VsZeQU8ZEY50ZHSkhjM+1PFdgjL5RJv2j7sFgHVr7P2mvEFNTy+PCKW/1Gj agjSehjXvFCqs8O9Was/dEdQ8pyT216VBPi+S77qcbGYAH6yqQ0XqiF0ogBZE8jKnkUDhFZz60gC QqlClW6i7iczbalEjnvEx3z+tsUzIK2UGrwqv0BmCg0qz7T1RZgbTowy0D/BAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAF01Bxe7vzqE /pJ4hZ30dqxJDSjHVOSmKdAkHg/i0uKLbIs7C+RYDlOptqlrmXwE40cTjFk26XVimzYayfHev/mA lgqxPlQC28zhQTHi1VtwVUXwslphpGRJk/WK8esXu61gGgjEErcGtNB7G4KfymM3yQgIudUM4cZb Z+5Et5fzLd9WLHIqd5vb2IbC4Q/dg00lmIWmikQtjt9mi1EaUUIAiySzjI5e6Akq8uyeOw+7ccPg WZOPPfif8D0z0WDXpSwCyTo9SG/f1gvwPkuxfJ4pilIBVBPkS2zAb7a5ZM1xXdLIjbboFCLCzJhk VsK40ZdKTdMvp9t/M1O1D/b7U+MxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fYMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMzMTE4 MTg1OVowIwYJKoZIhvcNAQkEMRYEFB3207eJ06tmBw1zxYEfbKjfUqtKMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEF86KmSsFzr78cpiLSmTh9gwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fY MA0GCSqGSIb3DQEBAQUABIIBABe+SrUf4ZiJf1qTZYLY+3Od3rKcm7wqLYQ6xcANGbz6lp4JCHO/ Wf2YFFOhXA8k2Vyo/222HEvqYiTJXtS20w4FXc+Ev8P6MGh1MaRxVjPaTnyxB3puVnLxPyKFCYI/ 136exH5KvcrFLnD9S1o/fbGuVea81L4pgMzsrN1Kwz225tVZReIYAwjmzZs/1cF5pvanOzEyITXR IHcNVvO08UbzlUGWQK/AbxkvrMS2qM4VshauLsp+vXHct7+H5WXLbXOAdVRl6WCifU8TnJuWwuWE vuPcJKaqZEJ5VLVBFIf8Z3CV+t/ZBqUGjGTZQ+EhwqkrVzurkvYeUBp4/CR2+a0AAAAAAAA= --Apple-Mail-20--981691926-- From Volker.Lendecke@SerNet.DE Thu Mar 31 12:40:24 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FBBF28C0FC for ; Thu, 31 Mar 2011 12:40:24 -0700 (PDT) X-Quarantine-ID: <6zqOa4UZk1Jk> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Date" X-Spam-Flag: NO X-Spam-Score: -4.854 X-Spam-Level: X-Spam-Status: No, score=-4.854 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, INVALID_DATE=1.245, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zqOa4UZk1Jk for ; Thu, 31 Mar 2011 12:40:21 -0700 (PDT) Received: from mail.SerNet.de (mail1.SerNet.de [193.175.80.2]) by core3.amsl.com (Postfix) with ESMTP id 8C2DC28C0E1 for ; Thu, 31 Mar 2011 12:40:21 -0700 (PDT) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.69 #1) id 1Q5Nkj-0000tU-2D; Thu, 31 Mar 2011 21:41:57 +0200 Received: by intern.SerNet.DE id 1Q5Nki-00B2Kw-Q1; Thu, 31 Mar 2011 21:41:56 +0200 Received: by intern.SerNet.DE id 1Q5Nki-00B2Ke-H2; Thu, 31 Mar 2011 21:41:56 +0200 Date: Thu, 31 Mar 2011 21:39:59 +0200 Date: Thu, 31 Mar 2011 21:39:59 +0200 From: Volker Lendecke To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> <6E55A187-4E26-4B85-92D1-D070D6324EBB@kth.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6E55A187-4E26-4B85-92D1-D070D6324EBB@kth.se> User-Agent: Mutt/1.5.20 (2009-06-14) Message-Id: Organization: SerNet GmbH, Goettingen, Germany Cc: "" , Sam Hartman Subject: Re: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Volker.Lendecke@SerNet.DE List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 19:40:24 -0000 On Thu, Mar 31, 2011 at 06:19:01PM +0000, Love Hörnquist Åstrand wrote: > > 31 mar 2011 kl. 10.50 skrev Nico Williams: > > > Last time I talked to Love I convinced him, I think (Love, correct me > > if I'm misremembering please!) that we could do something like this: > > Standardizing on libevent is a non starter for me. The Avahi API might be worth a look: http://avahi.org/download/doxygen/struct_avahi_poll.html It might need extensions, but for pure socket and timeout operations something like that looks like a good start. It was pretty easy to integrate this int Samba's event loop. I could imagine that other event loops are similar in this respect. Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen From nico@cryptonector.com Thu Mar 31 13:34:26 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC2923A6BA1 for ; Thu, 31 Mar 2011 13:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSq-EcCnE15f for ; Thu, 31 Mar 2011 13:34:26 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 0AC423A6AA4 for ; Thu, 31 Mar 2011 13:34:26 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id E294921DE58 for ; Thu, 31 Mar 2011 13:36:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=dLWOjehyz8xgCNC/Nt8aY eeICG02B+bxFNhhwluPmW1OALI091eEr5aNhaSFBAOla0l92amURyOD5p9aB3D7k 7UHorC3m+sTRuXi2IiyIxs+WtoxHCU39ZNKMwVS8TFc3MlYsd827R5is21wuZJfN CH9n7DZqEA5rlV3HLarKM8= 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=PEpPsjFERIZEJrCPLjp7 FW1dVL4=; b=miwUl7+u43ssXiS3dcFS1eo4e7O490aYnhDEAjSgwvDvfqN5NME6 edtcRChMl0tANsdFEEfQrfXtMlIEhJ2z1fuGUdYIza3mLLaLfbkjkv2c/ah6biCe F8MeYYJFV+TWw5ktGvGqUrycsNsEK3sR3OmVyMVD3Ijbvd21upHo6CY= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id ACE5121DE14 for ; Thu, 31 Mar 2011 13:36:05 -0700 (PDT) Received: by vxg33 with SMTP id 33so2586671vxg.31 for ; Thu, 31 Mar 2011 13:36:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.18 with SMTP id bk18mr4181802vdb.270.1301603764909; Thu, 31 Mar 2011 13:36:04 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Thu, 31 Mar 2011 13:36:04 -0700 (PDT) In-Reply-To: References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> <6E55A187-4E26-4B85-92D1-D070D6324EBB@kth.se> Date: Thu, 31 Mar 2011 15:36:04 -0500 Message-ID: From: Nico Williams To: Volker.Lendecke@sernet.de Content-Type: text/plain; charset=UTF-8 Cc: "" , Sam Hartman Subject: Re: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 20:34:26 -0000 Also, note that I was a fan of a callback-only API as the standard, and then Love told me that'd be a non-starter for Samba folks, yet it's also what Love prefers. So then let me try one more proposal: - A standard set of new GSS functions that simply take a completion callback function and data pointers, with all output parameters passed to the callback. - An optional to implement set of new GSS functions that take an event loop as an argument, where the event loop consists of a vector of libevent-like functions (same prototypes, semantics) and a data pointer that corresponds to a libevent event base. - Maybe N more optional to implement variants using different event loop APIs. I think this is pretty much what my last offer had been when we last talked about this. This should be relatively simple to implement and use, assuming underlying Kerberos (and other) async APIs. Nico -- From lukeh@padl.com Thu Mar 31 15:24:20 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CAFE3A6AC7 for ; Thu, 31 Mar 2011 15:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cwAo9bQ4eIb for ; Thu, 31 Mar 2011 15:24:19 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 3FCC93A698F for ; Thu, 31 Mar 2011 15:24:19 -0700 (PDT) Received: by us.padl.com with ESMTP id p2VMPoCl024311; Thu, 31 Mar 2011 18:25:55 -0400 References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8G4) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <7A7EACC4-EA42-4CAE-8F5C-3B565D50E503@padl.com> X-Mailer: iPhone Mail (8G4) From: Luke Howard Date: Fri, 1 Apr 2011 09:25:44 +1100 To: Nico Williams X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.9 Cc: "kitten@ietf.org" , "Volker.Lendecke@sernet.de" , Sam Hartman Subject: Re: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 22:24:20 -0000 Async krb5 apis shipped in MIT 1.9. I think they exist in Heimdal for the AS. Von meinem iPhone gesendet Am 01/04/2011 um 4:50 schrieb Nico Williams : > On Thu, Mar 31, 2011 at 12:24 PM, Volker Lendecke > wrote: >> While there -- some years ago I have had some chat with a >> Kerberos developer about async non-blocking GSS-API. Is >> there any work being done in that direction? > > If async krb5 APIs materialize then it wouldn't be too hard to build > async GSS interfaces. > > Last time I talked to Love I convinced him, I think (Love, correct me > if I'm misremembering please!) that we could do something like this: > > - add a libevent function pointer set and event base argument to the > functions we want to be async > > Apps that use libevent can be made to use such GSS async APIs trivially. > > Apss that don't use libevent need to provide libevent-ABI-compatible > wrappers to their event loops. > > I.e., let's standardize the libevent API/ABI without having to force > everyone to use libevent proper. > > Given the widespread ports of libevent, and its popularity, this seems > like the best approach to me. > > Nico > -- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From jhutz@cmu.edu Thu Mar 31 15:31:15 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 488E13A6BC0 for ; Thu, 31 Mar 2011 15:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2iXPgs0wIJA for ; Thu, 31 Mar 2011 15:31:14 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 8D82B3A67F4 for ; Thu, 31 Mar 2011 15:31:14 -0700 (PDT) Received: from [130.129.69.105] (dhcp-4569.meeting.ietf.org [130.129.69.105]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p2VMWpY8028302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Mar 2011 18:32:52 -0400 (EDT) From: Jeffrey Hutzelman To: "William J. Mills" In-Reply-To: <11220_1301594356_p2VHxFPN028287_631012.11217.qm@web32303.mail.mud.yahoo.com> References: <4D94377D.5040508@oracle.com> <11220_1301594356_p2VHxFPN028287_631012.11217.qm@web32303.mail.mud.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 01 Apr 2011 00:32:51 +0200 Message-ID: <1301610771.2583.81.camel@destiny> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: "kitten@ietf.org" , jhutz@cmu.edu Subject: Re: [kitten] Channel binding requirements. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 22:31:15 -0000 On Thu, 2011-03-31 at 10:59 -0700, William J. Mills wrote: > I asked this before but I did not see an answer. Is message integrity > in the mechanism a requirement for correct support of channel binding? > I believe the answer to this is yes, because an intelligent MITM can > simply modify the channel binding payload in flight otherwise, and > this would be undetectable to the endpoints. You need some means of providing integrity protection for channel bindings. This does not mean you need to provide the GSSAPI message integrity service or a SASL security layer, both of which require you to be able to integrity-protect traffic carried afgter context establishment is complete. So, for example, a public-key-signature mechanism which includes channel bindings in the data it signs during context establishment would provide channel bindings, but not necessarily the message integrity service. It is most desirable to provide channel bindings, PRF, message integrity, and message confidentiality; various existing GSS-API applications depend on each of these. However, given any of the first three (or a shared, session-specific secret), we can show you how to derive the rest (however, if the thing you start with is not PRF or a key, then the derivation will likely involve a key exchange protocol like DH, which can be expensive). -- Jeff From tlyu@mit.edu Thu Mar 31 17:27:40 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13053A69C9 for ; Thu, 31 Mar 2011 17:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.76 X-Spam-Level: X-Spam-Status: No, score=-102.76 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUTMiTSMZ-b2 for ; Thu, 31 Mar 2011 17:27:40 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by core3.amsl.com (Postfix) with ESMTP id 1949F3A6AD8 for ; Thu, 31 Mar 2011 17:27:39 -0700 (PDT) X-AuditID: 1209190c-b7b7aae0000047c7-f6-4d951c64ac46 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id B9.A3.18375.46C159D4; Thu, 31 Mar 2011 20:29:24 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p310TIe5024616; Thu, 31 Mar 2011 20:29:18 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p310TGE9025149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Mar 2011 20:29:17 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id p310TGiO024236; Thu, 31 Mar 2011 20:29:16 -0400 (EDT) To: Love =?utf-8?Q?H=C3=B6rnquist_=C3=85strand?= References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> <6E55A187-4E26-4B85-92D1-D070D6324EBB@kth.se> From: Tom Yu Date: Thu, 31 Mar 2011 20:29:15 -0400 In-Reply-To: <6E55A187-4E26-4B85-92D1-D070D6324EBB@kth.se> (Love =?utf-8?Q?H=C3=B6rnquist_=C3=85strand's?= message of "Thu, 31 Mar 2011 18:19:01 +0000") Message-ID: Lines: 11 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsUixG6nrpsiM9XX4PwRSYuvbQ/YLI5uXsVi ceGsqsWpa0fYLFZ+vs7iwOrx8tQ5Ro8lS34yeXS/3sjo8W32ExaPlVNPswewRnHZpKTmZJal FunbJXBlHL/2hq1gG3PFqxl72BoYHzJ1MXJySAiYSPx4up4NwhaTuHAPxObiEBLYxyhx6P4Z VghnA6PEy8XLWSCcK0wSW5ovQDldjBJvX91iBekXEbCV+NPaAtbPLHCaUWLau98sIAlhAXOJ BS/fMEF0vGeUmLlqHlAVBwebgLTE0cVlIDUsAqoSbSfmg9VwCsxhlLj27jrYVF4BC4kJhx8y gtTzCHBKnJhSCREWlDg58wnYfGYBdYk/8y4xQ9jaEssWvmaewCg0C0nZLCRls5CULWBkXsUo m5JbpZubmJlTnJqsW5ycmJeXWqRrqJebWaKXmlK6iREUGZySPDsY3xxUOsQowMGoxMP7edoU XyHWxLLiytxDjJIcTEqivJ+kpvoK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuGdPBuonDclsbIq tSgfJiXNwaIkzjtDUt1XSCA9sSQ1OzW1ILUIJivDwaEkwftcGmioYFFqempFWmZOCUKaiYMT ZDgP0PB/IIt5iwsSc4sz0yHypxgVpcR5WYCpR0gAJJFRmgfXC0tcrxjFgV4R5n0DsoIHmPTg ul8BDWYCGiyuCnJ1cUkiQkqqgdFt8bQZrcsupYmlastN/7lrlruRXdSB14cmH58ULbUjzkqP WWpv5/vdV8ssV11IE1Q+f+x0y+q1eR+6+yzNGoO0PaMCtUKNVlV9uR3Gv+gCm2K2WszsMhvB E2InpHS7Pm1mnjNZsyBYre/Jo88ts0vCpia2lwQvSeT7cC5amtd1t/f2E7t2XFRiKc5INNRi LipOBAAsZ4peNwMAAA== Cc: "" , "" , Sam Hartman Subject: Re: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 00:27:40 -0000 Love H=C3=B6rnquist =C3=85strand writes: > 31 mar 2011 kl. 10.50 skrev Nico Williams: > >> Last time I talked to Love I convinced him, I think (Love, correct me >> if I'm misremembering please!) that we could do something like this: > > Standardizing on libevent is a non starter for me. So you want a non-callback approach that doesn't require libevent? Would you please elaborate on what your constraints are? From wmills@yahoo-inc.com Thu Mar 31 21:17:28 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1DFE3A6BDE for ; Thu, 31 Mar 2011 21:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBHjSGzBi21d for ; Thu, 31 Mar 2011 21:17:28 -0700 (PDT) Received: from web32310.mail.mud.yahoo.com (web32310.mail.mud.yahoo.com [68.142.207.158]) by core3.amsl.com (Postfix) with SMTP id E250C3A69D0 for ; Thu, 31 Mar 2011 21:17:27 -0700 (PDT) Received: (qmail 75176 invoked by uid 60001); 1 Apr 2011 04:19:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1301631545; bh=oqdozw9k8pvbscmjuX8IBReFBFlaT1DqAtir9zlt5WE=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GAwH8ZAaI9OwoLkfdG/YFZVO1xh4mYqq90awBgOpZ1+PCUnXCuFv7l8tkMouXlQB1JGSPNW05o+oKPfSs7ftMol/wydcCdTTGZgHqcXnQKt9YcT637BsxYtFDXdGWgOXhFI9DDvSGM6TvvLkSS64RZCnS0PbCAvyauYTIIIAJr8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jJIL5sLXwqZ20GcihvnOZujrIkLtAEr2B8k99OBpNjJROMOpFpEXTyUhK2nEnuKqejwi6xEbsKGDB3yETVWDU7qtr6adnrzRJWswjyNfAdeT8dkMP9B+uIddsSCCkcXYiDrlu9UOCEn2T283imre7bAltTfOEq2GjGwloin3fiQ=; Message-ID: <129745.75106.qm@web32310.mail.mud.yahoo.com> X-YMail-OSG: JxSLPNAVM1kdczDqX21ZTuknypZWnFztISkNZUfJFp3XFQC gmMgxUB9OA1b_GKi1ANcc1xPES1vwTY5HugStBkgq1KZVP68ZkliOy8WXPBl W_ZbcS6sIb2JPUxgH9vsDZWNI1V4ZQiZyAtHfa9ADqSyMQQp5RCk.uXz6vH_ OU9LTB137XcAgrlk4qEnGHyarNofnb.bxaC1qrelr.z6ZenMJxHeYdyOci5M PHNE2LFhFThfz_b7yyFFouq2RAHMpMASx2HJftEVmuV.hQ2JAxzVifGqCMjx VPQqGhbTgZDBIQRlIe1A5i0usUMmRCMsZNvXN6b1Jum4ZZ.em3.KwNma6wY. hHU2kBY9anRdYXEc5Y3M- Received: from [99.31.212.42] by web32310.mail.mud.yahoo.com via HTTP; Thu, 31 Mar 2011 21:19:05 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <4D94377D.5040508@oracle.com> <11220_1301594356_p2VHxFPN028287_631012.11217.qm@web32303.mail.mud.yahoo.com> <1301610771.2583.81.camel@destiny> Date: Thu, 31 Mar 2011 21:19:05 -0700 (PDT) From: "William J. Mills" To: Jeffrey Hutzelman In-Reply-To: <1301610771.2583.81.camel@destiny> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2113692669-1301631545=:75106" Cc: "kitten@ietf.org" Subject: Re: [kitten] Channel binding requirements. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 04:17:29 -0000 --0-2113692669-1301631545=:75106 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable In some cases I'll have a shared secret, but not in all cases.=0A=0A=0A=0A_= _______________________________=0AFrom: Jeffrey Hutzelman = =0ATo: William J. Mills =0ACc: jhutz@cmu.edu; "kitten= @ietf.org" =0ASent: Thursday, March 31, 2011 3:32 PM=0ASub= ject: Re: [kitten] Channel binding requirements.=0A=0AOn Thu, 2011-03-31 at= 10:59 -0700, William J. Mills wrote:=0A> I asked this before but I did not= see an answer.=A0 Is message integrity=0A> in the mechanism a requirement = for correct support of channel binding?=0A> I believe the answer to this is= yes, because an intelligent MITM can=0A> simply modify the channel binding= payload in flight otherwise, and=0A> this would be undetectable to the end= points.=0A=0AYou need some means of providing integrity protection for chan= nel=0Abindings.=A0 This does not mean you need to provide the GSSAPI messag= e=0Aintegrity service or a SASL security layer, both of which require you t= o=0Abe able to integrity-protect traffic carried afgter context=0Aestablish= ment is complete.=A0 So, for example, a public-key-signature=0Amechanism wh= ich includes channel bindings in the data it signs during=0Acontext establi= shment would provide channel bindings, but not=0Anecessarily the message in= tegrity service.=0A=0AIt is most desirable to provide channel bindings, PRF= , message=0Aintegrity, and message confidentiality; various existing GSS-AP= I=0Aapplications depend on each of these.=A0 However, given any of the firs= t=0Athree (or a shared, session-specific secret), we can show you how to=0A= derive the rest (however, if the thing you start with is not PRF or a=0Akey= , then the derivation will likely involve a key exchange protocol=0Alike DH= , which can be expensive).=0A=0A-- Jeff --0-2113692669-1301631545=:75106 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
In some ca= ses I'll have a shared secret, but not in all cases.
<= br>
From: Jeffrey Hutzelman = <jhutz@cmu.edu>
To: William J. Mills <wmills@yahoo-inc.com>
Cc: jhutz@cmu.edu; "kitten@ietf.org" <kitten@i= etf.org>
Sent: Thurs= day, March 31, 2011 3:32 PM
Subjec= t: Re: [kitten] Channel binding requirements.

=0AO= n Thu, 2011-03-31 at 10:59 -0700, William J. Mills wrote:
> I asked t= his before but I did not see an answer.  Is message integrity
> = in the mechanism a requirement for correct support of channel binding?
&= gt; I believe the answer to this is yes, because an intelligent MITM can> simply modify the channel binding payload in flight otherwise, and> this would be undetectable to the endpoints.

You need some mea= ns of providing integrity protection for channel
bindings.  This do= es not mean you need to provide the GSSAPI message
integrity service or = a SASL security layer, both of which require you to
be able to integrity= -protect traffic carried afgter context
establishment is complete. = So, for example, a public-key-signature
mechanism which includes channe= l bindings in the data it signs during
context establishment would provi= de channel bindings, but not
necessarily the message integrity service.

It is most desirable to provide channel bindings, PRF, mes= sage
integrity, and message confidentiality; various existing GSS-APIapplications depend on each of these.  However, given any of the firs= t
three (or a shared, session-specific secret), we can show you how toderive the rest (however, if the thing you start with is not PRF or a
= key, then the derivation will likely involve a key exchange protocol
lik= e DH, which can be expensive).

-- Jeff




--0-2113692669-1301631545=:75106--