From kitten-bounces@lists.ietf.org Wed Jan 03 14:49:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2C7A-0000vQ-3L; Wed, 03 Jan 2007 14:49:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2C78-0000v7-Vi for kitten@ietf.org; Wed, 03 Jan 2007 14:49:30 -0500 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2C77-0002zV-QC for kitten@ietf.org; Wed, 03 Jan 2007 14:49:30 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5CD12E00B4; Wed, 3 Jan 2007 14:49:20 -0500 (EST) From: Sam Hartman To: kitten@ietf.org Date: Wed, 03 Jan 2007 14:49:20 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: Adding security considerations text to draft-ietf-kitten-gssapi-domain-based-names X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org In order to resolve Tom Yu's security directorate review we're proposing the following additional security considerations text. Please scream if you have any objections. "Note that, as with all service names, the mere existence of a domain-based service name conveys meaningful information that may be used by initiators for making authorization decisions; therefore, administrators of distributed authentication services should be aware of the significance of the service names for which they create acceptor credentials." _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jan 03 20:29:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HPQ-0002Kp-JO; Wed, 03 Jan 2007 20:28:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HPP-0002FC-KL; Wed, 03 Jan 2007 20:28:43 -0500 Received: from stratton-one-sixteen.mit.edu ([18.187.5.116] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2HPO-0007yP-EN; Wed, 03 Jan 2007 20:28:43 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 52D54E00B4; Wed, 3 Jan 2007 20:28:42 -0500 (EST) To: saag@mit.edu From: Sam Hartman Message-Id: <20070104012842.52D54E00B4@carter-zimmerman.mit.edu> Date: Wed, 3 Jan 2007 20:28:42 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: kitten@ietf.org, ietf-sasl@imc.org, tls@ietf.org Subject: Writing Help with draft-williams-on-channel-binding X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org There was a lively discussion here of draft-williams-on-channel-binding. After revising the draft based on comments received, Nico has submitted it for publication. I've sent him some minor AD review comments; once he addresses them I think the document will be ready for last call. However, I think we could make it significantly better. The problem is that several of us have been thinking about channel binding for the last couple of years. We've got it stuck in our minds. The current draft speaks well to what we're looking for. However it isn't as good of an introduction to the concept as it could be. It does a good job of specifying requirements for channel binding values and mechanisms that use channel binding. Is there someone out there who is a reasonably good writer but who has not been heavily involved in the channel binding discussion who would be willing to commit some significant time over the next month or so to understand and improve the draft? If you would be interested please let Nico and I know. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jan 03 20:46:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HgC-0003WR-Qv; Wed, 03 Jan 2007 20:46:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HgB-0003WE-Ib for kitten@ietf.org; Wed, 03 Jan 2007 20:46:03 -0500 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2HgA-0001m0-9L for kitten@ietf.org; Wed, 03 Jan 2007 20:46:03 -0500 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l041k1km009181; Wed, 3 Jan 2007 20:46:01 -0500 (EST) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l041k0bi028769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Jan 2007 20:46:00 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id l041k0Lu010701; Wed, 3 Jan 2007 20:46:00 -0500 (EST) To: Sam Hartman References: From: Tom Yu Date: Wed, 03 Jan 2007 20:46:00 -0500 In-Reply-To: (Sam Hartman's message of "Wed, 03 Jan 2007 14:49:20 -0500") Message-ID: Lines: 37 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: kitten@ietf.org Subject: Re: Adding security considerations text to draft-ietf-kitten-gssapi-domain-based-names X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org An alternative which I prefer is the following: "With all service names, the mere existence of service name conveys meaningful information that may be used by initiators for making authorization decisions. Domain-based service names make stronger authorization assertions than do simple host-based service names; therefore, administrators of distributed authentication services should be aware of the significance of the service names for which they create acceptor credentials." I think it makes somewhat more clear that there is a qualitative change in the responsibilities of the administrators of the authentication infrastructure when domain-based service names become deployed. Quoting some prior private discussion: >>>>> "Sam" == Sam Hartman writes: Sam> Today MIT is very happy to hand out host, rvdsrv (don't ask), Sam> daemon , discuss and a few other principals to anyone who can Sam> demonstrate that they run a host. The assumption is that having Sam> such a principal doesn't say anything about the overall mit.edu Sam> namespace; it is simply a service running on that host. Sam> The first time you introduce a service whose clients expect the Sam> service to be domain-wide, you need to make a new decision when Sam> handing out a a key: is this principal allowed to speak for the Sam> entire namespace. It may be the case that ldap in current client Sam> implementations actually already works this way even without the Sam> domain based names draft. But host and a number of other Sam> services definitely do not. The first time you add a domain Sam> based service, you take on a new responsibility in namespace Sam> management. Previously you needed to ask whether you were giving Sam> a key to the person responsible for the machine on which it runs. Sam> You still need to ask that, but you also need to ask whether that Sam> machine is allowed to represent the entire domain. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten