From shawn.emery@oracle.com Thu Jun 2 22:27:39 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330EDE06C6 for ; Thu, 2 Jun 2011 22:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffKRTyZ6O85P for ; Thu, 2 Jun 2011 22:27:38 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 65B3BE068E for ; Thu, 2 Jun 2011 22:27:38 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p535RZ1d009777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 3 Jun 2011 05:27:37 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p535RZxa001082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Jun 2011 05:27:35 GMT Received: from abhmt008.oracle.com (abhmt008.oracle.com [141.146.116.17]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p535RTYX030176 for ; Fri, 3 Jun 2011 00:27:30 -0500 Received: from [10.7.250.160] (/10.7.250.160) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Jun 2011 22:27:29 -0700 Message-ID: <4DE870BC.3020902@oracle.com> Date: Thu, 02 Jun 2011 23:27:24 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.17) Gecko/20110508 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: kitten@ietf.org References: <4DD0AB28.6000406@oracle.com> In-Reply-To: <4DD0AB28.6000406@oracle.com> Content-Type: multipart/mixed; boundary="------------020405040303060008050201" X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4DE870C9.00E5:SCFMA922111,ss=1,fgs=0 Subject: Re: [kitten] Consensus Call on Kitten Recharter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 05:27:39 -0000 This is a multi-part message in MIME format. --------------020405040303060008050201 Content-Type: multipart/alternative; boundary="------------010306020308060401050401" --------------010306020308060401050401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Based on feed-back from WG members the updates have been attached. Please provide any comments/updates no later than 6/9/11. Shawn. kitten co-chair -- On 05/15/11 10:42 PM, Shawn Emery wrote: > > Per kitten WG session discussions in Prague, this starts a consensus > call for the recharter of the kitten WG. The call expires in two > weeks, 5/29/11. Please provide feed-back of the proposed changes, see > attached. Members that find the changes adequate then please respond > as well. Please give feed-back directly to the list. > > Alexey, > Shawn, & > Tom. > -- > kitten co-chairs > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --------------010306020308060401050401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Based on feed-back from WG members the updates have been attached.  Please provide any comments/updates no later than 6/9/11.

Shawn.
kitten co-chair
--
On 05/15/11 10:42 PM, Shawn Emery wrote:

Per kitten WG session discussions in Prague, this starts a consensus call for the recharter of the kitten WG.  The call expires in two weeks, 5/29/11.  Please provide feed-back of the proposed changes, see attached.  Members that find the changes adequate then please respond as well.  Please give feed-back directly to the list.

Alexey,
Shawn, &
Tom.
--
kitten co-chairs

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

--------------010306020308060401050401-- --------------020405040303060008050201 Content-Type: text/plain; name="kitten-charter-diff2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kitten-charter-diff2.txt" kitten-charter: @@ -48,30 +48,36 @@ * Provide a more programmer friendly GSS-API for application developers. This could include reducing the number of interface parameters, for example, by eliminating parameters which are commonly used with the default values. - This WG is also chartered to transition proposed SASL mechanisms as - GSS-API mechanisms: + * Specify an option for exporting partially-established security + contexts and possibly a utility function for exporting security + contexts in an encrypted form, as well as a corresponding utility + function to decrypt and import such security context tokens. - * A SASL Mechanism for OpenID - draft-lear-ietf-sasl-openid-00 - * A SASL Mechanism for SAML - draft-wierenga-ietf-sasl-saml-00 + This WG is also chartered to finalize proposed SASL mechanisms as + GSS-API mechanisms (based on RFC 5801): + * A SASL Mechanism for OpenID: + draft-ietf-kitten-sasl-openid + * SASL Mechanisms for SAML: + draft-ietf-kitten-sasl-saml + draft-cantor-ietf-kitten-saml-ec + * A SASL Mechanism for OAuth + draft-mills-kitten-sasl-oauth + The transition from SASL to GSS-API mechanisms will allow a greater set of applications to utilize said mechanisms with SASL implementations - that support the use of GSS-API mechanisms in SASL (draft-ietf-sasl- - gs2). + that support the use of GSS-API mechanisms in SASL (RFC 5801). - * Shepherd draft-ietf-sasl-digest-to-historic to publication. - This WG should review proposals for new SASL and GSS-API mechanisms, but may take on work on such mechanisms only through a revision of this charter. The WG should also review non-mechanism proposals related to SASL and the GSS-API. However, work that adds SASL or GSS-API support in - application protocols should be handled by the application's WG. + application protocols is out of scope and should be handled by the + corresponding application's WG. Deliverables: * GSS-API: initializing credentials @@ -83,20 +89,24 @@ * GSS-API: interfaces/improvements for better error message reporting * GSS-API: programmer friendly interfaces - * GSS-API: transition SASL mechanism for OpenID + * SASL: SASL mechanism for OpenID - * GSS-API: transition SASL mechanism for SAML + * SASL: SASL mechanisms for SAML + * SASL: SASL mechanism for OAuth + * GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana * GSS-API: publish draft-ietf-kitten-gssapi-naming-exts * SASL: publish draft-melnikov-digest-to-historic - Goals and Milestones: - Done - Submit naming-exts to the IESG as Proposed Standard - Aug 2010 - WGLC on gssapi-extensions-iana - Aug 2010 - Submit gssapi-extensions-iana to the IESG as Proposed Standard + May 2011 Submit SASL OpenID mechanism to the IESG as Proposed Standard + Jun 2011 Submit naming-exts to the IESG as Proposed Standard + Jul 2011 WGLC on gssapi-extensions-iana + Aug 2011 Submit SASL SAML mechanisms to the IESG as Proposed Standard + Sep 2011 Submit gssapi-extensions-iana to the IESG as Proposed Standard + Oct 2011 Submit SASL OAuth mechanism to the IESG as Proposed Standard --------------020405040303060008050201-- From klaas@cisco.com Fri Jun 3 07:46:20 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69DEE0761 for ; Fri, 3 Jun 2011 07:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztMv6En-snN3 for ; Fri, 3 Jun 2011 07:46:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFBCE065D for ; Fri, 3 Jun 2011 07:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1352; q=dns/txt; s=iport; t=1307112379; x=1308321979; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=7/UdAoObqDCfqfuMzqmZZX9W1+ShabpaRS47vavb5Ls=; b=Vr+ZkiA9gJvVJ1BFGKw8HDb6Jml9DlOP56X5yfJNzl8XGEajLtBHzZyO PHE890DWRnd4dc8trLY4pkD8A2yMa8+QwHtE1QD5O2/5MKjhyYOPdqK8M XZDOlt6wXWBtFV9g+agmqyQWsWK8Axd/LUFJoBY4ukEuMC3fM+1XRQVTq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkHALby6E1Io8UR/2dsb2JhbABTmBqOH3eIcaMUnW2GIQSQdI87 X-IronPort-AV: E=Sophos;i="4.65,315,1304294400"; d="scan'208";a="92159976" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 03 Jun 2011 14:46:18 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p53EkG3Z031956 for ; Fri, 3 Jun 2011 14:46:16 GMT Message-ID: <4DE8F3B7.1010700@cisco.com> Date: Fri, 03 Jun 2011 16:46:15 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: kitten@ietf.org References: <4DD0AB28.6000406@oracle.com> <4DE870BC.3020902@oracle.com> In-Reply-To: <4DE870BC.3020902@oracle.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] Consensus Call on Kitten Recharter X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 14:46:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/3/11 7:27 AM, Shawn Emery wrote: Hi Shawn, Works for me. Klaas > > Based on feed-back from WG members the updates have been attached. > Please provide any comments/updates no later than 6/9/11. > > Shawn. > kitten co-chair > -- > On 05/15/11 10:42 PM, Shawn Emery wrote: >> >> Per kitten WG session discussions in Prague, this starts a consensus >> call for the recharter of the kitten WG. The call expires in two >> weeks, 5/29/11. Please provide feed-back of the proposed changes, see >> attached. Members that find the changes adequate then please respond >> as well. Please give feed-back directly to the list. >> >> Alexey, >> Shawn, & >> Tom. >> -- >> kitten co-chairs >> >> >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3o87cACgkQH2Wy/p4XeFIshwCfVjWx8uMXZMth3p/yV+5xs0hQ HBIAoKh2oyd511KSvBi68RA+0W0wW9Zw =tWHe -----END PGP SIGNATURE----- From nico@cryptonector.com Tue Jun 7 14:14:51 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DA211E80C2 for ; Tue, 7 Jun 2011 14:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppJ0JbGGZgK5 for ; Tue, 7 Jun 2011 14:14:50 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id E025811E80A3 for ; Tue, 7 Jun 2011 14:14:50 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id B6F9D594069 for ; Tue, 7 Jun 2011 14:14:50 -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=BoN7peoswDrHy/zjEBzTKQYZBjDukXQj+WjaW4f89/s1 ukGK3CzFkyKiS0DtIQFf9wOsrmK619h6PlB4coe2/UIAo34k9aBsMer5pCMMHxTn rlxSe3oqQc6kEdVf+Rn1ni2VepOAVNubQFIM7l0gTRtYaqLKVjkbQWnmN//ueHw= 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=Fl1ZHpUKsE3VYgXd5SvL+r2/Ltw=; b=dcGj9H3osdF gN2fsLdLhU93lnJWLJruJCPAFyg5Va2hT8At4dLmA5NdY2yY7JFberZE9uM+jt9N 6NTb+eWfqhaM2TQ+Y5iUzBsI6gqbvqAZzOZIiS1zc6ckSbrsjGTa0A59+OtWdRPk tfoPAI9hK8m5ug0G84RmzALpI7W1C3X4= Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 99C70594061 for ; Tue, 7 Jun 2011 14:14:50 -0700 (PDT) Received: by pxi20 with SMTP id 20so4533328pxi.27 for ; Tue, 07 Jun 2011 14:14:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.10.9 with SMTP id e9mr576734pbb.255.1307481289955; Tue, 07 Jun 2011 14:14:49 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 14:14:49 -0700 (PDT) In-Reply-To: <201106071644.p57GiB90004300@fs4113.wdf.sap.corp> References: <201106071644.p57GiB90004300@fs4113.wdf.sap.corp> Date: Tue, 7 Jun 2011 16:14:49 -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, ietf-krb-wg@anl.gov, Thomas Maslen Subject: Re: [kitten] [Ietf-krb-wg] Channel bindings -- interop issue with GSS_C_AF_* X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 21:14:51 -0000 On Tue, Jun 7, 2011 at 11:44 AM, Martin Rex wrote: > Thomas Maslen wrote: >> >> and the general opinion seemed to be that the issue is moot because >> addresses in channel bindings were a mistake and these days you should >> pretty much always be using addressless channel bindings. > > This matches my personal opinion about address-based channel bindings. > They would intefere with firewall traversal, NAT-traversal and any > kind of application-level backend-internal load-balancing and > communication forwarding at protocol levels below GSS-API. Correct. >> In an addressless channel binding, what is the correct address-type >> value to use? =C2=A0Is it 0 (GSS_C_AF_UNSPEC), or is it 255 (GSS_C_AF_NU= LLADDR)? > > I'm confused. =C2=A0An application that doesn't want address-based channe= l > bindings would likely supply GSS_C_NO_CHANNEL_BINDINGS. =C2=A0Mine does. You forget about the "application_data" field, which is where we put the TLS (or whatever) channel bindings data. See RFCs 5056 and 5554. Oddly enough, I don't think we ever specified which GSS_C_AF_* to use. I think the right answer is: memset() the gss_channel_bindings_struct to zero, then set the application_data field. In other words, GSS_C_AF_UNSPEC. Dear KITTEN WG: do we have to update RFC5554 about this?? Or should we file an erratum? Nico -- From nico@cryptonector.com Tue Jun 7 15:53:42 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA85C11E81AE for ; Tue, 7 Jun 2011 15:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.068 X-Spam-Level: X-Spam-Status: No, score=-3.068 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXy2wFPjz+J4 for ; Tue, 7 Jun 2011 15:53:42 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 4B31811E80CF for ; Tue, 7 Jun 2011 15:53:42 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 1BA262C806B for ; Tue, 7 Jun 2011 15:53:42 -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=QIcEHTkPxsxU+P3j6hhAEz+3qKFplelXRD3Qzrj4qo+B 4B7mgiKloz6iJcQdJduzUNg+wv7xyt9rJl8JvmkYhflpL3Ol2CLA4Wi/VJ6x19M4 ndwexBGV7eogQSi0W5LZOgf15KFosMrH7BCGFCekdmiPB4gquQ3Txi4ttm9g/xw= 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=G10RMlCgVsYHTwgK3jaDyaroCeo=; b=kLInttaoW1d E6QZ2m14Ede8Q6eflI1/u7IhjiZ+ClLr8n3tsQeuKn9lScfWKagZo+9xPReXFFXH o4hHvlcRDLc0QRQ1rmuBmvwxffKiyC4rGQqlGs50vNqZp9kG8/tCFUPYEftEOVsh d0lc8OsqVg91zGejvRXzo8wHiTL1Qm5A= Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) (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 01E212C8057 for ; Tue, 7 Jun 2011 15:53:41 -0700 (PDT) Received: by pxi20 with SMTP id 20so4583691pxi.27 for ; Tue, 07 Jun 2011 15:53:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.103 with SMTP id o7mr467266pbc.523.1307487221692; Tue, 07 Jun 2011 15:53:41 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 15:53:41 -0700 (PDT) Date: Tue, 7 Jun 2011 17:53:41 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org, ietf-krb-wg@anl.gov Content-Type: text/plain; charset=UTF-8 Subject: [kitten] Negotiating "DCE style" -- a proposal and advice request X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 22:53:43 -0000 I've a proposal to make, but I need advice. The proposal is: - add a new GSS req_flag: GSS_C_DCE_STYLE_OK (possibly with a nicer name; suggestions?); - [optional] add a authz-data element to use in Authenticator to serve the same purpose as GSS_C_DCE_STYLE_OK, for non-GSS apps; - add a field or more to EncAPRepPart; acceptors/servers would only use the EncAPRepPart extension when the GSS_C_DCE_STYLE_OK (or authz-data element) is present in the initiator/client's AP-REQ's Authenticator. I need advice on the following: a) What better flag name might there be instead of GSS_C_DCE_STYLE_OK? E.g., GSS_C_EXTRA_TOKENS_OK? GSS_C_NEGO_REPLAY_CACHE_AVOIDANCE? GSS_C_NO_RCACHE_OK? b) What to add to EncAPRepPart? And should we add a new SEQUENCE named something like EncAPRepPartExt? I was thinking of adding authorization data to EncAPRepPart, like so: EncAPRepPart ::= [APPLICATION 27] SEQUENCE { ctime[0] KerberosTime, cusec[1] krb5int32, subkey[2] EncryptionKey OPTIONAL, seq-number[3] krb5uint32 OPTIONAL, authorization-data[4] AuthorizationData OPTIONAL, ... } And there would also be a new authorization-data type by which the server would indicate that it understood the GSS_C_DCE_STYLE_OK flag and awaits one more token from the initiator. Is this OK? Would folks prefer a typed hole for anything *other* than authorization data here? My opinion is that we already overload authorization-data, and we're going to do much more of it in the future, plus we are likely to want to have a way for the acceptor to send some authorization data to the initiator, plus symmetry is good when we can have it. Nico -- From nico@cryptonector.com Tue Jun 7 15:55:34 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1627D11E81B2 for ; Tue, 7 Jun 2011 15:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.02 X-Spam-Level: X-Spam-Status: No, score=-3.02 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5E552luZCv4 for ; Tue, 7 Jun 2011 15:55:33 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 7D02611E80CF for ; Tue, 7 Jun 2011 15:55:33 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 53B2210062 for ; Tue, 7 Jun 2011 15:55:33 -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 :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=THaovWE9Y0dEzGu430CK1jjXGSPFD+RE8l04iHDF8ssy DMDGHU6aPkvf7BnyNzY21o8xHw7P5EtuMXqj+eOehBEZ3/5BJ13iqJ1mWAcPk3FV Ykk2ClTYa4D8fBgxwEwldeyN2fAoitr1Jt/P5EsFInl9bFjCYVDZQJ/23bKnXeQ= 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:content-type:content-transfer-encoding; s=cryptonector.com; bh=V7bled1iURTnM3N4i187e83Ht58=; b=DeJJJZuSFD6aXJtUsRd4SUdmlVcI KC1yltj2P0JlrOUMcQ52J3BGNHe9LL+e0ZFQEzZoOsgX/IapNRPjG5H+lO0ckulC /Rmh2DMBECJxo3tr6j+1SNmtFZOHduKJFaIYHDhue/1xjohTZWVBHA1QIWHDnXPV Y8G2yESCSUXjq3M= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 3BD7910059 for ; Tue, 7 Jun 2011 15:55:33 -0700 (PDT) Received: by pwi5 with SMTP id 5so114682pwi.31 for ; Tue, 07 Jun 2011 15:55:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.33 with SMTP id d1mr454823pbk.389.1307487332835; Tue, 07 Jun 2011 15:55:32 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 15:55:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jun 2011 17:55:32 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org, ietf-krb-wg@anl.gov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [kitten] Negotiating "DCE style" -- a proposal and advice request X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 22:55:34 -0000 On Tue, Jun 7, 2011 at 5:53 PM, Nico Williams wrote= : > b) What to add to EncAPRepPart? =C2=A0And should we add a new SEQUENCE > named something like EncAPRepPartExt? Note: for code simplicity reasons, I'd rather a field to the existing SEQUENCE than add a new SEQUENCE. Nico -- From nico@cryptonector.com Tue Jun 7 19:10:12 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBAF11E80E3 for ; Tue, 7 Jun 2011 19:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.406 X-Spam-Level: X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMe5peOcrKNo for ; Tue, 7 Jun 2011 19:10:11 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id EA53D11E80CC for ; Tue, 7 Jun 2011 19:10:10 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 4E3987E4062 for ; Tue, 7 Jun 2011 19:10:01 -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: content-type; q=dns; s=cryptonector.com; b=MC+qlCNdRuhkreg9zH3cz MQtW1CyTfulTb3lrjPDFhbU8g0cLuFI47dBsVXEhVTvAyfyIcbq4yPmYCt8SEskW 9ppbIHyMzJXCynKxXIAsYdebVesUkM/3MmMK1nJ4cMZQw48UJ9y6yc9I/sEdL6zX tEewN/4/Rw0ggXvrdiX/NY= 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:content-type; s=cryptonector.com; bh=y8gPjPUIm6w9lkGtVioZby6 ADDc=; b=B6M4zcMR+nAgYaqyxom/hKtysWq/KwxoXCFEKC4ifSz6+L8282eh2Ps q1Vc0pbNiyWNxSHnpwDzZ2t2wvcHhK4SK0Hvfbgv1soWEoGCjlj6sLmw49yoQQsS n3LqsjoLBw6VO9biMRKmVwfRM94WSIcu8BwaogwZyyENzJuRO1VU= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 3747E7E4058 for ; Tue, 7 Jun 2011 19:10:01 -0700 (PDT) Received: by pvh18 with SMTP id 18so28044pvh.31 for ; Tue, 07 Jun 2011 19:10:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.17.7 with SMTP id k7mr614804pbd.322.1307499000809; Tue, 07 Jun 2011 19:10:00 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 19:10:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jun 2011 21:10:00 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org, ietf-krb-wg@anl.gov Content-Type: multipart/mixed; boundary=bcaec52160717cc97c04a529d50e Subject: Re: [kitten] Negotiating "DCE style" -- a proposal and advice request X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 02:10:12 -0000 --bcaec52160717cc97c04a529d50e Content-Type: text/plain; charset=UTF-8 On Tue, Jun 7, 2011 at 5:55 PM, Nico Williams wrote: > Note: for code simplicity reasons, I'd rather a field to the existing > SEQUENCE than add a new SEQUENCE. To give you an idea of how simple this is, see the attached patch (not yet tested, written in the last 30 minutes). Nico -- --bcaec52160717cc97c04a529d50e Content-Type: application/octet-stream; name="0001-Initial-implementation-of-GSS_C_DCE_STYLE_OK-for-rca.patch" Content-Disposition: attachment; filename="0001-Initial-implementation-of-GSS_C_DCE_STYLE_OK-for-rca.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gonn4lgg0 RnJvbSA4N2ZiN2UwYWM3ODU0NDM5OWRhYWNiMTQ3MTU2NmM0YzMwZGU2MDUwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOaWNvbGFzIFdpbGxpYW1zIDxuaWNvMTAzQGdtYWlsLmNvbT4K RGF0ZTogVHVlLCA3IEp1biAyMDExIDIxOjA3OjM4IC0wNTAwClN1YmplY3Q6IFtQQVRDSF0gSW5p dGlhbCBpbXBsZW1lbnRhdGlvbiBvZiBHU1NfQ19EQ0VfU1RZTEVfT0sgZm9yIHJjYWNoZSBhdm9p ZGFuY2UuCgotLS0KIGxpYi9hc24xL2tyYjUuYXNuMSAgICAgICAgICAgICAgICAgICB8ICAgIDgg KysrKysrLS0KIGxpYi9nc3NhcGkvZ3NzYXBpL2dzc2FwaS5oICAgICAgICAgICB8ICAgIDEgKwog bGliL2dzc2FwaS9rcmI1L2FjY2VwdF9zZWNfY29udGV4dC5jIHwgICAgNSArKysrKwogbGliL2dz c2FwaS9rcmI1L2luaXRfc2VjX2NvbnRleHQuYyAgIHwgICAxNiArKysrKysrKysrKysrKysrCiBs aWIva3JiNS9rcmI1LmggICAgICAgICAgICAgICAgICAgICAgfCAgICAzICsrLQogbGliL2tyYjUv bWtfcmVwLmMgICAgICAgICAgICAgICAgICAgIHwgICAyMiArKysrKysrKysrKysrKysrKysrKysr CiA2IGZpbGVzIGNoYW5nZWQsIDUyIGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pCgpkaWZm IC0tZ2l0IGEvbGliL2FzbjEva3JiNS5hc24xIGIvbGliL2FzbjEva3JiNS5hc24xCmluZGV4IDAy ZmFiN2EuLjdhODk0ZjQgMTAwNjQ0Ci0tLSBhL2xpYi9hc24xL2tyYjUuYXNuMQorKysgYi9saWIv YXNuMS9rcmI1LmFzbjEKQEAgLTcsNiArNyw3IEBAIEVYUE9SVFMKIAlBRC1JRi1SRUxFVkFOVCwK IAlBRC1LRENJc3N1ZWQsCiAJQUQtTG9naW5BbGlhcywKKwlBRC1FeHRyYUFQUERVUmVxdWlyZWQs CiAJQVAtUkVQLAogCUFQLVJFUSwKIAlBUy1SRVAsCkBAIC0xOTMsNyArMTk0LDggQEAgQVVUSERB VEEtVFlQRSA6Oj0gSU5URUdFUiB7CiAJS1JCNS1BVVRIREFUQS1HU1MtQVBJLUVUWVBFLU5FR09U SUFUSU9OKDEyOSksIC0tIEF1dGhlbnRpY2F0b3Igb25seQogCUtSQjUtQVVUSERBVEEtU0lHTlRJ Q0tFVC1PTERFUigtMTcpLAogCUtSQjUtQVVUSERBVEEtU0lHTlRJQ0tFVC1PTEQoMTQyKSwKLQlL UkI1LUFVVEhEQVRBLVNJR05USUNLRVQoNTEyKQorCUtSQjUtQVVUSERBVEEtU0lHTlRJQ0tFVCg1 MTIpLAorCUtSQjUtQVVUSERBVEEtRVhUUkEtQVAtUERVLVJFUVVJUkVEKDEyMzQpCiB9CiAKIC0t IGNoZWNrc3VtdHlwZXMKQEAgLTU0MCw3ICs1NDIsOSBAQCBFbmNBUFJlcFBhcnQgOjo9IFtBUFBM SUNBVElPTiAyN10gICAgIFNFUVVFTkNFIHsKIAljdGltZVswXQkJS2VyYmVyb3NUaW1lLAogCWN1 c2VjWzFdCQlrcmI1aW50MzIsCiAJc3Via2V5WzJdCQlFbmNyeXB0aW9uS2V5IE9QVElPTkFMLAot CXNlcS1udW1iZXJbM10JCWtyYjV1aW50MzIgT1BUSU9OQUwKKwlzZXEtbnVtYmVyWzNdCQlrcmI1 dWludDMyIE9QVElPTkFMLAorCWF1dGhvcml6YXRpb24tZGF0YVs0XSAgIEF1dGhvcml6YXRpb25E YXRhIE9QVElPTkFMLAorCS4uLgogfQogCiBLUkItU0FGRS1CT0RZIDo6PSBTRVFVRU5DRSB7CmRp ZmYgLS1naXQgYS9saWIvZ3NzYXBpL2dzc2FwaS9nc3NhcGkuaCBiL2xpYi9nc3NhcGkvZ3NzYXBp L2dzc2FwaS5oCmluZGV4IGZhNTNhMjkuLmI4NzBhYzQgMTAwNjQ0Ci0tLSBhL2xpYi9nc3NhcGkv Z3NzYXBpL2dzc2FwaS5oCisrKyBiL2xpYi9nc3NhcGkvZ3NzYXBpL2dzc2FwaS5oCkBAIC0xNjAs NiArMTYwLDcgQEAgdHlwZWRlZiBPTV91aW50MzIgZ3NzX3FvcF90OwogI2RlZmluZSBHU1NfQ19J REVOVElGWV9GTEFHIDgxOTIKICNkZWZpbmUgR1NTX0NfRVhURU5ERURfRVJST1JfRkxBRyAxNjM4 NAogI2RlZmluZSBHU1NfQ19ERUxFR19QT0xJQ1lfRkxBRyAzMjc2OAorI2RlZmluZSBHU1NfQ19E Q0VfU1RZTEVfT0sgNjU1MzYKIAogLyoKICAqIENyZWRlbnRpYWwgdXNhZ2Ugb3B0aW9ucwpkaWZm IC0tZ2l0IGEvbGliL2dzc2FwaS9rcmI1L2FjY2VwdF9zZWNfY29udGV4dC5jIGIvbGliL2dzc2Fw aS9rcmI1L2FjY2VwdF9zZWNfY29udGV4dC5jCmluZGV4IDVhMDBlMTIuLmZhYzU5M2IgMTAwNjQ0 Ci0tLSBhL2xpYi9nc3NhcGkva3JiNS9hY2NlcHRfc2VjX2NvbnRleHQuYworKysgYi9saWIvZ3Nz YXBpL2tyYjUvYWNjZXB0X3NlY19jb250ZXh0LmMKQEAgLTUyMyw2ICs1MjMsMTEgQEAgZ3Nza3Ji NV9hY2NlcHRvcl9zdGFydChPTV91aW50MzIgKiBtaW5vcl9zdGF0dXMsCiAJCQkJCQkmY3R4LT5m bGFncywKIAkJCQkJCSZjdHgtPmZ3ZF9kYXRhKTsKIAorCSAgICBpZiAoY3R4LT5mbGFncyAmIEdT U19DX0RDRV9TVFlMRV9PSykgeworCQljdHgtPmZsYWdzIHw9IEdTU19DX0RDRV9TVFlMRTsKKwkJ Y3R4LT5hdXRoX2NvbnRleHQtPmZsYWdzIHw9CisJCSAgICBLUkI1X0FVVEhfQ09OVEVYVF9FWFRS QV9BUF9QRFVfUkVRVUlSRUQ7CisJICAgIH0KIAkgICAga3JiNV9mcmVlX2F1dGhlbnRpY2F0b3Io Y29udGV4dCwgJmF1dGhlbnRpY2F0b3IpOwogCSAgICBpZiAocmV0KSB7CiAJCXJldHVybiByZXQ7 CmRpZmYgLS1naXQgYS9saWIvZ3NzYXBpL2tyYjUvaW5pdF9zZWNfY29udGV4dC5jIGIvbGliL2dz c2FwaS9rcmI1L2luaXRfc2VjX2NvbnRleHQuYwppbmRleCA1ZjhiMDFiLi5hNDU1MTA5IDEwMDY0 NAotLS0gYS9saWIvZ3NzYXBpL2tyYjUvaW5pdF9zZWNfY29udGV4dC5jCisrKyBiL2xpYi9nc3Nh cGkva3JiNS9pbml0X3NlY19jb250ZXh0LmMKQEAgLTU5Miw2ICs1OTIsMTEgQEAgaW5pdF9hdXRo X3Jlc3RhcnQKIAlmbGFncyB8PSBHU1NfQ19EQ0VfU1RZTEUgfCBHU1NfQ19NVVRVQUxfRkxBRzsK IAlhcF9vcHRpb25zIHw9IEFQX09QVFNfTVVUVUFMX1JFUVVJUkVEOwogICAgIH0KKyAgICBpZiAo cmVxX2ZsYWdzICYgR1NTX0NfRENFX1NUWUxFX09LKSB7CisJLyogR1NTX0NfRENFX1NUWUxFIGlt cGxpZXMgR1NTX0NfTVVUVUFMX0ZMQUcgKi8KKwlmbGFncyB8PSBHU1NfQ19EQ0VfU1RZTEVfT0sg fCBHU1NfQ19NVVRVQUxfRkxBRzsKKwlhcF9vcHRpb25zIHw9IEFQX09QVFNfTVVUVUFMX1JFUVVJ UkVEOworICAgIH0KICAgICBpZiAocmVxX2ZsYWdzICYgR1NTX0NfSURFTlRJRllfRkxBRykKIAlm bGFncyB8PSBHU1NfQ19JREVOVElGWV9GTEFHOwogICAgIGlmIChyZXFfZmxhZ3MgJiBHU1NfQ19F WFRFTkRFRF9FUlJPUl9GTEFHKQpAQCAtODI4LDYgKzgzMywxNyBAQCByZXBsX211dHVhbAogICAg IGlmIChyZXRfZmxhZ3MpCiAJKnJldF9mbGFncyA9IGN0eC0+ZmxhZ3M7CiAKKyAgICBpZiAocmVx X2ZsYWdzICYgR1NTX0NfRENFX1NUWUxFX09LICYmIHJlcGwtPmF1dGhvcml6YXRpb25fZGF0YSkg eworCUF1dGhvcml6YXRpb25EYXRhICphZCA9IHJlcGwtPmF1dGhvcml6YXRpb25fZGF0YTsKKwlp bnQgaTsKKworCWZvciAoaSA9IDA7IGkgPCBhZC0+bGVuOyBpKyspIHsKKwkgICAgaWYgKGFkLT52 YWxbaV0uYWRfdHlwZSA9PSBLUkI1X0FVVEhEQVRBX0VYVFJBX0FQX1BEVV9SRVFVSVJFRCkgewor CQlyZXFfZmxhZ3MgKz0gR1NTX0NfRENFX1NUWUxFOworCQlicmVhazsKKwkgICAgfQorCX0KKyAg ICB9CiAgICAgaWYgKHJlcV9mbGFncyAmIEdTU19DX0RDRV9TVFlMRSkgewogCWludDMyX3QgbG9j YWxfc2VxLCByZW1vdGVfc2VxOwogCWtyYjVfZGF0YSBvdXRidWY7CmRpZmYgLS1naXQgYS9saWIv a3JiNS9rcmI1LmggYi9saWIva3JiNS9rcmI1LmgKaW5kZXggZTkwNmI3Yy4uM2IwNGVlZiAxMDA2 NDQKLS0tIGEvbGliL2tyYjUva3JiNS5oCisrKyBiL2xpYi9rcmI1L2tyYjUuaApAQCAtNTkwLDcg KzU5MCw4IEBAIGVudW0gewogICAgIEtSQjVfQVVUSF9DT05URVhUX1JFVF9TRVFVRU5DRSAJCT0g OCwKICAgICBLUkI1X0FVVEhfQ09OVEVYVF9QRVJNSVRfQUxMICAgCQk9IDE2LAogICAgIEtSQjVf QVVUSF9DT05URVhUX1VTRV9TVUJLRVkgICAJCT0gMzIsCi0gICAgS1JCNV9BVVRIX0NPTlRFWFRf Q0xFQVJfRk9SV0FSREVEX0NSRUQJPSA2NAorICAgIEtSQjVfQVVUSF9DT05URVhUX0NMRUFSX0ZP UldBUkRFRF9DUkVECT0gNjQsCisgICAgS1JCNV9BVVRIX0NPTlRFWFRfRVhUUkFfQVBfUERVX1JF UVVJUkVECT0gMTI4CiB9OwogCiAvKiBmbGFncyBmb3Iga3JiNV9hdXRoX2Nvbl9nZW5hZGRycyAq LwpkaWZmIC0tZ2l0IGEvbGliL2tyYjUvbWtfcmVwLmMgYi9saWIva3JiNS9ta19yZXAuYwppbmRl eCA4NGMzMTUyLi40YmM2OWVjIDEwMDY0NAotLS0gYS9saWIva3JiNS9ta19yZXAuYworKysgYi9s aWIva3JiNS9ta19yZXAuYwpAQCAtODgsNiArODgsMjggQEAga3JiNV9ta19yZXAoa3JiNV9jb250 ZXh0IGNvbnRleHQsCiAgICAgfSBlbHNlCiAJYm9keS5zZXFfbnVtYmVyID0gTlVMTDsKIAorICAg IGlmIChhdXRoX2NvbnRleHQtPmZsYWdzICYgS1JCNV9BVVRIX0NPTlRFWFRfRVhUUkFfQVBfUERV X1JFUVVJUkVEKSB7CisJQXV0aG9yaXphdGlvbkRhdGFFbGVtZW50IGFkZTsKKworCWFkZS5hZF90 eXBlID0gS1JCNV9BVVRIREFUQV9FWFRSQV9BUF9QRFVfUkVRVUlSRUQ7CisJYWRlLmFkX2RhdGEu bGVuZ3RoID0gMDsKKwlhZGUuYWRfZGF0YS5kYXRhID0gTlVMTDsKKworCWJvZHkuYXV0aG9yaXph dGlvbl9kYXRhID0gY2FsbG9jKDEsIHNpemVvZigqYm9keS5hdXRob3JpemF0aW9uX2RhdGEpKTsK KwlpZiAoYm9keS5hdXRob3JpemF0aW9uX2RhdGEgPT0gTlVMTCkgeworCSAgICBrcmI1X3NldF9l cnJvcl9tZXNzYWdlKGNvbnRleHQsIEVOT01FTSwgIm91dCBvZiBtZW1vcnkiKTsKKwkgICAgZnJl ZV9FbmNBUFJlcFBhcnQoJmJvZHkpOworCSAgICByZXR1cm4gRU5PTUVNOworCX0KKworCXJldCA9 IGFkZF9BdXRob3JpemF0aW9uRGF0YShib2R5LmF1dGhvcml6YXRpb25fZGF0YSwgJmFkZSk7CisJ aWYgKHJldCkgeworCSAgICBrcmI1X3NldF9lcnJvcl9tZXNzYWdlKGNvbnRleHQsIHJldCwgImFk ZCBBdXRob3JpemF0aW9uRGF0YSBmYWlsZWQiKTsKKwkgICAgZnJlZV9FbmNBUFJlcFBhcnQoJmJv ZHkpOworCSAgICByZXR1cm4gcmV0OworCX0KKyAgICB9CisKICAgICBhcC5lbmNfcGFydC5ldHlw ZSA9IGF1dGhfY29udGV4dC0+a2V5YmxvY2stPmtleXR5cGU7CiAgICAgYXAuZW5jX3BhcnQua3Zu byAgPSBOVUxMOwogCi0tIAoxLjcuMQoK --bcaec52160717cc97c04a529d50e-- From metze@samba.org Tue Jun 7 21:20:04 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167BB11E80B2 for ; Tue, 7 Jun 2011 21:20:04 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kZeqCVJ7ZJG for ; Tue, 7 Jun 2011 21:20:03 -0700 (PDT) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by ietfa.amsl.com (Postfix) with ESMTP id 997EA11E80B0 for ; Tue, 7 Jun 2011 21:20:02 -0700 (PDT) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwJ7eL6yL6M6h8JiYXs/HrEl2yUn8V3w== X-RZG-CLASS-ID: mo05 Received: from [172.30.123.11] (dvm01.metzemix.de [85.214.18.123]) by post.strato.de (fruni mo48) (RZmta 25.18) with ESMTPA id R067den5822vk1 ; Wed, 8 Jun 2011 06:19:52 +0200 (MEST) Message-ID: <4DEEF865.6050203@samba.org> Date: Wed, 08 Jun 2011 06:19:49 +0200 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB64B7CAA63C5568DF09F865E" Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating "DCE style" -- a proposal and advice request X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 04:20:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB64B7CAA63C5568DF09F865E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 08.06.2011 00:53, schrieb Nico Williams: > I've a proposal to make, but I need advice. >=20 > The proposal is: >=20 > - add a new GSS req_flag: GSS_C_DCE_STYLE_OK (possibly with a nicer > name; suggestions?); >=20 > - [optional] add a authz-data element to use in Authenticator to > serve the same purpose as GSS_C_DCE_STYLE_OK, for non-GSS apps; >=20 > - add a field or more to EncAPRepPart; acceptors/servers would only > use the EncAPRepPart extension when the GSS_C_DCE_STYLE_OK (or > authz-data element) is present in the initiator/client's AP-REQ's > Authenticator. >=20 > I need advice on the following: >=20 > a) What better flag name might there be instead of GSS_C_DCE_STYLE_OK? >=20 > E.g., GSS_C_EXTRA_TOKENS_OK? GSS_C_NEGO_REPLAY_CACHE_AVOIDANCE? > GSS_C_NO_RCACHE_OK? anything is better which don't have DCE_STYLE in the name:-) metze --------------enigB64B7CAA63C5568DF09F865E 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.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3u+GUACgkQm70gjA5TCD/nPwCfSZ2Qwo3scTxxUKwPTS0y941q kvEAnArvidkDnNfS0KAMSMQH/tDKe2sB =lJSQ -----END PGP SIGNATURE----- --------------enigB64B7CAA63C5568DF09F865E-- From metze@samba.org Tue Jun 7 21:25:41 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A059811E80A1 for ; Tue, 7 Jun 2011 21:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L76ohXL5Ewll for ; Tue, 7 Jun 2011 21:25:41 -0700 (PDT) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DA511E8071 for ; Tue, 7 Jun 2011 21:25:40 -0700 (PDT) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwJ7eL6yL6M6h8JiYXs/HrEl2yUn8V3w== X-RZG-CLASS-ID: mo05 Received: from [172.30.123.11] (dvm01.metzemix.de [85.214.18.123]) by post.strato.de (klopstock mo7) (RZmta 25.18) with ESMTPA id 6009e6n582m79G ; Wed, 8 Jun 2011 06:25:35 +0200 (MEST) Message-ID: <4DEEF9BC.4040509@samba.org> Date: Wed, 08 Jun 2011 06:25:32 +0200 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9E5AB09BF2A20F81BE8F310C" Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating "DCE style" -- a proposal and advice request X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 04:25:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9E5AB09BF2A20F81BE8F310C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 08.06.2011 04:10, schrieb Nico Williams: > On Tue, Jun 7, 2011 at 5:55 PM, Nico Williams w= rote: >> Note: for code simplicity reasons, I'd rather a field to the existing >> SEQUENCE than add a new SEQUENCE. >=20 > To give you an idea of how simple this is, see the attached patch (not > yet tested, written in the last 30 minutes). + if (ctx->flags & GSS_C_DCE_STYLE_OK) { + ctx->flags |=3D GSS_C_DCE_STYLE; + ctx->auth_context->flags |=3D + KRB5_AUTH_CONTEXT_EXTRA_AP_PDU_REQUIRED; + } Please don't imply GSS_C_DCE_STYLE. metze --------------enig9E5AB09BF2A20F81BE8F310C 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.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3u+bwACgkQm70gjA5TCD8xTQCeJ5K80zd8v2ubuujG05VJnw6b 0AwAn1E9n9ynMpqDP1wR/a6tjRxKKQWs =HSeV -----END PGP SIGNATURE----- --------------enig9E5AB09BF2A20F81BE8F310C-- From nico@cryptonector.com Tue Jun 7 22:30:10 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67C011E808E for ; Tue, 7 Jun 2011 22:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=-1.213, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXIS5e4uZD-h for ; Tue, 7 Jun 2011 22:30:09 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9E86011E8082 for ; Tue, 7 Jun 2011 22:30:09 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 9DC28B805B for ; Tue, 7 Jun 2011 22:30:08 -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=SekrHYMUGXrW87tLtNukv FxHSQaDShgxHIb4WsNosjscR7AZzkGDQup/SoddpVkyiF1HiaIiHjQBaBvyeoKks MyFUfwmcudGU3gc+U3gPDkC11KINocktmHzr45eeYeQN6DDbA8B/zCQu5blYl2/B AwX0YaYECdUKx5GSY5T0A8= 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=2ktlPwCz4bD/BVH4kRVP 49lz3QQ=; b=zAmckk7DdEYVuHxv/8/Ecd7edXOIU7n8W516oSQq4oeOgu7jVQNb 8JLAoxoCKxUwiEe6gYfyTwD052q/zv+4wTJW4lN40m/X7tGbxGe0TChBGY0A2c5G Gt9qtN3X2Y2IL57c2JcL7W8KsLiyYXHwoZQKfntLTsm64U4RAxq/wi8= Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 8E0C5B8057 for ; Tue, 7 Jun 2011 22:30:08 -0700 (PDT) Received: by pxi20 with SMTP id 20so121800pxi.27 for ; Tue, 07 Jun 2011 22:30:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.37.3 with SMTP id u3mr557730pbj.456.1307511008085; Tue, 07 Jun 2011 22:30:08 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 22:30:07 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 22:30:07 -0700 (PDT) In-Reply-To: <4DEEF9BC.4040509@samba.org> References: <4DEEF9BC.4040509@samba.org> Date: Wed, 8 Jun 2011 00:30:07 -0500 Message-ID: From: Nico Williams To: "Stefan (metze) Metzmacher" Content-Type: multipart/alternative; boundary=bcaec520f3072d47b404a52ca120 Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating "DCE style" -- a proposal and advice request X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 05:30:10 -0000 --bcaec520f3072d47b404a52ca120 Content-Type: text/plain; charset=UTF-8 On Jun 7, 2011 11:25 PM, "Stefan (metze) Metzmacher" wrote: > Am 08.06.2011 04:10, schrieb Nico Williams: > > To give you an idea of how simple this is, see the attached patch (not > > yet tested, written in the last 30 minutes). > > > + if (ctx->flags & GSS_C_DCE_STYLE_OK) { > + ctx->flags |= GSS_C_DCE_STYLE; > + ctx->auth_context->flags |= > + KRB5_AUTH_CONTEXT_EXTRA_AP_PDU_REQUIRED; > + } > > Please don't imply GSS_C_DCE_STYLE. Why not? Nico -- --bcaec520f3072d47b404a52ca120 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Jun 7, 2011 11:25 PM, "Stefan (metze) Metzmacher" <metze@samba.org> wrote:
> Am 08.06.2011 04:10, schrieb Nico Williams:
> > To give you an idea of how simple this is, see the attached patch= (not
> > yet tested, written in the last 30 minutes).
>
>
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (ctx->flags & GSS_C_DCE= _STYLE_OK) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ctx->flags |=3D = GSS_C_DCE_STYLE;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ctx->auth_contex= t->flags |=3D
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 KRB5_= AUTH_CONTEXT_EXTRA_AP_PDU_REQUIRED;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>
> Please don't imply GSS_C_DCE_STYLE.

Why not?

Nico
--

--bcaec520f3072d47b404a52ca120-- From stephen.farrell@cs.tcd.ie Wed Jun 8 00:38:44 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFB121F84A5 for ; Wed, 8 Jun 2011 00:38:44 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN1Ay8fcJQ4C for ; Wed, 8 Jun 2011 00:38:43 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4F10A21F84A2 for ; Wed, 8 Jun 2011 00:38:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DA97B153811 for ; Wed, 8 Jun 2011 08:38:40 +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=1307518720; bh=b/ILx+ptyASVjk7/UPOojA6Q 7YrZnTgZwSyPTzc2Org=; b=RPvCiK2KkMXyTVJbreRW7Y5feux6NjyFnMXTeili z06VqPyNfiMTY/VLrZTbKr6JQ2qP0Dg2u0tpONc4x1UQi2CWTFjJWFb3OQVgOYLL aXuvxYMUaQaYtx7DXgkCBkSArdQNX4o1VLu+HYFlzLB0aAqRLaDBADZXORzWnvaJ niZo0mealQ6LW6Cb7A7VfhHNitYt/6otE4MCpIRsTPuRUe0QYCYfQYFcice3/bg8 P/sRFjzfy2iuW8MsjPH5B7Y9m+zK8831GiFIoEMIejnOjuuAu9h/d7Y1IzPToxJg zS1vfbCh6rt0fX/7RlAdtIrJFhIhVt1JYnopbuFwFrNhYA== 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 0e6sxsyMFRTE for ; Wed, 8 Jun 2011 08:38:40 +0100 (IST) Received: from [143.169.220.220] (unknown [143.169.220.220]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 108C615380B for ; Wed, 8 Jun 2011 08:38:38 +0100 (IST) Message-ID: <4DEF26FE.5070904@cs.tcd.ie> Date: Wed, 08 Jun 2011 08:38:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 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] Fwd: [Technical Errata Reported] RFC5801 (2825) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 07:38:44 -0000 Hi all, Can you confirm that this is correct, or not? Thanks, S. -------- Original Message -------- Subject: [Technical Errata Reported] RFC5801 (2825) Date: Tue, 7 Jun 2011 20:58:20 -0700 (PDT) From: RFC Errata System To: simon@josefsson.org, Nicolas.Williams@oracle.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, tlyu@mit.edu, kurt.zeilenga@isode.com CC: thomas.maslen@quest.com, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC5801, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5801&eid=2825 -------------------------------------- Type: Technical Reported by: Thomas Maslen Section: 5.1 Original Text ------------- The initiator-address-type and acceptor-address-type fields of the GSS-CHANNEL-BINDINGS structure MUST be set to 0. Corrected Text -------------- The initiator-address-type and acceptor-address-type fields of the GSS-CHANNEL-BINDINGS structure MUST be set to 255 (GSS_C_AF_NULLADDR). Notes ----- See RFC 2744, section 3.11, last paragraph: "[...] or omit addressing information, specifying GSS_C_AF_NULLADDR as the address-types". Appendix A of RFC 2744 specifies that the value of GSS_C_AF_NULLADDR is 255. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5801 (draft-ietf-sasl-gs2-20) -------------------------------------- Title : Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family Publication Date : July 2010 Author(s) : S. Josefsson, N. Williams Category : PROPOSED STANDARD Source : Simple Authentication and Security Layer Area : Security Stream : IETF Verifying Party : IESG From simon@josefsson.org Wed Jun 8 01:02:29 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2559121F855F for ; Wed, 8 Jun 2011 01:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enmLtXt3EK9V for ; Wed, 8 Jun 2011 01:02:28 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id EB23721F843D for ; Wed, 8 Jun 2011 01:02:24 -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 p58827UZ016370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 8 Jun 2011 10:02:09 +0200 From: Simon Josefsson To: Stephen Farrell References: <4DEF26FE.5070904__4175.18786057389$1307518736$gmane$org@cs.tcd.ie> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110608:kitten@ietf.org::94dxZ8gTeFrnkp7P:33eV X-Hashcash: 1:22:110608:stephen.farrell@cs.tcd.ie::XvFMTOSVlRVVbScr:1/xC Date: Wed, 08 Jun 2011 10:02:07 +0200 In-Reply-To: <4DEF26FE.5070904__4175.18786057389$1307518736$gmane$org@cs.tcd.ie> (Stephen Farrell's message of "Wed, 08 Jun 2011 08:38:38 +0100") Message-ID: <87d3ioycn4.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) 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] Fwd: [Technical Errata Reported] RFC5801 (2825) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 08:02:29 -0000 Stephen Farrell writes: > Hi all, > > Can you confirm that this is correct, or not? I think we could use some more discussion before approving this -- for example, what impact does this have on existing implementations? I will try to change my implementation to use 255 instead of 0 and see if it still works and inteoperates with my old version. It would be useful if others could do similar experiments. I don't expect serious problems, but I think we should consider the impact before approving this. I do agree it is a bug in the specification though. /Simon > Thanks, > S. > > -------- Original Message -------- > Subject: [Technical Errata Reported] RFC5801 (2825) > Date: Tue, 7 Jun 2011 20:58:20 -0700 (PDT) > From: RFC Errata System > To: simon@josefsson.org, Nicolas.Williams@oracle.com, > stephen.farrell@cs.tcd.ie, turners@ieca.com, tlyu@mit.edu, > kurt.zeilenga@isode.com > CC: thomas.maslen@quest.com, rfc-editor@rfc-editor.org > > > The following errata report has been submitted for RFC5801, > "Using Generic Security Service Application Program Interface (GSS-API) > Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 > Mechanism Family". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5801&eid=2825 > > -------------------------------------- > Type: Technical > Reported by: Thomas Maslen > > Section: 5.1 > > Original Text > ------------- > The initiator-address-type and acceptor-address-type fields of the > GSS-CHANNEL-BINDINGS structure MUST be set to 0. > > > Corrected Text > -------------- > The initiator-address-type and acceptor-address-type fields of the > GSS-CHANNEL-BINDINGS structure MUST be set to 255 (GSS_C_AF_NULLADDR). > > > Notes > ----- > See RFC 2744, section 3.11, last paragraph: "[...] or omit addressing > information, specifying GSS_C_AF_NULLADDR as the address-types". > > Appendix A of RFC 2744 specifies that the value of GSS_C_AF_NULLADDR is 255. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5801 (draft-ietf-sasl-gs2-20) > -------------------------------------- > Title : Using Generic Security Service Application Program > Interface (GSS-API) Mechanisms in Simple Authentication and Security > Layer (SASL): The GS2 Mechanism Family > Publication Date : July 2010 > Author(s) : S. Josefsson, N. Williams > Category : PROPOSED STANDARD > Source : Simple Authentication and Security Layer > Area : Security > Stream : IETF > Verifying Party : IESG From stephen.farrell@cs.tcd.ie Wed Jun 8 03:03:00 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F48421F851C for ; Wed, 8 Jun 2011 03:03:00 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQlu29zoqQ7S for ; Wed, 8 Jun 2011 03:02:59 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3F11E21F851B for ; Wed, 8 Jun 2011 03:02:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 24134153811; Wed, 8 Jun 2011 11:02:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1307527373; bh=Z604eVppM+ToEi ptAaQK4I8D/n7Dy/ForqD51vUgURo=; b=uNMXEDvjXg7POOoYwKpoRYTTdaVWL1 9Ip4fOP/uDUX06broZE5iiq50ZcAZYw3mU+oC2E2VxCfYKZud3al26SQC/xd0UA0 YBJgLOVoDeCEhZ71Ngqz4drybMn8oo/cLCKue0j13aAik7mlHeekSy4JG0r7MmIB m5NrpxfuTbLigCW04ZWp9ke4T4Szv8yho/OcwvD26VIGFOPKszl08ald/qof4SeY Fw7V66CxzLgi4OBfhW+l69/5uVgR2pRhIZWw9CPUBvNHbwE//6NpGK8v9llnIOYL O1zSPiDKsUtjwVAkNvuwKTGZdaqpRnbj5JR+NpCWxSU9TPGdBs80gM6A== 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 F-Fc5N7b56g4; Wed, 8 Jun 2011 11:02:53 +0100 (IST) Received: from [143.169.220.220] (unknown [143.169.220.220]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D4A8615380B; Wed, 8 Jun 2011 11:02:47 +0100 (IST) Message-ID: <4DEF48C0.3000508@cs.tcd.ie> Date: Wed, 08 Jun 2011 11:02:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Simon Josefsson References: <4DEF26FE.5070904__4175.18786057389$1307518736$gmane$org@cs.tcd.ie> <87d3ioycn4.fsf@latte.josefsson.org> In-Reply-To: <87d3ioycn4.fsf@latte.josefsson.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5801 (2825) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 10:03:00 -0000 On 08/06/11 09:02, Simon Josefsson wrote: > Stephen Farrell writes: > >> Hi all, >> >> Can you confirm that this is correct, or not? > > I think we could use some more discussion before approving this -- for > example, what impact does this have on existing implementations? Good point. I'm fine with waiting for the WG to give me the answer that I'll cut'n'paste into the errata tool:-) Sooner is of course better for that. Thanks, S. > > I will try to change my implementation to use 255 instead of 0 and see > if it still works and inteoperates with my old version. It would be > useful if others could do similar experiments. I don't expect serious > problems, but I think we should consider the impact before approving > this. > > I do agree it is a bug in the specification though. > > /Simon > >> Thanks, >> S. >> >> -------- Original Message -------- >> Subject: [Technical Errata Reported] RFC5801 (2825) >> Date: Tue, 7 Jun 2011 20:58:20 -0700 (PDT) >> From: RFC Errata System >> To: simon@josefsson.org, Nicolas.Williams@oracle.com, >> stephen.farrell@cs.tcd.ie, turners@ieca.com, tlyu@mit.edu, >> kurt.zeilenga@isode.com >> CC: thomas.maslen@quest.com, rfc-editor@rfc-editor.org >> >> >> The following errata report has been submitted for RFC5801, >> "Using Generic Security Service Application Program Interface (GSS-API) >> Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 >> Mechanism Family". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5801&eid=2825 >> >> -------------------------------------- >> Type: Technical >> Reported by: Thomas Maslen >> >> Section: 5.1 >> >> Original Text >> ------------- >> The initiator-address-type and acceptor-address-type fields of the >> GSS-CHANNEL-BINDINGS structure MUST be set to 0. >> >> >> Corrected Text >> -------------- >> The initiator-address-type and acceptor-address-type fields of the >> GSS-CHANNEL-BINDINGS structure MUST be set to 255 (GSS_C_AF_NULLADDR). >> >> >> Notes >> ----- >> See RFC 2744, section 3.11, last paragraph: "[...] or omit addressing >> information, specifying GSS_C_AF_NULLADDR as the address-types". >> >> Appendix A of RFC 2744 specifies that the value of GSS_C_AF_NULLADDR is 255. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5801 (draft-ietf-sasl-gs2-20) >> -------------------------------------- >> Title : Using Generic Security Service Application Program >> Interface (GSS-API) Mechanisms in Simple Authentication and Security >> Layer (SASL): The GS2 Mechanism Family >> Publication Date : July 2010 >> Author(s) : S. Josefsson, N. Williams >> Category : PROPOSED STANDARD >> Source : Simple Authentication and Security Layer >> Area : Security >> Stream : IETF >> Verifying Party : IESG > From hartmans@mit.edu Wed Jun 8 09:57:13 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A2A11E8116 for ; Wed, 8 Jun 2011 09:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxpg8i0DYtvY for ; Wed, 8 Jun 2011 09:57:13 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7868211E8189 for ; Wed, 8 Jun 2011 09:57:13 -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 59EFD20115; Wed, 8 Jun 2011 12:52:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 98CC94426; Wed, 8 Jun 2011 12:57:07 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <201106071831.p57IVNmb010502@fs4113.wdf.sap.corp> <201106071900.p57J0uCN012135@fs4113.wdf.sap.corp> <87oc29xrtn.fsf@latte.josefsson.org> Date: Wed, 08 Jun 2011 12:57:07 -0400 In-Reply-To: (Nico Williams's message of "Tue, 7 Jun 2011 16:23:48 -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, Simon Josefsson , "ietf-krb-wg@anl.gov" Subject: Re: [kitten] [Ietf-krb-wg] Channel bindings -- interop issue with GSS_C_AF_* X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 16:57:14 -0000 I think RFC 2744 chose the wrong constant for nulladdr; it should have been 0 not 255. I think we need to update RFC 2744 and 5554. I believe that 1) Mechanism implementations should collapse unspecified address with no actual data and null address together 2) The Kerberos mechanism should do so in a manner compatible with Microsoft 3) We need to explicitly specify what applications should do here. If someone argues that we cannot make incompatible changes to 2744, I respond that compatibility with the implementations we know about is more important to me than compatibility with the spec and if forced to choose I will choose the implementations. From nico@cryptonector.com Wed Jun 8 10:09:50 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C42721F84F1 for ; Wed, 8 Jun 2011 10:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.18 X-Spam-Level: X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[AWL=-1.203, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNbICAatt8d5 for ; Wed, 8 Jun 2011 10:09:50 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0E33B21F84F0 for ; Wed, 8 Jun 2011 10:09:50 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id B0D94674093 for ; Wed, 8 Jun 2011 10:09:49 -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=kfaIGRK7jkAt5XQqlRZu5u9UdYmnH7zYX8X9fEUFvCjO DeyygUuZZnPspbd3b7h0Pi1VtfbsbGJ7xyQ2GXvGfmfnTGlflLGblZiMNjmph5C8 ezj5M/c5lJ+yxo3EqZHmbYT1pbfKQw3eRrPdToDG0fdwm1KJK4NHOoPp7k96sgo= 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=QzllMIvS0sU1G05mIHWD6iZGX14=; b=Z01zLOnbMNE BiBC6lyl+LajzkuJrBzZkRb+f49skY4gJe2aRuSEYArS9uehrU3DP+sPkNptKO+T TGZbzmoM6YIS/Q+SyspImBmdHiFxJ2fRwQ5MSZsElGV0IcA+a69/LHBxKPiRUs8k iwyn9DbQ31nZI3T2LkerLejgebZVkvYE= Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) (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 A44E76740DA for ; Wed, 8 Jun 2011 10:05:29 -0700 (PDT) Received: by pxi20 with SMTP id 20so545156pxi.27 for ; Wed, 08 Jun 2011 10:05:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.37.3 with SMTP id u3mr908868pbj.456.1307552728795; Wed, 08 Jun 2011 10:05:28 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 8 Jun 2011 10:05:28 -0700 (PDT) In-Reply-To: References: <201106071831.p57IVNmb010502@fs4113.wdf.sap.corp> <201106071900.p57J0uCN012135@fs4113.wdf.sap.corp> <87oc29xrtn.fsf@latte.josefsson.org> Date: Wed, 8 Jun 2011 12:05:28 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Simon Josefsson , "ietf-krb-wg@anl.gov" Subject: Re: [kitten] [Ietf-krb-wg] Channel bindings -- interop issue with GSS_C_AF_* X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 17:09:50 -0000 On Wed, Jun 8, 2011 at 11:57 AM, Sam Hartman wrote: > I think RFC 2744 chose the wrong constant for nulladdr; it should have > been 0 not 255. =C2=A0I think we need to update RFC 2744 and 5554. > I believe that I'm agnostic as to that. I don't mind saying "must use GSS_C_AF_UNSPEC and null addresses" and leaving RFC2744 alone. > 1) Mechanism implementations should collapse unspecified address with no > actual data and null address together > > 2) The Kerberos mechanism should do so in a manner compatible with > Microsoft Agreed, though (2) subsumes (1). > 3) We need to explicitly specify what applications should do here. > > If someone argues that we cannot make incompatible changes to 2744, I > respond that compatibility with the implementations we know about is > more important to me than compatibility with the spec and if forced to > choose I will choose the implementations. +1 Nico -- From nico@cryptonector.com Wed Jun 8 10:16:31 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A9821F8582 for ; Wed, 8 Jun 2011 10:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-1.172, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12mi3skrvRAV for ; Wed, 8 Jun 2011 10:16:31 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id D31A321F8581 for ; Wed, 8 Jun 2011 10:16:30 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id A6716594074 for ; Wed, 8 Jun 2011 10:16:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=VlW0h2B92rcFv5wOH31z/ FmPhyDvEwvRUN3Pxz9V01Y5llR/QyU8LYEZuKwsMSdrvpku73/zVNH/hXyScJe5O DJzoZ/AhgZ/i5ueFum63ck9Ml1+x/jFHpaNVYU+QiKhbaJNlbLOnWaeVoZYgFl9J x83AJjUmmF5M47EpkM16lU= 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=//B5KwKMeSXqGHicIMaN 3EARXY8=; b=HlywK1JOgthGjB4KiTHA7W+0NrDHcADDiif18sy1fahDfWXMCHSA aM/7nLAMZ6bL33xohVW/k4isVbOdgmAHPnXcm9vKDJ6dmive3WCcN9TnE96wAFBT AJzKxB7BsvbwopkzWIyS5UhFVwx803N8qVWUUl8f++HYd/TiiEQ8f1Y= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 78DA2594071 for ; Wed, 8 Jun 2011 10:16:30 -0700 (PDT) Received: by pzk5 with SMTP id 5so381491pzk.31 for ; Wed, 08 Jun 2011 10:16:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.20.137 with SMTP id n9mr906728pbe.121.1307553390133; Wed, 08 Jun 2011 10:16:30 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 8 Jun 2011 10:16:30 -0700 (PDT) In-Reply-To: References: <201106071831.p57IVNmb010502@fs4113.wdf.sap.corp> <201106071900.p57J0uCN012135@fs4113.wdf.sap.corp> <87oc29xrtn.fsf@latte.josefsson.org> Date: Wed, 8 Jun 2011 12:16:30 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Simon Josefsson , "ietf-krb-wg@anl.gov" Subject: Re: [kitten] [Ietf-krb-wg] Channel bindings -- interop issue with GSS_C_AF_* X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 17:16:31 -0000 Another possibility is that we fix only RFC5554 to say that when null addresses are provided then the address families must be a specific one and that mechanisms must coerce those to that one specific family if the application supplied the wrong one. We then need only determine which one Windows is using now. Nico -- From Thomas.Maslen@quest.com Wed Jun 8 10:38:39 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B06A11E8174 for ; Wed, 8 Jun 2011 10:38:39 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UTn3G1eoh8x for ; Wed, 8 Jun 2011 10:38:38 -0700 (PDT) Received: from alvetxw01.quest.com (alvetxw01.quest.com [12.106.87.93]) by ietfa.amsl.com (Postfix) with ESMTP id 66CF811E8076 for ; Wed, 8 Jun 2011 10:38:37 -0700 (PDT) Received: from ALVHTXW10.prod.quest.corp (10.1.135.22) by alvetxw01.quest.com (10.1.100.93) with Microsoft SMTP Server (TLS) id 14.1.255.0; Wed, 8 Jun 2011 10:35:18 -0700 Received: from ALVMBXW01.prod.quest.corp ([fe80::48dd:e065:86b3:9cee]) by ALVHTXW10.prod.quest.corp ([::1]) with mapi id 14.01.0218.012; Wed, 8 Jun 2011 10:38:37 -0700 From: Thomas Maslen To: Nico Williams , Sam Hartman Thread-Topic: [Ietf-krb-wg] Channel bindings -- interop issue with GSS_C_AF_* Thread-Index: AQHMJf0Zgp1L8fcswUq0Wg4hAhbIRpS0KPsA//+NS7E= Date: Wed, 8 Jun 2011 17:38:36 +0000 Message-ID: References: <201106071831.p57IVNmb010502@fs4113.wdf.sap.corp> <201106071900.p57J0uCN012135@fs4113.wdf.sap.corp> <87oc29xrtn.fsf@latte.josefsson.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.104.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "kitten@ietf.org" , Simon Josefsson , "ietf-krb-wg@anl.gov" Subject: Re: [kitten] [Ietf-krb-wg] Channel bindings -- interop issue with GSS_C_AF_* X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 17:38:39 -0000 Nico Williams wrote:=0A= >=0A= > [...] We then need only determine which one Windows is using now.=0A= =0A= My understanding -- based both on some Microsoft documentation and on=0A= tweaking our implementation to validate a CB hash generated by a Windows=0A= HTTPS-SPNEGO client -- is that Microsoft does exactly the same thing that= =0A= you specified in RFC5801: set the address-type to zero (and of course the= =0A= address-length is also zero).=0A= =0A= =0A= And I agree with Sam + you: we shouldn't break Microsoft's implementation,= =0A= nor should we break RFC5801. Instead we should update RFC2744 /=0A= RFC5554 / whatever to use 0, not 255, as the address-type for omitted addre= sses.=0A= From nico@cryptonector.com Wed Jun 8 10:44:25 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8C411E8125 for ; Wed, 8 Jun 2011 10:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER2Qyr+GCnbH for ; Wed, 8 Jun 2011 10:44:24 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id B868B11E8076 for ; Wed, 8 Jun 2011 10:44:24 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 567FB202017 for ; Wed, 8 Jun 2011 10:44:24 -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=v9yfiblj8CYmfQWAkHAGQtXGKEJ02Jqelzx78bqS3vYN GrKVZCTvki7QDDafoCE3xzHpfRA6OZqH9/vT5Bt4XPiXNC/bXcStxmlp4XEO7LeA UbSjn2vr5KQFu09DsIUBvVthucHMzmMuEsr3F++fD9BbWQYEFaMF+Pne0hweY1s= 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=QOeVo6d+NXZEbfseus/Kzfya+9Y=; b=C0zCrit5K49 3tshthmV5rkXn7NL7ln1TgOZVTKbstXy6b3q7qUJhCi6h6gzQBMgMvuw6XVJiHel 245PhzB89yi/qJ1lEa+tgniSmfNTvDAbYgVqyyi2aBHpq4Ezbbf3jfhMJT+eF5VP tYxJn4vY8VJ+NWZ+C1XWh0sxb08wTGQ0= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 9D7C3202038 for ; Wed, 8 Jun 2011 10:44:23 -0700 (PDT) Received: by pwi5 with SMTP id 5so394539pwi.31 for ; Wed, 08 Jun 2011 10:44:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.31.135 with SMTP id a7mr1043198pbi.54.1307555063156; Wed, 08 Jun 2011 10:44:23 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 8 Jun 2011 10:44:23 -0700 (PDT) In-Reply-To: References: <201106071831.p57IVNmb010502@fs4113.wdf.sap.corp> <201106071900.p57J0uCN012135@fs4113.wdf.sap.corp> <87oc29xrtn.fsf@latte.josefsson.org> Date: Wed, 8 Jun 2011 12:44:23 -0500 Message-ID: From: Nico Williams To: Thomas Maslen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson , Sam Hartman , "ietf-krb-wg@anl.gov" Subject: Re: [kitten] [Ietf-krb-wg] Channel bindings -- interop issue with GSS_C_AF_* X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 17:44:25 -0000 On Wed, Jun 8, 2011 at 12:38 PM, Thomas Maslen wr= ote: > Nico Williams wrote: >> [...] We then need only determine which one Windows is using now. > > My understanding -- based both on some Microsoft documentation and on > tweaking our implementation to validate a CB hash generated by a Windows > HTTPS-SPNEGO client -- is that Microsoft does exactly the same thing that > you specified in RFC5801: =C2=A0set the address-type to zero (and of cour= se the > address-length is also zero). Thanks, this is great information. > And I agree with Sam + you: =C2=A0we shouldn't break Microsoft's implemen= tation, > nor should we break RFC5801. =C2=A0Instead we should update RFC2744 / > RFC5554 / whatever to use 0, not 255, as the address-type for omitted add= resses. RFC5554 is basically an update to RFC2743 adding to the abstract API what RFC2744 had effectively done. So I think an update or erratum to RFC5554 will suffice. An erratum to RFC2744 would not hurt though. From nico@cryptonector.com Wed Jun 8 12:18:38 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B983211E818E for ; Wed, 8 Jun 2011 12:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=-1.156, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VBqLQNZJANq for ; Wed, 8 Jun 2011 12:18:37 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0BA11E8100 for ; Wed, 8 Jun 2011 12:18:37 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id CCAF8350084 for ; Wed, 8 Jun 2011 12:18:33 -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=tVOWpLVv7bDN6TUx0i/Pv n9KezqMw3mdfpgqpQejLH0qDtFfQqoAuooZWmfCls2LBOnRzV7WlMXrIOrOkEACy gIUSBK95W1UgS+olj1SeRfAnzKij+gljRhgyoQ6RomGfnOKmg03vV9/jLhQhj4w6 BGJRj0XmQEO2bphAXI5C/c= 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=dGxe8DQxmDKTOxGqPUQy lhfF0MA=; b=FJvUXbtg2LdyKAREze/hlS0qx9VZsTWpt3oA9/GII8xxn0nZ1Uv0 3Wv7cLB2bh+CaruBgWiu4d4/k7gWf4iba0sibp5EM0+0ahx6wYfnyPUKAB5sQQOX mwfq90r3oJWf5qVSesyMq9BJtZ5Rx2ARcqiH4u76GS4dKJScRVIVuB4= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.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 B0A0335007F for ; Wed, 8 Jun 2011 12:18:33 -0700 (PDT) Received: by pzk5 with SMTP id 5so432913pzk.31 for ; Wed, 08 Jun 2011 12:18:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.10.9 with SMTP id e9mr1217283pbb.255.1307560713276; Wed, 08 Jun 2011 12:18:33 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 8 Jun 2011 12:18:33 -0700 (PDT) In-Reply-To: References: <4DEEF9BC.4040509@samba.org> Date: Wed, 8 Jun 2011 14:18:33 -0500 Message-ID: From: Nico Williams To: "Stefan (metze) Metzmacher" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating "DCE style" -- a proposal and advice request X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 19:18:38 -0000 On Wed, Jun 8, 2011 at 12:30 AM, Nico Williams wrote: > On Jun 7, 2011 11:25 PM, "Stefan (metze) Metzmacher" > wrote: >> Please don't imply GSS_C_DCE_STYLE. > > Why not? My guess is that you don't like the gratuitous differences between DCE style and the standard mechanism. I tend to agree, but as you can see, it's rather easy to implement negotiation of three-legged Kerberos if I re-use DCE style. It's probably not that much harder to just add the extra leg without implying DCE style, but all implementations will need to implement DCE style anyways (all except Samba??). Anyways, do please explain why not imply DCE style. Thanks, Nico -- From mrex@sap.com Wed Jun 8 12:50:56 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA34421F84B7 for ; Wed, 8 Jun 2011 12:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.945 X-Spam-Level: X-Spam-Status: No, score=-8.945 tagged_above=-999 required=5 tests=[AWL=1.304, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H-IcKAjmx+I for ; Wed, 8 Jun 2011 12:50:56 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E9E3C21F84B6 for ; Wed, 8 Jun 2011 12:50:55 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p58Jolku027719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Jun 2011 21:50:47 +0200 (MEST) From: Martin Rex Message-Id: <201106081950.p58JokTE006270@fs4113.wdf.sap.corp> To: hartmans-ietf@mit.edu (Sam Hartman) Date: Wed, 8 Jun 2011 21:50:46 +0200 (MEST) In-Reply-To: from "Sam Hartman" at Jun 8, 11 12:57:07 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, ietf-krb-wg@anl.gov, simon@josefsson.org Subject: Re: [kitten] [Ietf-krb-wg] Channel bindings -- interop issue with GSS_C_AF_* X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 19:50:56 -0000 Sam Hartman wrote: > > I think RFC 2744 chose the wrong constant for nulladdr; it should have > been 0 not 255. I think we need to update RFC 2744 and 5554. > I believe that > > 1) Mechanism implementations should collapse unspecified address with no > actual data and null address together > > 2) The Kerberos mechanism should do so in a manner compatible with > Microsoft > > 3) We need to explicitly specify what applications should do here. > > If someone argues that we cannot make incompatible changes to 2744, I > respond that compatibility with the implementations we know about is > more important to me than compatibility with the spec and if forced to > choose I will choose the implementations. In case I my messages were conceived as ambiguous: I'm OK with updating the relevant specs to formally allow _and_ document what the current installed base is doing, for all of the specs that we know about. Changing rfc2744 in a backwards incompatible fashion would be a bad idea, but I don't think that is necessary. Relaxing rfc-2744 should be sufficient. Two things should go into rfc-2744. - We need to allow taggging an absent address (i.e. OctetString of size zero) with GSS_C_AF_UNSPEC(0). The current wording of rfc-2744 implies that absent address data needs to be tagged with GSS_C_AF_NULLADDR(255). - We need to document which specs are going to require GSS_C_AF_UNSPEC(0) with absent network addresses and non-empty application_data channel bindings to match actual implementation practice and for interoperability with the installed base of that specs. -Martin From metze@samba.org Wed Jun 8 14:14:54 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11C511E80CE for ; Wed, 8 Jun 2011 14:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXkzEVNSDPko for ; Wed, 8 Jun 2011 14:14:54 -0700 (PDT) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7198F11E809E for ; Wed, 8 Jun 2011 14:14:52 -0700 (PDT) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwJ7eL6yL6M6h8JiYXs/HrEl2yUn8V3w== X-RZG-CLASS-ID: mo05 Received: from [172.30.123.11] (dvm01.metzemix.de [85.214.18.123]) by post.strato.de (mrclete mo60) (RZmta 25.18) with ESMTPA id x02b42n58JbKZO ; Wed, 8 Jun 2011 23:14:47 +0200 (MEST) Message-ID: <4DEFB74D.5060402@samba.org> Date: Wed, 08 Jun 2011 19:54:21 +0200 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nico Williams References: <4DEEF9BC.4040509@samba.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA5CE3EF3782761DCB8500965" Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating "DCE style" -- a proposal and advice request X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 21:14:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA5CE3EF3782761DCB8500965 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 08.06.2011 07:30, schrieb Nico Williams: > On Jun 7, 2011 11:25 PM, "Stefan (metze) Metzmacher" > wrote: >> Am 08.06.2011 04:10, schrieb Nico Williams: >>> To give you an idea of how simple this is, see the attached patch (no= t >>> yet tested, written in the last 30 minutes). >> >> >> + if (ctx->flags & GSS_C_DCE_STYLE_OK) { >> + ctx->flags |=3D GSS_C_DCE_STYLE; >> + ctx->auth_context->flags |=3D >> + KRB5_AUTH_CONTEXT_EXTRA_AP_PDU_REQUIRED; >> + } >> >> Please don't imply GSS_C_DCE_STYLE. >=20 > Why not? Because the new feature should be completely unrelated to GSS_C_DCE_STYLE= =2E GSS_C_DCE_STYLE has more implications than just the 3 leg handshake. E.g. it also changes the PDU layout! I guess you don't want to force implementers of the new feature to also implement the mircrosoft/DCERPC specific details. I think it's fine if the application chooses to combine them, but the library should not enforce that. metze --------------enigA5CE3EF3782761DCB8500965 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.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3vt00ACgkQm70gjA5TCD/prgCffxSpet6/ZOQ0PfdB0DYIrPr+ f8IAoJoKj5PE5FKdUIwi1XQy/6a753Ja =0arB -----END PGP SIGNATURE----- --------------enigA5CE3EF3782761DCB8500965-- From nico@cryptonector.com Wed Jun 8 14:43:45 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7498111E80A0 for ; Wed, 8 Jun 2011 14:43:45 -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=-1.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hGjjJ7xcDmo for ; Wed, 8 Jun 2011 14:43:44 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id AD88511E809B for ; Wed, 8 Jun 2011 14:43:44 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 78AE72C806B for ; Wed, 8 Jun 2011 14:43:44 -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=f/oNX6T/tTYbDaNcBuTOq QxWwKWN+yBAg/R+M1j4tTcAoqfcsfQ0vPt/m00SrQRgGw4Xenb//DipUq1UY69kk 5MF9p3EWsxnF9iM78mWXu6UrrXJrmfnAwoqEh8xBteKGZOKcw+Pbf1PcsPH3lIQY dVfyA3MAzaY2DvUWpXe9pg= 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=oKRb7TqnA6mqZEfRwXx/ I7CPfE0=; b=DtK2mxtbF2J94tUCuBneiBO8O+ICP5tZsueeiJF7AjZK/sAkXAcg I9fMLD5mFTiNNzQkm93o5+KapeOq705qy3H8Ab/HqZFGZWk63G41q8ExUOlc8tg/ 1Xx/w8cg3CS2osYLaA421vFWTQuxSmQgOh4uRmP92MslKJsnLOK7CYc= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.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 575792C8058 for ; Wed, 8 Jun 2011 14:43:44 -0700 (PDT) Received: by pvh18 with SMTP id 18so490071pvh.31 for ; Wed, 08 Jun 2011 14:43:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.10.9 with SMTP id e9mr1283383pbb.255.1307569424010; Wed, 08 Jun 2011 14:43:44 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 8 Jun 2011 14:43:43 -0700 (PDT) In-Reply-To: <4DEFB74D.5060402@samba.org> References: <4DEEF9BC.4040509@samba.org> <4DEFB74D.5060402@samba.org> Date: Wed, 8 Jun 2011 16:43:43 -0500 Message-ID: From: Nico Williams To: "Stefan (metze) Metzmacher" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating "DCE style" -- a proposal and advice request X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 21:43:45 -0000 On Wed, Jun 8, 2011 at 12:54 PM, Stefan (metze) Metzmacher wrote: > Am 08.06.2011 07:30, schrieb Nico Williams: >> On Jun 7, 2011 11:25 PM, "Stefan (metze) Metzmacher" >>> Please don't imply GSS_C_DCE_STYLE. >> >> Why not? > > Because the new feature should be completely unrelated to GSS_C_DCE_STYLE. Sure it is. Both allow the acceptor to avoid the use of an rcache. One is negotiable, the other is not. > GSS_C_DCE_STYLE has more implications than just the 3 leg handshake. > E.g. it also changes the PDU layout! Hmmm, the non-initial security context tokens are missing the OID header in the DCE style case, and there's changes to the per-message tokens. The latter I can see objecting to. Alright, almost sold; I've to think about this. > I guess you don't want to force implementers of the new feature to also > implement the mircrosoft/DCERPC specific details. They have to anyways. > I think it's fine if the application chooses to combine them, but the > library should > not enforce that. IMO these two options must be mutually exclusive if the new one does not imply the old one. Nico -- From nico@cryptonector.com Wed Jun 8 14:55:20 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA25321F853E for ; Wed, 8 Jun 2011 14:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.144 X-Spam-Level: X-Spam-Status: No, score=-3.144 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXn2B2kSD6dM for ; Wed, 8 Jun 2011 14:55:19 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id DCBB521F853C for ; Wed, 8 Jun 2011 14:55:19 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id B274E67C06B for ; Wed, 8 Jun 2011 14:55:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=X6IOqh+TuLqPkU9Rm5XiL n4Rcy2n76+ftvDrbfuo9PeEBz8RYrABWmjCzwo0fHP5TcZmzfYdZVOYeC4AEN1Ld aLNIhkC954XUyjLmX6Oh3okwlaI/IEupfTbHgZ+VIhuMeIxe/GsMCD4cBUbcRJdJ 0jx6NmVb2j350Q5OfvSMO0= 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=mZ4QCUMYOWuOBr2y4/ct gmJbSkM=; b=tgJN5QRT/Sp/UsgEQmJV5EtNfyLba2I1auU8G2ZHPBhugb7JU0Z/ ILriQdVhY2VqnGQY4gfA7bYx77JRtGR8VgMs9NRBPFURJnR9jKGIRGI7hYdWsAZr TEjYtribS+6eFS7Ku9PLCgE75rLTF5qr0VP1xgY9ub6tTgX7A7WX+6Q= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id A21F467C069 for ; Wed, 8 Jun 2011 14:55:19 -0700 (PDT) Received: by pwi5 with SMTP id 5so493228pwi.31 for ; Wed, 08 Jun 2011 14:55:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.31.135 with SMTP id a7mr1177011pbi.54.1307570119317; Wed, 08 Jun 2011 14:55:19 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 8 Jun 2011 14:55:19 -0700 (PDT) In-Reply-To: References: <4DEEF9BC.4040509@samba.org> <4DEFB74D.5060402@samba.org> Date: Wed, 8 Jun 2011 16:55:19 -0500 Message-ID: From: Nico Williams To: "Stefan (metze) Metzmacher" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating "DCE style" -- a proposal and advice request X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 21:55:20 -0000 On Wed, Jun 8, 2011 at 4:43 PM, Nico Williams wrote: > IMO these two options must be mutually exclusive if the new one does > not imply the old one. I take that back. From metze@samba.org Wed Jun 8 15:08:10 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2021F0C3E for ; Wed, 8 Jun 2011 15:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ixbwk-zr9S8W for ; Wed, 8 Jun 2011 15:08:10 -0700 (PDT) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C421F0C41 for ; Wed, 8 Jun 2011 15:08:08 -0700 (PDT) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwJ7eL6yL6M6h2IziqwDH3E4NCo4U3R/aEd67rXuDEH8iy77xmeucJmD0l1y+exZM= X-RZG-CLASS-ID: mo05 Received: from [IPv6:2001:470:9f11:11f9:abeb:24b4:7dc8:68a2] ([2001:470:9f11:11f9:abeb:24b4:7dc8:68a2]) by post.strato.de (cohen mo14) (RZmta 25.18) with ESMTPA id d0085dn58JaNeM ; Thu, 9 Jun 2011 00:08:02 +0200 (MEST) Message-ID: <4DEFF2BD.80602@samba.org> Date: Thu, 09 Jun 2011 00:07:57 +0200 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nico Williams References: <4DEEF9BC.4040509@samba.org> <4DEFB74D.5060402@samba.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6462CAEEE4B85AA6741F9E60" Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating "DCE style" -- a proposal and advice request X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 22:08:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6462CAEEE4B85AA6741F9E60 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 08.06.2011 23:43, schrieb Nico Williams: > On Wed, Jun 8, 2011 at 12:54 PM, Stefan (metze) Metzmacher > wrote: >> Am 08.06.2011 07:30, schrieb Nico Williams: >>> On Jun 7, 2011 11:25 PM, "Stefan (metze) Metzmacher" >>>> Please don't imply GSS_C_DCE_STYLE. >>> >>> Why not? >> >> Because the new feature should be completely unrelated to GSS_C_DCE_ST= YLE. >=20 > Sure it is. Both allow the acceptor to avoid the use of an rcache. > One is negotiable, the other is not. >=20 >> GSS_C_DCE_STYLE has more implications than just the 3 leg handshake. >> E.g. it also changes the PDU layout! >=20 > Hmmm, the non-initial security context tokens are missing the OID > header in the DCE style case, and there's changes to the per-message > tokens. The latter I can see objecting to. Alright, almost sold; > I've to think about this. >=20 >> I guess you don't want to force implementers of the new feature to als= o >> implement the mircrosoft/DCERPC specific details. >=20 > They have to anyways. No, it's only used exclusive for DCERPC. If someone wants to implement just LDAP, http, SMB, SMTP, IMAP or others it's not needed ( and as far as I remember also not supported by windows). >> I think it's fine if the application chooses to combine them, but the >> library should >> not enforce that. >=20 > IMO these two options must be mutually exclusive if the new one does > not imply the old one. Maybe for one specific session, but I haven't thought about more details.= metze --------------enig6462CAEEE4B85AA6741F9E60 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.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3v8r0ACgkQm70gjA5TCD9BUACgtL95YRd409uayqXwo8ZsiKO5 OUsAoL+umMUluikIgxvzdfekfPLb4CqN =HPnS -----END PGP SIGNATURE----- --------------enig6462CAEEE4B85AA6741F9E60-- From nico@cryptonector.com Wed Jun 8 15:14:30 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F8611E8080 for ; Wed, 8 Jun 2011 15:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.12 X-Spam-Level: X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXCL6n42Xhmt for ; Wed, 8 Jun 2011 15:14:30 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id F077811E8076 for ; Wed, 8 Jun 2011 15:14:29 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 9A13F77805B for ; Wed, 8 Jun 2011 15:14:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=h85CZvD2dw5DJAx0hfrBo SV9ureQymetrXB8Aqfv43xNfcy83Q75M4ft1BgoygDFJis7A5SJCEfordfLincnU 7+XoD1f0C6KboUBSJfZBZKwQ/FFknTqll0fCUPyh+F0LyKg+QXbxa9G/zzV06ANR P/OvPMuFic0+zl/UZGRR7E= 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=6WGy+ai4cL2IEozcZzUk ziM1CTk=; b=Kkek1siKIEiSxDISkuAzCF06zHif/0AmXiNYZtw93LZDSLc5e5ax YETSPnuKZ3x7Z6ov7xoCUH3U3yN6x5UrhtcsiL7dn0ZWE05dRF2mrLs6XBZf6HCk nm027xMYRgm/539z4YccKjkNeg7O7eNXVkmU74w/WG0Q93Bx1TlfzKU= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (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 78B17778057 for ; Wed, 8 Jun 2011 15:14:29 -0700 (PDT) Received: by pzk5 with SMTP id 5so499803pzk.31 for ; Wed, 08 Jun 2011 15:14:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.17.7 with SMTP id k7mr1188004pbd.322.1307571269003; Wed, 08 Jun 2011 15:14:29 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 8 Jun 2011 15:14:28 -0700 (PDT) In-Reply-To: <4DEFF2BD.80602@samba.org> References: <4DEEF9BC.4040509@samba.org> <4DEFB74D.5060402@samba.org> <4DEFF2BD.80602@samba.org> Date: Wed, 8 Jun 2011 17:14:28 -0500 Message-ID: From: Nico Williams To: "Stefan (metze) Metzmacher" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating "DCE style" -- a proposal and advice request X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 22:14:30 -0000 On Wed, Jun 8, 2011 at 5:07 PM, Stefan (metze) Metzmacher wrote: > Am 08.06.2011 23:43, schrieb Nico Williams: >> On Wed, Jun 8, 2011 at 12:54 PM, Stefan (metze) Metzmacher >> wrote: >>> I guess you don't want to force implementers of the new feature to also >>> implement the mircrosoft/DCERPC specific details. >> >> They have to anyways. > > No, it's only used exclusive for DCERPC. > > If someone wants to implement just LDAP, http, SMB, SMTP, IMAP or others > it's not needed ( > and as far as I remember also not supported by windows). Mumble... As a GSS implementor I'd not know what the consumers are -- I'd want to implement this option. OTOH, you've given me enough to convince me, so that's that. >> IMO these two options must be mutually exclusive if the new one does >> not imply the old one. > > Maybe for one specific session, but I haven't thought about more details. They're not mutually exclusive after all, but it makes no sense to use them both -- if you set both then the DCE_STYLE flag wins. Nico -- From nico@cryptonector.com Thu Jun 9 11:29:59 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC1111E81EA for ; Thu, 9 Jun 2011 11:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=-1.096, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svgGXX+G5m7s for ; Thu, 9 Jun 2011 11:29:59 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id D07A611E80F3 for ; Thu, 9 Jun 2011 11:29:58 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 81F971006E for ; Thu, 9 Jun 2011 11:29:58 -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: content-type; q=dns; s=cryptonector.com; b=Z1e+RM1TK0MMQu+V4W/fR /eVxEfvKFbpRTIKnBnwtELhFecZy82DKcmFfoZJofNa9R8eVDHZo2LUuqNzLuxfg KnZGsWqgk1udzUIrjm2rgY8xDJnDWE3FX3AWcmuzuH4Tcra2La3rXdLslvkLGAWF ktqopcEwNIkmtaDRFpEy0Y= 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:content-type; s=cryptonector.com; bh=QhEiyXBrxp5GeLm4mJVSkp0 AXgM=; b=xnid6UUq8/+GF+u/dMb7B+LgK8eZx5VUAQ3rFjipAVzHgi3h3D4pgn4 ptlrn029vnWDuiYnxJRx4CfVglUZhnUe98vyIis+zPdjHUujcseVRZrUBX9VR5UW HaZd7Y3EcCfmcsv0EqkwF2Dmx2wdeQN4zhxwBo2B9MaBZN/884rA= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 6355810062 for ; Thu, 9 Jun 2011 11:29:58 -0700 (PDT) Received: by pwi5 with SMTP id 5so960049pwi.31 for ; Thu, 09 Jun 2011 11:29:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.20.137 with SMTP id n9mr509084pbe.121.1307644198061; Thu, 09 Jun 2011 11:29:58 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Thu, 9 Jun 2011 11:29:58 -0700 (PDT) In-Reply-To: References: <4DEEF9BC.4040509@samba.org> <4DEFB74D.5060402@samba.org> <4DEFF2BD.80602@samba.org> Date: Thu, 9 Jun 2011 13:29:58 -0500 Message-ID: From: Nico Williams To: ietf-krb-wg@anl.gov, kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [kitten] Negotiating "DCE style" -- a proposal and advice request X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 18:29:59 -0000 The most annoying problem so far is making sure that non-GSS kerberos apps don't accept AP-REQs taken from a GSS exchange that's using this three-legged exchange to avoind using the rcache. Getting this right requires a bit of refactoring. And, of course, since there may be multiple krb5 implementations using the same principal name, and not all up to date, this feature has to be configurable, which too is obnoxious. Nico -- From mrex@sap.com Thu Jun 9 15:46:47 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B6311E8102 for ; Thu, 9 Jun 2011 15:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.419 X-Spam-Level: X-Spam-Status: No, score=-9.419 tagged_above=-999 required=5 tests=[AWL=0.830, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkqOqArj+BGR for ; Thu, 9 Jun 2011 15:46:46 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADD211E80F6 for ; Thu, 9 Jun 2011 15:46:45 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p59MkbKT017065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2011 00:46:37 +0200 (MEST) From: Martin Rex Message-Id: <201106092246.p59Mkbfc007916@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Fri, 10 Jun 2011 00:46:37 +0200 (MEST) In-Reply-To: from "Nico Williams" at Jun 8, 11 05:14:28 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] [Ietf-krb-wg] Negotiating "DCE style" -- a proposal X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 22:46:47 -0000 Nico Williams wrote: > > Stefan Metzmacher wrote: > > > > Nico Williams wrote: > > > > > > wrote: > > > > I guess you don't want to force implementers of the new feature > > > > to also implement the mircrosoft/DCERPC specific details. > > > > > > They have to anyways. Are you sure? Myself, I have never tried to use DCE at all or through GSS-API, but the SSPI function CompleteAuthToken, that does not exist in GSS-API, always made me wonder what weird things DCE did (or required from apps): http://msdn.microsoft.com/en-us/library/aa374764%28v=vs.85%29.aspx > > > > No, it's only used exclusive for DCERPC. > > > > If someone wants to implement just LDAP, http, SMB, SMTP, IMAP or others > > it's not needed ( > > and as far as I remember also not supported by windows). > > Mumble... As a GSS implementor I'd not know what the consumers are -- > I'd want to implement this option. OTOH, you've given me enough to > convince me, so that's that. DCE seemed to have died around 1997/1998, from license strangulation. Since the original implementation was basically GSS-API v1 (i.e. no interproces transfer of the security context), is was never really an option for us. -Martin From lukeh@padl.com Thu Jun 9 15:58:58 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780D91F0C51 for ; Thu, 9 Jun 2011 15:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDhd8q3yiorq for ; Thu, 9 Jun 2011 15:58:57 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6F49F1F0C4E for ; Thu, 9 Jun 2011 15:58:57 -0700 (PDT) Received: by us.padl.com with ESMTP id p59MwmSa003766; Thu, 9 Jun 2011 18:58:52 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <201106092246.p59Mkbfc007916@fs4113.wdf.sap.corp> Date: Thu, 9 Jun 2011 22:58:47 +0000 Content-Transfer-Encoding: 7bit Message-Id: <5207900A-5FEC-407A-B8BB-1A9CBA57CC49@padl.com> References: <201106092246.p59Mkbfc007916@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_40,RDNS_DYNAMIC,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -19.9 Cc: ietf-krb-wg@anl.gov, kitten@ietf.org Subject: Re: [kitten] [Ietf-krb-wg] Negotiating "DCE style" -- a proposal X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 22:58:58 -0000 > DCE seemed to have died around 1997/1998, from license strangulation. Whatever. D From lukeh@padl.com Thu Jun 9 16:00:58 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FC51F0C51 for ; Thu, 9 Jun 2011 16:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZufLKH8-wSZ for ; Thu, 9 Jun 2011 16:00:58 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7291F0C3F for ; Thu, 9 Jun 2011 16:00:57 -0700 (PDT) Received: by us.padl.com with ESMTP id p59N0mgH009789; Thu, 9 Jun 2011 19:00:53 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <5207900A-5FEC-407A-B8BB-1A9CBA57CC49@padl.com> Date: Thu, 9 Jun 2011 23:00:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201106092246.p59Mkbfc007916@fs4113.wdf.sap.corp> <5207900A-5FEC-407A-B8BB-1A9CBA57CC49@padl.com> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_20,RDNS_DYNAMIC,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -19.9 Cc: ietf-krb-wg@anl.gov, kitten@ietf.org Subject: Re: [kitten] [Ietf-krb-wg] Negotiating "DCE style" -- a proposal X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 23:00:58 -0000 On 09/06/2011, at 10:58 PM, Luke Howard wrote: >> DCE seemed to have died around 1997/1998, from license strangulation. >=20 > Whatever. D Um, whoops. DCE RPC still underpins Active Directory -- but the rest of = DCE is dead, granted. But note that the authentication mechanism is = quite different to what the OSF implementation did, which was not based = on GSS. Windows uses GSS, with some quirks for Kerberos. -- Luke= From mrex@sap.com Thu Jun 9 17:01:47 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3D421F8584 for ; Thu, 9 Jun 2011 17:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.407 X-Spam-Level: X-Spam-Status: No, score=-9.407 tagged_above=-999 required=5 tests=[AWL=0.842, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwPhxJDJWDqJ for ; Thu, 9 Jun 2011 17:01:46 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 76E5321F8580 for ; Thu, 9 Jun 2011 17:01:46 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p5A01XVl012666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2011 02:01:38 +0200 (MEST) From: Martin Rex Message-Id: <201106100001.p5A01WFg012177@fs4113.wdf.sap.corp> To: lukeh@padl.com (Luke Howard) Date: Fri, 10 Jun 2011 02:01:32 +0200 (MEST) In-Reply-To: from "Luke Howard" at Jun 9, 11 11:00:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ietf-krb-wg@anl.gov, kitten@ietf.org Subject: Re: [kitten] [Ietf-krb-wg] Negotiating "DCE style" -- a proposal X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 00:01:47 -0000 Luke Howard wrote: > > On 09/06/2011, at 10:58 PM, Luke Howard wrote: > > > > > DCE seemed to have died around 1997/1998, from license strangulation. > > DCE RPC still underpins Active Directory -- but the rest of DCE is dead, > granted. But note that the authentication mechanism is quite different > to what the OSF implementation did, which was not based on GSS. > Windows uses GSS, with some quirks for Kerberos. It seems that Microsoft started developing Windows NT when DCE was still assumed to have a bright future on Unix-based servers, but Microsoft was just as much detered from the licensing conditions as pretty much everyone else. But Microsoft did implement some wire-level interop with DCE PDUs, assuming that it might be beneficial to interop with Unix-based servers (at a time when MS-DOS and early MS Windows was for pure end-user machines). >From what I heard, GSS-API was primarily developed by Digital Equipment Coorporation (DEC) for the use in DCE, but some members of the DCE camp frowned upon it because of the performance overhead compared to more traditional APIs. So DEC gave it to the IETF. GSS-API v1 was later retrofitted onto DCE as an alternative API (as of DCE v1.2, I believe). -Martin From lukeh@padl.com Fri Jun 10 01:34:39 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA83E11E80F0 for ; Fri, 10 Jun 2011 01:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSFTt3ZxPcyP for ; Fri, 10 Jun 2011 01:34:39 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id D73D511E80F4 for ; Fri, 10 Jun 2011 01:34:38 -0700 (PDT) Received: by us.padl.com with ESMTP id p5A8YQnx001982; Fri, 10 Jun 2011 04:34:31 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <201106100001.p5A01WFg012177@fs4113.wdf.sap.corp> Date: Fri, 10 Jun 2011 08:34:27 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7BA6079A-839C-4EB0-A803-35DAD0A8B8D8@padl.com> References: <201106100001.p5A01WFg012177@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_DYNAMIC,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.1 Cc: ietf-krb-wg@anl.gov, kitten@ietf.org Subject: Re: [kitten] [Ietf-krb-wg] Negotiating "DCE style" -- a proposal X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 08:34:40 -0000 > It seems that Microsoft started developing Windows NT when DCE was > still assumed to have a bright future on Unix-based servers, > but Microsoft was just as much detered from the licensing conditions > as pretty much everyone else. The protocols were licensed freely. By the time MS was ready to develop = an enterprise directory, they realised (correctly) that CDS and = GDS/X.500 were dead, and modern Kerberos and LDAP were not. > But Microsoft did implement some wire-level interop with DCE PDUs, > assuming that it might be beneficial to interop with Unix-based = servers > (at a time when MS-DOS and early MS Windows was for pure end-user > machines). I suspect it has as much to do with the people they hired as it does = with interop. > =46rom what I heard, GSS-API was primarily developed by Digital = Equipment > Coorporation (DEC) for the use in DCE, but some members of the DCE = camp > frowned upon it because of the performance overhead compared to more > traditional APIs. So DEC gave it to the IETF. GSS-API v1 was later > retrofitted onto DCE as an alternative API (as of DCE v1.2, I = believe). Sounds about right. RPC came from Apollo NCS, FWIW. There's still some NCS-compatibility = stuff in the OSF code (see dcerpc.org). -- Luke= From internet-drafts@ietf.org Tue Jun 14 13:23:47 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6B71F0C56; Tue, 14 Jun 2011 13:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7uL3CN2X2L0; Tue, 14 Jun 2011 13:23:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1C41F0C3C; Tue, 14 Jun 2011 13:23:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110614202345.6994.16730.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2011 13:23:45 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-openid-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 20:23:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next= Generation Working Group of the IETF. Title : A SASL & GSS-API Mechanism for OpenID Author(s) : Eliot Lear Hannes Tschofenig Henry Mauldin Simon Josefsson Filename : draft-ietf-kitten-sasl-openid-03.txt Pages : 26 Date : 2011-06-14 OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-03.txt From simon@josefsson.org Tue Jun 14 13:51:17 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8107228007 for ; Tue, 14 Jun 2011 13:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMRZLvQJYioV for ; Tue, 14 Jun 2011 13:51:17 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id B44F6228005 for ; Tue, 14 Jun 2011 13:51:16 -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 p5EKp8rh028968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 14 Jun 2011 22:51:11 +0200 X-Hashcash: 1:22:110614:kitten@ietf.org::lBPZwYbnBxp+eKDT:S90/ From: Simon Josefsson To: kitten@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Tue, 14 Jun 2011 22:51:08 +0200 Message-ID: <87lix4jfwj.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) 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 Subject: [kitten] Enctype agility in SCRAM? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 20:51:17 -0000 How is the enctype algorithm agility supposed to work in SCRAM? Recall that the SCRAM GSS-API mechanism hard codes the use of "aes128-cts-hmac-sha1-96" for per-message tokens and GSS_Pseudo_random. Let's say someone breaks "aes128-cts-hmac-sha1-96", or we for some reason just wants to use something else. How would this be done? I'm thinking we would need to specify both a new SASL name and a new GSS-API OID for the new mechanism, but unfortunately, this won't be backwards compatible with existing native-SASL implementations of SCRAM. Is there some alternative? If we only change the OID, how would GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname work? /Simon From nico@cryptonector.com Tue Jun 14 15:04:30 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4AC11E80AD for ; Tue, 14 Jun 2011 15:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OVoR7MADJdO for ; Tue, 14 Jun 2011 15:04:29 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id BECDE11E80AC for ; Tue, 14 Jun 2011 15:04:29 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 601BD350072 for ; Tue, 14 Jun 2011 15:04:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Cf1c8Hqw9YR2IDkywrjc1zWTWlWrImVTAXI32f+YtfpI s8G+80suiCFtB2mE2qYclco1hoznBamV5UL69OvRKup4GprAJtisFiO2oSaCecEs poLZ3AK/Eb7pjnf4mqyHGFG9leaOe7xciDtHm9oVLpsS64HWydfEkSeDwNbF7Ho= 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=xl54aDvfr/xfevurkgjYgMMgVIA=; b=H0+ot+CUtZt RHcqnKEet82YHA3eC/TLfXuIyGVkSncrxPB4xcZOiWqn7hkAAH81fQorj9kzMuT8 /uHHsBZ2YTUDCqoHim2jRt3CKnUF5RxcDJaT2gKwq6IXUhMGvKDTHzwqWXVJTZZI /a6VSSdypS8eKwPgW1G+4YrZsE6iTPFc= Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) (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 458C335005B for ; Tue, 14 Jun 2011 15:04:29 -0700 (PDT) Received: by pxi20 with SMTP id 20so4556489pxi.27 for ; Tue, 14 Jun 2011 15:04:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.33 with SMTP id d1mr3359317pbk.389.1308089068929; Tue, 14 Jun 2011 15:04:28 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 14 Jun 2011 15:04:28 -0700 (PDT) In-Reply-To: <87lix4jfwj.fsf@latte.josefsson.org> References: <87lix4jfwj.fsf@latte.josefsson.org> Date: Tue, 14 Jun 2011 17:04:28 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] Enctype agility in SCRAM? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 22:04:31 -0000 On Tue, Jun 14, 2011 at 3:51 PM, Simon Josefsson wrot= e: > How is the enctype algorithm agility supposed to work in SCRAM? > > Recall that the SCRAM GSS-API mechanism hard codes the use of > "aes128-cts-hmac-sha1-96" for per-message tokens and GSS_Pseudo_random. It also uses HMAC-SHA-1 for the security context tokens. If you want a different suite of algorithms then you must assign a new OID (and SASL mech name, if you don't want the hash-of-OID name) to SCRAM with that suite. We explicitly made this choice. > Let's say someone breaks "aes128-cts-hmac-sha1-96", or we for some > reason just wants to use something else. =C2=A0How would this be done? = =C2=A0I'm > thinking we would need to specify both a new SASL name and a new GSS-API > OID for the new mechanism, but unfortunately, this won't be backwards > compatible with existing native-SASL implementations of SCRAM. =C2=A0Is t= here > some alternative? =C2=A0If we only change the OID, how would > GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname work? Adding suite negotiation in the mechanism wouldn't change the fact that to add a new suite is not enough: you must also deploy it widely if you want that suite to be used. And suite negotiation in the mechanism is a form of two-layer negotiation, with all attendant issues. It is important that we avoid it as much as possible (I know, we didn't avoid this in the case of Kerberos, but there we had decades of having done it one way, so we stuck to it). Nico -- From simon@josefsson.org Wed Jun 15 02:27:18 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DAA11E809C for ; Wed, 15 Jun 2011 02:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OA1sl4fCpO96 for ; Wed, 15 Jun 2011 02:27:18 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id AFAC811E80AA for ; Wed, 15 Jun 2011 02:27:17 -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 p5F9QmDG030904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Jun 2011 11:26:50 +0200 From: Simon Josefsson To: Nico Williams References: <87lix4jfwj.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110615:kitten@ietf.org::/SeHK/ciJEzmsB4a:FRD7 X-Hashcash: 1:22:110615:nico@cryptonector.com::Al2zteCdZ72dEY0P:M5v8 Date: Wed, 15 Jun 2011 11:26:48 +0200 In-Reply-To: (Nico Williams's message of "Tue, 14 Jun 2011 17:04:28 -0500") Message-ID: <87lix3igx3.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) 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] Enctype agility in SCRAM? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 09:27:18 -0000 Nico Williams writes: > If you want a different suite of algorithms then you must assign a new > OID (and SASL mech name, if you don't want the hash-of-OID name) to > SCRAM with that suite. We explicitly made this choice. Ok thanks, that resolves my question. I think there would be significant operational problems making this change, but I can't think of any better solution. Part of the problem is that there is no benefit for native-SASL implementers to support the new mech, they will be identical on the SASL-wire. /Simon From klaas@cisco.com Wed Jun 15 06:26:20 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646CB11E8135 for ; Wed, 15 Jun 2011 06:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdNHhaVA0GGo for ; Wed, 15 Jun 2011 06:26:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B909811E812C for ; Wed, 15 Jun 2011 06:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=5794; q=dns/txt; s=iport; t=1308144378; x=1309353978; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Gay3jmv/IsEEJa10lDWfCfJuC0tcCdGRV/2WqeSsHio=; b=MZ6BnCT2qsJ0KnT6ZICDQVTEdv302GCF3vH0yZXzM1dVzwyQwYJuXp65 o5EO3eCpesrt/g403/+mHY6mACF+Z5iGKxyYPo3JYU7meCp67IG14IASE pxpMfzySKKrYraQZYSGFXpi6EhREpJcsq47HehROwKAxMkn+ky3skIgJ5 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFWy+E2Q/khR/2dsb2JhbABFDaZRd4hzn3yePoMagwwEkU6Pcg X-IronPort-AV: E=Sophos;i="4.65,370,1304294400"; d="scan'208";a="94093685" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2011 13:26:17 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5FDQH6F026863; Wed, 15 Jun 2011 13:26:17 GMT Message-ID: <4DF8B2F9.9040001@cisco.com> Date: Wed, 15 Jun 2011 15:26:17 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alexey Melnikov References: <4D94377D.5040508@oracle.com> <4DA0D494.6050304@isode.com> In-Reply-To: <4DA0D494.6050304@isode.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:26:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/9/11 11:50 PM, Alexey Melnikov wrote: Hi Alexey, Finally got around addressing your review comments... Thanks for you comments! See inline. > Shawn M Emery wrote: > >> 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. > > While some of the generic issues are the same for this document and for > the OpenID one, this draft is in a better shape, IMHO. At least I think I processed your review for the OpenID draft and applied when appropriate. > this is actually implementable without relying on some abstract > definition of a browser. > > Below are some specific comments: > > 1. Introduction > > Security Assertion Markup Language (SAML) 2.0 > [OASIS.saml-core-2.0-os] is a modular specification that provides > various means for a user to be identified to a relying party (RP) > through the exchange of (typically signed) assertions issued by an > identity provider (IdP). It includes a number of protocols, protocol > bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles > [OASIS.saml-profiles-2.0-os] designed for different use cases. > > Is any protocol binding mandatory-to-implement for interoperability? added text and reference to Web Browser SSO profile (and to HTTP redirect binding in description) > > The SAML mechanism described in this memo aims to re-use the > available SAML deployment to a maximum extent and therefore does not > establish a separate authentication, integrity and confidentiality > mechanism. The mechanisms assumes a security layer, such as > Transport Layer Security (TLS), to protect against some attacks. > > An Informative reference to TLS is needed here. ack > > 3. Applicability for non-HTTP Use Cases > > 2. The RP sends an HTTP redirect as described in Section 10.3 of > [RFC2616] to the browser to the Identity Provider (IdP) or an IdP > discovery service with an authentication request that contains > the name of resource being requested, some sort of a cookie and a > return URL, > > "URL" needs a reference. ack > > 3. The Relying Party transmits an authentication request encoded > using a Universal Resource Identifier (URI) as described in RFC > 3986 [RFC3986] and a redirect to the IdP corresponding to the > domain > > Is this always an HTTP/HTTPS URI? yes, changed text appropriately > > 7. The IdP will convey information about the success or failure of > the authentication back to the the RP in the form of an > Authentication Statement or failure, using a indirect response > via the client browser or the handler. This step happens out of > band from SASL. > > I think we need a mandatory to implement SAML protocol mapping here, > otherwise this is not really implementable on the server side. I added text to that in the descriptionj of the flow > > Also, the document should be clear that the SASL server (==RP) needs to > be able > to talk HTTP/HTTPS. actually, the SASL server needs to implement full SAML RP capacity, I have added text on that > > Please note: What is described here is the case in which the client > has not previously authenticated. If the client can handle SAML > internally it is possible that the client already holds a valid SAML > authentication token so that the user does not need to be involved in > the process anymore, but that would still be external to SASL. > > Would the client need to talk to RP using an HTTP/HTTPS connection? > I think a bit more details here would help. I added some text, but this is the classical WebSSO case, not specific to SASL-SAML, so I don't want to dwell too much on that. > > > Later in this section: I think an explicit statement about the need to > correlate > the original TCP connection with the SAML authentication is needed. > Also explaining how this is done in the section with an XMPP example > would help as well. ack > > > > 6. Channel Binding > > The "gs2-cb-flag" MUST use "n" because channel binding data cannot be > integrity protected by the SAML negotiation. FIXME: Transfer channel > binding in SAML assertion? > > Yes, this needs to be decided before the document goes to IETF LC. this can afaik not be done today with SAML, but Scott is working on channel binding. I have added some text describing this. > 8.1. Man in the middle and Tunneling Attacks > > This mechanism is vulnerable to man in the middle and tunneling > attacks unless a client always verify the server identity before > proceeding with authentication. Typically TLS is used to provide a > secure channel with server authentication. > > Should this provide some details on TLS server identity verification, > e.g. via an RFC 6125 reference? ack > 10.1. Normative References > > I think this section need a Normative reference to HTTPS. ack Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk34svkACgkQH2Wy/p4XeFJt3wCfUJ2SBWpEmxdC0cVUDFs+6HgD tx0AnAti+gpR8b+ssFVymNe8cjgPfahq =qCtg -----END PGP SIGNATURE----- From internet-drafts@ietf.org Wed Jun 15 06:44:32 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC5B11E8162; Wed, 15 Jun 2011 06:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA+j8YlMw3Xg; Wed, 15 Jun 2011 06:44:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF73A11E814C; Wed, 15 Jun 2011 06:44:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110615134431.4133.97241.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2011 06:44:31 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:44:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next= Generation Working Group of the IETF. Title : A SASL and GSS-API Mechanism for SAML Author(s) : Klaas Wierenga Eliot Lear Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-03.txt Pages : 25 Date : 2011-06-15 Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-03.txt From cantor.2@osu.edu Wed Jun 15 07:02:00 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B809E8011 for ; Wed, 15 Jun 2011 07:02:00 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WosIyfGnJqmN for ; Wed, 15 Jun 2011 07:02:00 -0700 (PDT) Received: from defang2.it.ohio-state.edu (defang2.it.ohio-state.edu [128.146.216.82]) by ietfa.amsl.com (Postfix) with ESMTP id E6F969E800A for ; Wed, 15 Jun 2011 07:01:59 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang2.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p5FE0b1A015324; Wed, 15 Jun 2011 10:01:55 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%11]) with mapi; Wed, 15 Jun 2011 10:00:03 -0400 From: "Cantor, Scott E." To: Klaas Wierenga Thread-Topic: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02 Thread-Index: AQHL73rllNXs9yl9Dk6ScWT87tVCLJS+4HOhgAAJ7IA= Date: Wed, 15 Jun 2011 14:01:05 +0000 Message-ID: In-Reply-To: <4DF8B2F9.9040001@cisco.com> 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: <4fc545e5-0784-4493-8f6e-4d86a5898311> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.82 Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:02:00 -0000 On 6/15/11 9:26 AM, "Klaas Wierenga" wrote: >this can afaik not be done today with SAML, but Scott is working on >channel binding. I have added some text describing this. I haven't thought about it deeply, but I believe you can pull of something involving channel binding in the "use a browser" case if you extend the HTTP Redirect binding between the client and the IdP (you have the client append its CB data to the URL it fires to the browser). However, that obviously won't work with unmodified IdPs. -- Scott From klaas@cisco.com Wed Jun 15 07:07:41 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6001E9E800A for ; Wed, 15 Jun 2011 07:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw3-78Ws73Sz for ; Wed, 15 Jun 2011 07:07:40 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 86C4111E80F0 for ; Wed, 15 Jun 2011 07:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1188; q=dns/txt; s=iport; t=1308146860; x=1309356460; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lIJyEIFd5i07p7neXT0wXDjVdDVpgTNDJbv+nBd/HLw=; b=PqN5qpRJnpg7xZhRabEUt3EQVL1qOw/bZUTqvDMofhnUZn5gdoISkkBt v/lYcR5p+KvoCEE3tvQm4miBgyfmtT4xIY23HEjRqUw6cAX4m5311hl1s hKqjLoUqzD4EeNqN8KbFPkK2rzn1Js5+bgTmhxzZgMzhBUzuAC0Z9l340 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOC7+E2Q/khN/2dsb2JhbABSEKZBd6kjnj+GJgSRTo87Nw X-IronPort-AV: E=Sophos;i="4.65,370,1304294400"; d="scan'208";a="94101269" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2011 14:07:37 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5FE7bhU017103; Wed, 15 Jun 2011 14:07:37 GMT Message-ID: <4DF8BCA9.5090805@cisco.com> Date: Wed, 15 Jun 2011 16:07:37 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Cantor, Scott E." References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:07:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/15/11 4:01 PM, Cantor, Scott E. wrote: > On 6/15/11 9:26 AM, "Klaas Wierenga" wrote: >> this can afaik not be done today with SAML, but Scott is working on >> channel binding. I have added some text describing this. > > I haven't thought about it deeply, but I believe you can pull of something > involving channel binding in the "use a browser" case if you extend the > HTTP Redirect binding between the client and the IdP (you have the client > append its CB data to the URL it fires to the browser). However, that > obviously won't work with unmodified IdPs. right, I wrote in the draft: "Note: In theory channel binding data could be inserted in the SAML flow by the client and verified by the server, but that is currently not supported in SAML." That seems to be the same thing you have in mind, right? Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk34vKkACgkQH2Wy/p4XeFKnfgCgiv9hYvt3k6RPsjtQxPTDSdRX zUMAn0tJXTcHXuKq7kfrgSaFlM9nbZWK =cUCZ -----END PGP SIGNATURE----- From cantor.2@osu.edu Wed Jun 15 07:26:21 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A4411E8128 for ; Wed, 15 Jun 2011 07:26:21 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0-vBMO59Z2N for ; Wed, 15 Jun 2011 07:26:21 -0700 (PDT) Received: from defang8.it.ohio-state.edu (defang8.it.ohio-state.edu [128.146.216.89]) by ietfa.amsl.com (Postfix) with ESMTP id 38F8C11E8141 for ; Wed, 15 Jun 2011 07:26:21 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang8.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p5FEQF56021170; Wed, 15 Jun 2011 10:26:18 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::dde8:9609:5365:c6f3%11]) with mapi; Wed, 15 Jun 2011 10:24:56 -0400 From: "Cantor, Scott E." To: Klaas Wierenga Thread-Topic: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02 Thread-Index: AQHL73rllNXs9yl9Dk6ScWT87tVCLJS+4HOhgAAJ7ICAAETigP//whIA Date: Wed, 15 Jun 2011 14:25:58 +0000 Message-ID: In-Reply-To: <4DF8BCA9.5090805@cisco.com> 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: <1354cb3e-123f-4f74-87aa-90340bcd4b15> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.89 Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:26:22 -0000 On 6/15/11 10:07 AM, "Klaas Wierenga" wrote: >"Note: In theory channel binding data could be inserted in the SAML >flow by the client and verified by the server, but that is currently >not supported in SAML." >That seems to be the same thing you have in mind, right? Yes. I guess its semantics, but if I can define extensions in the manner expected by the standard to do something, I think it's supported. Defining new bindings and protocol extensions are compatible with the existing profiles. -- Scott From klaas@cisco.com Wed Jun 15 07:41:25 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0593821F854C for ; Wed, 15 Jun 2011 07:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syL0y79-631V for ; Wed, 15 Jun 2011 07:41:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 09DCE21F8547 for ; Wed, 15 Jun 2011 07:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1175; q=dns/txt; s=iport; t=1308148884; x=1309358484; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OJafMuCynLGmDE3i7499Z/8GpNtYzo+x+CM5olGz41o=; b=U2trUPt7kAz/1QQvXEvfMyBUbTejZRje5uzHIb1p9vTYL5SmcGJvj692 L3ZV3wF8m1FSP0+f7rlc/pMTBoqCYaLecZnYnoJsP0CE71Uz3YCQIqqkS SZ88K+EIm3L4TP6Zxfqm4X54HmI39fERAJ+5kTGleQaDIguRHQneLxPtx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABTE+E2Q/khN/2dsb2JhbABSEKZBd6k2nkCGJgSRTo87Nw X-IronPort-AV: E=Sophos;i="4.65,370,1304294400"; d="scan'208";a="94107556" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2011 14:41:21 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5FEfK5e025566; Wed, 15 Jun 2011 14:41:21 GMT Message-ID: <4DF8C490.5050704@cisco.com> Date: Wed, 15 Jun 2011 16:41:20 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Cantor, Scott E." References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:41:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/15/11 4:25 PM, Cantor, Scott E. wrote: > On 6/15/11 10:07 AM, "Klaas Wierenga" wrote: >> "Note: In theory channel binding data could be inserted in the SAML >> flow by the client and verified by the server, but that is currently >> not supported in SAML." > >> That seems to be the same thing you have in mind, right? > > Yes. I guess its semantics, but if I can define extensions in the manner > expected by the standard to do something, I think it's supported. Defining > new bindings and protocol extensions are compatible with the existing > profiles. right, what I meant to say is that there is currently no defined method to carry whatever extra information is passed in the URL to the IdP back to the RP. But there is no reason why you couldn't define what the IdP should do with that blob. Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk34xJAACgkQH2Wy/p4XeFIpYACgrIB3ypaApqMY0pd6Nl1qCezg wzkAoK8WNt4Sxo0di86SVBtffZIIfHU5 =jk/g -----END PGP SIGNATURE----- From cantor.2@osu.edu Wed Jun 15 07:45:25 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F2021F8568 for ; Wed, 15 Jun 2011 07:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehs1yG7qTWM0 for ; Wed, 15 Jun 2011 07:45:25 -0700 (PDT) Received: from defang16.it.ohio-state.edu (defang16.it.ohio-state.edu [128.146.216.130]) by ietfa.amsl.com (Postfix) with ESMTP id 38A4921F8570 for ; Wed, 15 Jun 2011 07:45:13 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang16.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p5FEj9IG016662; Wed, 15 Jun 2011 10:45:09 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::dde8:9609:5365:c6f3%11]) with mapi; Wed, 15 Jun 2011 10:44:02 -0400 From: "Cantor, Scott E." To: Klaas Wierenga Thread-Topic: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02 Thread-Index: AQHL73rllNXs9yl9Dk6ScWT87tVCLJS+4HOhgAAJ7ICAAETigP//whIAgABHWQD//738gA== Date: Wed, 15 Jun 2011 14:45:03 +0000 Message-ID: In-Reply-To: <4DF8C490.5050704@cisco.com> 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: <2a26e1df-fc1a-479d-9c99-4c6da2b0403a> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.130 Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:45:26 -0000 On 6/15/11 10:41 AM, "Klaas Wierenga" wrote: >right, what I meant to say is that there is currently no defined method >to carry whatever extra information is passed in the URL to the IdP back >to the RP. But there is no reason why you couldn't define what the IdP >should do with that blob. Technically sending the CB back to the RP isn't a requirement, but the same syntax used to carry it from the RP to the IdP is defined for use in the other direction in SAML Advice. The part that's slightly broken is that I isolated the CB type from the data, not understanding that in most cases it's munged together and opaque to the GSS mechanism. I'll have an updated draft fairly soon I hope. -- Scott From alexey.melnikov@isode.com Sun Jun 19 07:43:58 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CEF11E8091 for ; Sun, 19 Jun 2011 07:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.325 X-Spam-Level: X-Spam-Status: No, score=-102.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4bPZw9fveLw for ; Sun, 19 Jun 2011 07:43:57 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD2211E8075 for ; Sun, 19 Jun 2011 07:43:57 -0700 (PDT) Received: from [188.29.231.218] (188.29.231.218.threembb.co.uk [188.29.231.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 19 Jun 2011 15:43:54 +0100 Message-ID: <4DFE0B13.8040106@isode.com> Date: Sun, 19 Jun 2011 15:43:31 +0100 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 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------030205090708000605010807" Subject: [kitten] "Negotiating "DCE style"" - accept as a WG item X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 14:43:58 -0000 This is a multi-part message in MIME format. --------------030205090708000605010807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit It is not very clear to chairs from the discussion whether there is no interest in this work item as a WG item, whether there is silent support for doing it, or silent dislike for it. So I would appreciate hearing some explicit +1/-1. Feel free to send them directly to me and not to the mailing list. Best Regards, Alexey, as a Kitten co-chair. --------------030205090708000605010807 Content-Type: message/rfc822; name="[kitten] Negotiating \"DCE style\" -- a proposal and advice request" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="[kitten] Negotiating \"DCE style\" -- a proposal and advice request" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by imap.isode.net (Isode M-Box/15.0v0) with LMTP; Wed, 08 Jun 2011 02:53:46 +0400 (MSD) Received: from mail.ietf.org ([64.170.98.30]) by rufus.isode.com (smtp external) via TCP with ESMTP id ; Tue, 7 Jun 2011 23:53:45 +0100 X-SPF-Result: PASS rufus.isode.com: domain of ietf.org designates 64.170.98.30 as permitted sender Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0011511E81C8; Tue, 7 Jun 2011 15:53:43 -0700 (PDT) X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA85C11E81AE for ; Tue, 7 Jun 2011 15:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.068 X-Spam-Level: X-Spam-Status: No, score=-3.068 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXy2wFPjz+J4 for ; Tue, 7 Jun 2011 15:53:42 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 4B31811E80CF for ; Tue, 7 Jun 2011 15:53:42 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 1BA262C806B for ; Tue, 7 Jun 2011 15:53:42 -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=QIcEHTkPxsxU+P3j6hhAEz+3qKFplelXRD3Qzrj4qo+B 4B7mgiKloz6iJcQdJduzUNg+wv7xyt9rJl8JvmkYhflpL3Ol2CLA4Wi/VJ6x19M4 ndwexBGV7eogQSi0W5LZOgf15KFosMrH7BCGFCekdmiPB4gquQ3Txi4ttm9g/xw= 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=G10RMlCgVsYHTwgK3jaDyaroCeo=; b=kLInttaoW1d E6QZ2m14Ede8Q6eflI1/u7IhjiZ+ClLr8n3tsQeuKn9lScfWKagZo+9xPReXFFXH o4hHvlcRDLc0QRQ1rmuBmvwxffKiyC4rGQqlGs50vNqZp9kG8/tCFUPYEftEOVsh d0lc8OsqVg91zGejvRXzo8wHiTL1Qm5A= Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) (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 01E212C8057 for ; Tue, 7 Jun 2011 15:53:41 -0700 (PDT) Received: by pxi20 with SMTP id 20so4583691pxi.27 for ; Tue, 07 Jun 2011 15:53:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.103 with SMTP id o7mr467266pbc.523.1307487221692; Tue, 07 Jun 2011 15:53:41 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 7 Jun 2011 15:53:41 -0700 (PDT) Date: Tue, 7 Jun 2011 17:53:41 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: [kitten] Negotiating "DCE style" -- a proposal and advice request X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org I've a proposal to make, but I need advice. The proposal is: - add a new GSS req_flag: GSS_C_DCE_STYLE_OK (possibly with a nicer name; suggestions?); - [optional] add a authz-data element to use in Authenticator to serve the same purpose as GSS_C_DCE_STYLE_OK, for non-GSS apps; - add a field or more to EncAPRepPart; acceptors/servers would only use the EncAPRepPart extension when the GSS_C_DCE_STYLE_OK (or authz-data element) is present in the initiator/client's AP-REQ's Authenticator. I need advice on the following: a) What better flag name might there be instead of GSS_C_DCE_STYLE_OK? E.g., GSS_C_EXTRA_TOKENS_OK? GSS_C_NEGO_REPLAY_CACHE_AVOIDANCE? GSS_C_NO_RCACHE_OK? b) What to add to EncAPRepPart? And should we add a new SEQUENCE named something like EncAPRepPartExt? I was thinking of adding authorization data to EncAPRepPart, like so: EncAPRepPart ::= [APPLICATION 27] SEQUENCE { ctime[0] KerberosTime, cusec[1] krb5int32, subkey[2] EncryptionKey OPTIONAL, seq-number[3] krb5uint32 OPTIONAL, authorization-data[4] AuthorizationData OPTIONAL, ... } And there would also be a new authorization-data type by which the server would indicate that it understood the GSS_C_DCE_STYLE_OK flag and awaits one more token from the initiator. Is this OK? Would folks prefer a typed hole for anything *other* than authorization data here? My opinion is that we already overload authorization-data, and we're going to do much more of it in the future, plus we are likely to want to have a way for the acceptor to send some authorization data to the initiator, plus symmetry is good when we can have it. Nico -- _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten --------------030205090708000605010807-- From nico@cryptonector.com Mon Jun 20 12:34:37 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC8111E81FC for ; Mon, 20 Jun 2011 12:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVA92U2s3Dpb for ; Mon, 20 Jun 2011 12:34:36 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5E73311E81F6 for ; Mon, 20 Jun 2011 12:34:36 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 0C90359405E for ; Mon, 20 Jun 2011 12:34:36 -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=iM6gxcrBYVuaI1R2UG0ml udKYSARLoUIi95gRJW+CcKJtHceoErvb030IynHzciUu0GjfxYAhOThuG5A0tpgT BMVXDsxb6zXLMgxwpr/RS5Ey8J7SsrhvYGz0ud/i1qqBmderqbQHvblGuncTKFD2 z4PZBB4WzphoDu7D55Oohc= 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=DoTCXfQFuUBBYuEMUtiF iEKvjoY=; b=L8d8kkQSmytjs0FUDlc/5XQIBKCUWVSL/ExdVGgSeqnRA2H0MtSx 1tsoQdRqvEOt5wdM1/yf/kRhKPbMuc+3FIoGLBBVHQcQXDjP2d+oLZAhC2MxWRV9 4g2CFvpGMXNzB/qOCcd53m/3rvcuRnjiQb344ThHwRhE0RjJQ1Lnoqc= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id DF85B594058 for ; Mon, 20 Jun 2011 12:34:35 -0700 (PDT) Received: by pzk5 with SMTP id 5so4241819pzk.31 for ; Mon, 20 Jun 2011 12:34:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.18.162 with SMTP id x2mr2427302pbd.274.1308598475508; Mon, 20 Jun 2011 12:34:35 -0700 (PDT) Received: by 10.68.41.167 with HTTP; Mon, 20 Jun 2011 12:34:35 -0700 (PDT) In-Reply-To: <4DFE0B13.8040106@isode.com> References: <4DFE0B13.8040106@isode.com> Date: Mon, 20 Jun 2011 14:34:35 -0500 Message-ID: From: Nico Williams To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] "Negotiating "DCE style"" - accept as a WG item X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 19:34:37 -0000 On Sun, Jun 19, 2011 at 9:43 AM, Alexey Melnikov wrote: > It is not very clear to chairs from the discussion whether there is no > interest in this work item as a WG item, whether there is silent support for > doing it, or silent dislike for it. > > So I would appreciate hearing some explicit +1/-1. Feel free to send them > directly to me and not to the mailing list. There has been plenty of discussion. No one has spoken in opposition to this (one person spoke in opposition to one particular design, but not in opposition to the feature as such). That's not enough, I realize. I would like to see some +1s. If not, that's OK, I'll just pursue the individual submission track -- but I think this needs to be reviewed here. Nico -- From ghudson@mit.edu Mon Jun 20 13:42:48 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB3511E8163 for ; Mon, 20 Jun 2011 13:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhctndGrmo4K for ; Mon, 20 Jun 2011 13:42:46 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 124D011E815B for ; Mon, 20 Jun 2011 13:42:45 -0700 (PDT) X-AuditID: 1209190c-b7c65ae00000117c-07-4dffb0cb0469 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 38.B8.04476.BC0BFFD4; Mon, 20 Jun 2011 16:42:51 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p5KKghJU031659; Mon, 20 Jun 2011 16:42:43 -0400 Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p5KKgf2O003170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Jun 2011 16:42:43 -0400 (EDT) From: Greg Hudson To: Nico Williams In-Reply-To: References: <4DFE0B13.8040106@isode.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 20 Jun 2011 16:42:40 -0400 Message-ID: <1308602560.19355.21.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hTV1j294b+vwe0+EYujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4MpY33WJveAeS8XDr++YGxgfM3cxcnJICJhI /Fn4kwnCFpO4cG89WxcjF4eQwD5GiePnvjBDOBsYJf5fWccI4dxjkpjUc5kVpEVYwFXi4fcn YO1sAsoSB89+YwGxRQQ0Ja7PW8oGYjMLqEscfd4EZnMKOEosPvoKrFdIIEHi7tRtjBA1mhKt 23+zg9gsAqoSO/f/AavhFdCR+Pb+GNB8DiBbUOLvDmGIS6UlZvf8Y4JolZfY/nYO8wRGwVlI Js1C6JiFpGoBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXUO93MwSvdSU0k2M4PCV5NnB+Oag 0iFGAQ5GJR7entL/vkKsiWXFlbmHGCU5mJREeSvXA4X4kvJTKjMSizPii0pzUosPMUpwMCuJ 8MY//ucrxJuSWFmVWpQPk5LmYFES5y33BmoTSE8sSc1OTS1ILYLJynBwKEnwygLjVEiwKDU9 tSItM6cEIc3EwQkynAdouARIDW9xQWJucWY6RP4Uoy7H26VvDjEKseTl56VKifO+A7lOAKQo ozQPbg4s7bxiFAd6S5hXCmQUDzBlwU16BbSECWjJ/1cgHxSXJCKkpBoYfb9ufnTMt2ZGZtPF 3/+nMjY03tbwOvnws2FAyLyqh5Lyc/6oXklZ1DY/K/O1f3gu943lshOzV3mHZF/2aZoSuE3D /P7vWr1JDWszv99UWB+76+PirdfvbD8uKdOrZrdc43Lk1JLTrc8nX5xxfKvZNy8xk/9Ru7Uy jz02vnpy1fmNIi9n3TXe/V6JpTgj0VCLuag4EQDfvQYGFgMAAA== Cc: "kitten@ietf.org" Subject: Re: [kitten] "Negotiating "DCE style"" - accept as a WG item X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 20:42:48 -0000 On Mon, 2011-06-20 at 15:34 -0400, Nico Williams wrote: > There has been plenty of discussion. No one has spoken in opposition > to this (one person spoke in opposition to one particular design, but > not in opposition to the feature as such). I'm definitely interested in ways to make replay caches unnecessary with Kerberos. There are a lot of design issues which make it hard for me to confidently comment on whether Nico's approach is the right one (or if there even is a viable approach). That plus being generally busy is why I've been quiet in the most recent round of discussion. From alexey.melnikov@isode.com Mon Jun 20 13:49:15 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A6D11E8165 for ; Mon, 20 Jun 2011 13:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.258 X-Spam-Level: X-Spam-Status: No, score=-102.258 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCxy+4OeSqbj for ; Mon, 20 Jun 2011 13:49:14 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7094A11E811D for ; Mon, 20 Jun 2011 13:49:14 -0700 (PDT) Received: from [188.28.254.65] (188.28.254.65.threembb.co.uk [188.28.254.65]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 20 Jun 2011 21:49:12 +0100 Message-ID: <4DFFB233.1080207@isode.com> Date: Mon, 20 Jun 2011 21:48:51 +0100 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: Greg Hudson References: <4DFE0B13.8040106@isode.com> <1308602560.19355.21.camel@t410> In-Reply-To: <1308602560.19355.21.camel@t410> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] "Negotiating "DCE style"" - accept as a WG item X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 20:49:15 -0000 Hi Greg, Greg Hudson wrote: >On Mon, 2011-06-20 at 15:34 -0400, Nico Williams wrote: > > >>There has been plenty of discussion. No one has spoken in opposition >>to this (one person spoke in opposition to one particular design, but >>not in opposition to the feature as such). >> >> >I'm definitely interested in ways to make replay caches unnecessary with >Kerberos. There are a lot of design issues which make it hard for me to >confidently comment on whether Nico's approach is the right one (or if >there even is a viable approach). That plus being generally busy is why >I've been quiet in the most recent round of discussion. > > The WG doesn't have to implement Nico's proposal as is. The WG just needs to decide if it is willing to do the work. So I will count you as "+1". From nico@cryptonector.com Mon Jun 20 13:54:06 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6181011E81D8 for ; Mon, 20 Jun 2011 13:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9i+fwzwW4zS for ; Mon, 20 Jun 2011 13:54:05 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8B79B11E81A2 for ; Mon, 20 Jun 2011 13:54:05 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 536AB674078 for ; Mon, 20 Jun 2011 13:54: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=D6LjiOobmQoL5R+by1qFmCFSoSnaVTddVnM24Szb7ai3 5L/wab5QXwvCzqu8RTBKJX3PAJcoPIYiXnDLTtgh4wPLah5vfaeiY+EbWVj62Csy EkUt3N+8DXT4J9CXhapK8kOF4myvs6t6uTmcNIC14FChlgQGBt+nvfKD6BnfUfA= 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=zX5C98CfsbPohNIktVt+ZhsTFg0=; b=tWOHiPVY6aV /pru19Gk9w6UGXYY2ta8ejAWiyuL0C0g3nx1Rv1j3G6KLcRrMiDP/klDFSUy/CEA Co7SpfM8X9IbpfTQvmEv6NYy5NbuEdrRiTDS04FeKJMd+UXPto5uYF+TbXnODLqh ma65cOyRDUr+jokVXYzOhDrYPuBR2od0= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (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 3A812674074 for ; Mon, 20 Jun 2011 13:54:05 -0700 (PDT) Received: by pvh18 with SMTP id 18so4333177pvh.31 for ; Mon, 20 Jun 2011 13:54:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.1.137 with SMTP id 9mr2405037pbm.475.1308602962573; Mon, 20 Jun 2011 13:49:22 -0700 (PDT) Received: by 10.68.41.167 with HTTP; Mon, 20 Jun 2011 13:49:22 -0700 (PDT) In-Reply-To: <1308602560.19355.21.camel@t410> References: <4DFE0B13.8040106@isode.com> <1308602560.19355.21.camel@t410> Date: Mon, 20 Jun 2011 15:49:22 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] "Negotiating "DCE style"" - accept as a WG item X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 20:54:06 -0000 On Mon, Jun 20, 2011 at 3:42 PM, Greg Hudson wrote: > On Mon, 2011-06-20 at 15:34 -0400, Nico Williams wrote: >> There has been plenty of discussion. =C2=A0No one has spoken in oppositi= on >> to this (one person spoke in opposition to one particular design, but >> not in opposition to the feature as such). > > I'm definitely interested in ways to make replay caches unnecessary with > Kerberos. =C2=A0There are a lot of design issues which make it hard for m= e to > confidently comment on whether Nico's approach is the right one (or if > there even is a viable approach). =C2=A0That plus being generally busy is= why > I've been quiet in the most recent round of discussion. There's no way to avoid a replay cache or out-of-band communications in a one-round-trip mechanism. Anyways, I'd be happy with making this work item broader to cover more possible designs if you like. From hbhotz@dslextreme.com Mon Jun 20 18:27:08 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2307D21F84FE for ; Mon, 20 Jun 2011 18:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96nEJORHT0wd for ; Mon, 20 Jun 2011 18:27:07 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA55021F84FC for ; Mon, 20 Jun 2011 18:27:07 -0700 (PDT) Received: by pvh18 with SMTP id 18so4446743pvh.31 for ; Mon, 20 Jun 2011 18:27:07 -0700 (PDT) Received: by 10.68.43.233 with SMTP id z9mr2797775pbl.211.1308619627278; Mon, 20 Jun 2011 18:27:07 -0700 (PDT) Received: from dhcp-128-149-92-248.jpl.nasa.gov (dhcp-128-149-92-248.jpl.nasa.gov [128.149.92.248]) by mx.google.com with ESMTPS id m9sm3372985pbd.39.2011.06.20.18.27.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2011 18:27:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <4DFE0B13.8040106@isode.com> Date: Mon, 20 Jun 2011 18:27:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DFE0B13.8040106@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: kitten@ietf.org Subject: Re: [kitten] "Negotiating "DCE style"" - accept as a WG item X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Henry B. Hotz" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 01:27:08 -0000 +1 for the problem in general. Have not read and therefore cannot = comment on Nico's specific proposal. On Jun 19, 2011, at 7:43 AM, Alexey Melnikov wrote: > It is not very clear to chairs from the discussion whether there is no = interest in this work item as a WG item, whether there is silent support = for doing it, or silent dislike for it. >=20 > So I would appreciate hearing some explicit +1/-1. Feel free to send = them directly to me and not to the mailing list. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From wwwrun@ietfa.amsl.com Tue Jun 28 09:34:11 2011 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id BE322228006; Tue, 28 Jun 2011 09:34:11 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110628163411.BE322228006@ietfa.amsl.com> Date: Tue, 28 Jun 2011 09:34:11 -0700 (PDT) Cc: kitten@ietf.org Subject: [kitten] WG Action: RECHARTER: Common Authentication Technology Next Generation (kitten) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 16:34:11 -0000 The Common Authentication Technology Next Generation (kitten) working group in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Common Authentication Technology Next Generation (kitten) --------------------------------------------------- Current Status: Active Working Group Chairs: Alexey Melnikov Tom Yu Shawn Emery Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Stephen Farrell Mailing Lists: General Discussion: kitten@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/kitten Archive: http://www.ietf.org/mail-archive/web/kitten/ Description of Working Group: The Generic Security Services (GSS) API and Simple Authentication and Security Layer (SASL) provide various applications with a security framework for secure network communication. The purpose of the Common Authentication Technology Next Generation (Kitten) working group (WG) is to develop extensions/improvements to the GSS-API, shepherd specific GSS-API security mechanisms, and provide guidance for any new SASL- related submissions. This working is chartered to specify the following extensions and improvements (draft-yu-kitten-api-wishlist-00) to the GSS-API: * Provide new interfaces for credential management, which include the following: initializing credentials iterating credentials exporting/importing credentials * Specify interface for asynchronous calls. * Negotiable replay cache avoidance * Define interfaces for better error message reporting. * Provide a more programmer friendly GSS-API for application developers. This could include reducing the number of interface parameters, for example, by eliminating parameters which are commonly used with the default values. * Specify an option for exporting partially-established security contexts and possibly a utility function for exporting security contexts in an encrypted form, as well as a corresponding utility function to decrypt and import such security context tokens. This WG is also chartered to finalize proposed SASL mechanisms as GSS-API mechanisms (based on RFC 5801): * A SASL Mechanism for OpenID draft-ietf-kitten-sasl-openid * SASL Mechanisms for SAML: draft-ietf-kitten-sasl-saml draft-cantor-ietf-kitten-saml-ec The SAML mechanism drafts will include applicability statement text to highlight when each is appropriate for use. * A SASL Mechanism for OAuth draft-mills-kitten-sasl-oauth The transition from SASL to GSS-API mechanisms will allow a greater set of applications to utilize said mechanisms with SASL implementations that support the use of GSS-API mechanisms in SASL (RFC 5801). This WG should review proposals for new SASL and GSS-API mechanisms, but may take on work on such mechanisms only through a revision of this charter. The WG should also review non-mechanism proposals related to SASL and the GSS-API. However, work that adds SASL or GSS-API support in application protocols is out of scope and should be handled by the corresponding application's WG. Deliverables: * GSS-API: initializing credentials * GSS-API: iterating credentials * GSS-API: exporting/importing credentials * GSS-API: specification for asynchronous calls * GSS-API: interfaces/improvements for better error message reporting * GSS-API: programmer friendly interfaces * SASL: SASL mechanism for OpenID * SASL: SASL mechanisms for SAML * SASL: SASL mechanism for OAuth * GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana Goals and Milestones: Jul 2011 Submit SASL OpenID mechanism to the IESG as Proposed Standard Jul 2011 Submit naming-exts to the IESG as Proposed Standard Jul 2011 WGLC on gssapi-extensions-iana Aug 2011 Submit SASL SAML mechanisms to the IESG as Proposed Standard Sep 2011 Submit gssapi-extensions-iana to the IESG as Proposed Standard Oct 2011 Submit SASL OAuth mechanism to the IESG as Proposed Standard