From spkm-bounces@ietf.org Tue Oct 03 11:37:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmKZ-0007bW-1t; Tue, 03 Oct 2006 11:37:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmGf-0004w5-Pw; Tue, 03 Oct 2006 11:33:13 -0400 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmGe-00005Q-Aj; Tue, 03 Oct 2006 11:33:13 -0400 Received: from [141.211.133.26] (yoga.citi.umich.edu [141.211.133.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "aglo", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id E28F71BDE1; Tue, 3 Oct 2006 11:33:09 -0400 (EDT) Message-ID: <452282B5.7000708@citi.umich.edu> Date: Tue, 03 Oct 2006 11:33:09 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: saag@mit.edu, kitten@ietf.org, nfsv4@ietf.org, tls@lists.ietf.org, ietf-pkix@imc.org, spkm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Tue, 03 Oct 2006 11:37:14 -0400 Cc: Subject: [SPKM] [67th IETF] SPKM3 BOF announcement X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org We would like to announce the following BOF for the 67th IETF meeting. BOF name: NFSv4 and Low Infrastructure Public Key Based GSS Security Mechanisms Area: Security Area Chair: Jeffrey Hutzelman If this topic is of interest to you please email your questions and concerns to the mail list (spkm@ietf.org). Problem Statement: The NFSv4 protocol has a need for low infrastructure PKI based GSS security mechanism(s) that provide for the creation of a secure channel using mutual authentication where 1) both user and server authenticate with public key certificates 2) server authenticates with public key certificates, and the user authenticates with a username and password. Current State: RFC3530 "Network File System (NFS) version 4 Protocol" mandates the use of RFC2847 "LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM". While RFC2847 fulfills the requirements of the problem statement, there are areas where RFC2847 is outdated and/or underspecified. Futhermore, RFC2847 both replaces and refers to portions of RFC2025 "The Simple Public-Key GSS-API Mechanism (SPKM)" and is confusing to implementers. None the less, there are two implementations (Hummingbird and Linux) based upon RFC2847. draft-adamson-rfc2847-bis-01.txt, an update of RFC2847, is intended to address RFC2847 shortcomings and provide a complete specification that doesn't need [RFC2025] and that replaces [RFC2847]. Agenda: 1) Need for a low infrastructure PK based GSS security mechanism for NFSV4 - what is low infrastructure - existing markets - current implementations 2) draft-adamson-rfc2847-bis-01.txt - issues brought up by IESG review - naming - algorithms - which diffie-hellman - clarify protocol security claims - whole document review - backwards compatibility with RFC2847 based implementations 3) moving forward - finish draft-adamson-rfc2847-bis-01.txt - get draft into shape to submit to for IESG comments. - find reviewers - explore alternative GSS mechanisms _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Wed Oct 11 16:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXkUc-0006gi-TI; Wed, 11 Oct 2006 16:15:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXkUb-0006gG-Li for spkm@ietf.org; Wed, 11 Oct 2006 16:15:53 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXkUX-0002S9-VE for spkm@ietf.org; Wed, 11 Oct 2006 16:15:53 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9BKFnkx013496 for ; Wed, 11 Oct 2006 13:15:49 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k9BKFmeT004112 for ; Wed, 11 Oct 2006 14:15:48 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9BKFlav007637; Wed, 11 Oct 2006 15:15:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9BKFleH007636; Wed, 11 Oct 2006 15:15:47 -0500 (CDT) Date: Wed, 11 Oct 2006 15:15:47 -0500 From: Nicolas Williams To: Olga Kornievskaia Message-ID: <20061011201546.GC3878@binky.Central.Sun.COM> References: <452282B5.7000708@citi.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452282B5.7000708@citi.umich.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: spkm@ietf.org Subject: [SPKM] Re: [67th IETF] SPKM3 BOF announcement X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Tue, Oct 03, 2006 at 11:33:09AM -0400, Olga Kornievskaia wrote: > 2) draft-adamson-rfc2847-bis-01.txt > - issues brought up by IESG review > - naming > - algorithms > - which diffie-hellman > - clarify protocol security claims > - whole document review > - backwards compatibility with RFC2847 based implementations > 3) moving forward > - finish draft-adamson-rfc2847-bis-01.txt > - get draft into shape to submit to for IESG comments. > - find reviewers > - explore alternative GSS mechanisms First, although I prefer, as you know, pursuing "alternative GSS mechanisms," I think it may well be best to pursue the alternative that I've proposed (namely, a DTLS-based mechanism) using the individual submission process, even though that process did not work out for draft-adamson-rfc2847-bis. I've not made up my mind as to whether I'd argue for this or for pursuing a WG work item. Second, I believe it is possibly -- probably, IMO -- the case that two of your goals for draft-adamson-rfc2847-bis are mutually exclusive: - fixing the problems with RFC2847 - while retaining backwards compatibility with any deployed implementations It seems to me that establishing whether this is so would be an essential responsibility of any WG tasked with updating RFC2847 as a result of this BoF. Figuring that out would require participants who are intimately familiar with any such implementations and/or who are very experienced in trying to interop with them. It may be that some, but not all problems with RFC2847 can be fixed while retaining compatibility and that the result would pass WG, IETF and IESG review. Then again, it may not be. For example, draft-adamson-rfc2847-bis extends some ASN.1 types that in RFC2847 never had extensibility markers -- this could break interoperability with deployed implementations. And draft-adamson-rfc2847-bis specifies use of DER, whereas RFC2847 did not specify an encoding (one of its many problems), though Certificate may be encoded in BER... A more detailed summary of the problems with RFC2847 would be useful, and, if the BoF succeeds, necessary. Ditto establishing the desire/need for backwards compatibility (so we can answer questions like: why not a new mechanism OID, i.e., SPKM-4?). Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Wed Oct 11 19:04:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXn88-0000cF-G6; Wed, 11 Oct 2006 19:04:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXn86-0000c9-N9 for spkm@ietf.org; Wed, 11 Oct 2006 19:04:50 -0400 Received: from web31803.mail.mud.yahoo.com ([68.142.207.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXn83-0004aJ-8y for spkm@ietf.org; Wed, 11 Oct 2006 19:04:50 -0400 Received: (qmail 93440 invoked by uid 60001); 11 Oct 2006 23:04:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kIaGO+3jqUWN50Jpefyhswu0DYN2pweuqeWJzsrz2ueLMNW+e4MyfeNED1kvWmH6+aX4+q4T39BHct98dwwTv6MBXQHAZDMpUeEtINv+DUtowrgtkqhWtEQAfKd+K+4NMH+rkaqVXsjNcZZQwzKwWjy+TRZ8NNHfJObR2eeLbBo= ; Message-ID: <20061011230444.93438.qmail@web31803.mail.mud.yahoo.com> Received: from [198.95.226.224] by web31803.mail.mud.yahoo.com via HTTP; Wed, 11 Oct 2006 16:04:44 PDT Date: Wed, 11 Oct 2006 16:04:44 -0700 (PDT) From: Mike Eisler Subject: Re: [SPKM] Re: [67th IETF] SPKM3 BOF announcement To: spkm@ietf.org In-Reply-To: <20061011201546.GC3878@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org --- Nicolas Williams wrote: > On Tue, Oct 03, 2006 at 11:33:09AM -0400, Olga Kornievskaia wrote: > > 2) draft-adamson-rfc2847-bis-01.txt > > - issues brought up by IESG review > > - naming > > - algorithms > > - which diffie-hellman > > - clarify protocol security claims > > - whole document review > > - backwards compatibility with RFC2847 based implementations > > 3) moving forward > > - finish draft-adamson-rfc2847-bis-01.txt > > - get draft into shape to submit to for IESG comments. > > - find reviewers > > - explore alternative GSS mechanisms > > First, although I prefer, as you know, pursuing "alternative GSS > mechanisms," I think it may well be best to pursue the alternative > that > I've proposed (namely, a DTLS-based mechanism) using the individual > submission process, even though that process did not work out for > draft-adamson-rfc2847-bis. I've not made up my mind as to whether > I'd > argue for this or for pursuing a WG work item. Not that it has ever stopped IETF before, but I think a GSS Public Key WG should avoid multiple solutions to the same problem. When I wrote RFC 2847, it was with the advice and encouragement of SPKM-philes, and a belief that this would be relatively simple to pull off. It turned, at the time, it was relatively hard, because the SPKM-1 code I thought I had has bit rotted, and I never had time to untangle the mess. At this point Andy, Olga, and others say they have interoperating SPKM-3 implementations. That trumps pursuing alternatives, however elegant some might see them to be. An analogy is Kerberos V5. The reason every NFSv4 implementation today supports Kerberos V5 is not because Kerberos V5 is elegant (it's really messy) or easy to use or deploy (it's really messy), but because it turned out to be relatively easy to drop into RPCSEC_GSS and hence RPC and NFS. A credit to the many people who worked on MIT Kerberos. So a test for SPKM or any other public key GSS mechanism is how easy reference (read: free, like beer) code will be to drop into *every* NFSv4 implementation. > Second, I believe it is possibly -- probably, IMO -- the case that > two > of your goals for draft-adamson-rfc2847-bis are mutually exclusive: > > - fixing the problems with RFC2847 > - while retaining backwards compatibility with any deployed > implementations [good stuff deleted] The takeaway for me is that it may take a bunch of time to sort this out. Again, I favor moving fast, and additionally, I favor simplicity, especially when it comes to security (that which is hard to understand is more prone to security holes, which really need to avoid). So SPKM-5 (reserving even numbers for the evil timestamped based SPKMs) may be a reasonable way out of this. Those who still would like a fixed SPKM-3 can figure out how to do that without holding up SPKM-5. We could even make it an official work item so that we don't have to confused by personal i-ds. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Wed Oct 11 19:38:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXneO-0006UK-MB; Wed, 11 Oct 2006 19:38:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXneN-0006UE-GH for spkm@ietf.org; Wed, 11 Oct 2006 19:38:11 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXneJ-0000MQ-2w for spkm@ietf.org; Wed, 11 Oct 2006 19:38:11 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9BNc6iH022569 for ; Wed, 11 Oct 2006 17:38:06 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k9BNc5hc015542 for ; Wed, 11 Oct 2006 17:38:05 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9BNc2nM012293; Wed, 11 Oct 2006 18:38:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9BNc1JT012292; Wed, 11 Oct 2006 18:38:01 -0500 (CDT) Date: Wed, 11 Oct 2006 18:38:01 -0500 From: Nicolas Williams To: Mike Eisler Subject: Re: [SPKM] Re: [67th IETF] SPKM3 BOF announcement Message-ID: <20061011233801.GA12284@binky.Central.Sun.COM> References: <20061011201546.GC3878@binky.Central.Sun.COM> <20061011230444.93438.qmail@web31803.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061011230444.93438.qmail@web31803.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Wed, Oct 11, 2006 at 04:04:44PM -0700, Mike Eisler wrote: > --- Nicolas Williams wrote: > > > - explore alternative GSS mechanisms > > > > First, although I prefer, as you know, pursuing "alternative GSS > > mechanisms," I think it may well be best to pursue the alternative > > that > > I've proposed (namely, a DTLS-based mechanism) using the individual > > submission process, even though that process did not work out for > > draft-adamson-rfc2847-bis. I've not made up my mind as to whether > > I'd > > argue for this or for pursuing a WG work item. > > Not that it has ever stopped IETF before, but > I think a GSS Public Key WG should avoid multiple > solutions to the same problem. > > When I wrote RFC 2847, it was with the advice and encouragement > of SPKM-philes, and a belief that this would be relatively > simple to pull off. It turned, at the time, it was relatively > hard, because the SPKM-1 code I thought I had has bit rotted, > and I never had time to untangle the mess. > > At this point Andy, Olga, and others say they have interoperating > SPKM-3 implementations. That trumps pursuing alternatives, > however elegant some might see them to be. Your opinion is not entirely at variance with mine. I took the presence of the above item in the agenda as an acknowledgement of alternate proposals. I then expressed my belief that a DTLS-based mechanism, as I propose, could progress through the individual submission track. See below. I would like to hear from the ADs as to whether the IESG would frown at two standards-track ways of doing much the same thing, or at one standards-track and one informational/experimental alternative. > An analogy is Kerberos V5. The reason every NFSv4 implementation > today supports Kerberos V5 is not because Kerberos V5 is elegant > (it's really messy) or easy to use or deploy (it's really messy), > but because it turned out to be relatively easy to drop into RPCSEC_GSS > and hence RPC and NFS. A credit to the many people who worked on MIT > Kerberos. What made Kerberos V so successful was, in great part, IMO, the availability of open source implementations. The same is true of TLS. If SPKM-# succeeds it may well turn out to be for similar reasons. > So a test for SPKM or any other public key GSS mechanism > is how easy reference (read: free, like beer) code will be to > drop into *every* NFSv4 implementation. As long as SPKM conforms to the GSS-API as an interface then, whatever SPKM may look like on the wire, it should "drop into" NFSv4 no problem. Getting new mechanisms to "drop into *every* NFSv4 implementation" is another story in that this depends on whether NFSv4 implementations are pluggable or otherwise make it easy to drop in new mechanisms. But here I'm picking nits :) > > Second, I believe it is possibly -- probably, IMO -- the case that > > two > > of your goals for draft-adamson-rfc2847-bis are mutually exclusive: > > > > - fixing the problems with RFC2847 > > - while retaining backwards compatibility with any deployed > > implementations > [good stuff deleted] > > The takeaway for me is that it may take a bunch of time to > sort this out. I've provided plenty of feedback over the last three years, to all who've asked for it, about what was wrong with the existing SPKM specs and how to fix it. It's taken the better part of three years to reach the point where a BoF was thought necessary... > Again, I favor moving fast, and additionally, I favor > simplicity, especially when it comes to security (that which > is hard to understand is more prone to security holes, which really > need to avoid). Given how long it's taken to come to this point it seems like a safe bet that it will take a long time to finish an update to SPKM-3 or a new SPKM. One way to speed things up and simplify things would be to drop interop with SPKM-3 implementations as a requirement and simply introduce a new SPKM with a new mechanism OID. Doing so would allow for a number of simplifications, methinks. E.g., no more CertificatePair. Note that simplicity from implementors' p.o.v. is important also. This is where DTLS comes in: using off-the-shelf DTLS implementations (or adding DTLS support to existing off-the-shelf TLS implementations) in order to implement a new SPKM would greatly simplify SPKM for many implementors. > So SPKM-5 (reserving even numbers for the evil > timestamped based SPKMs) may be a reasonable way out of this. I agree. But if the authors would agree to this, then one has to ask: why charter a WG for SPKM-4/5/whatever? Why shouldn't the individual submission process work? > Those who still would like a fixed SPKM-3 can figure out how to do > that without holding up SPKM-5. We could even make it an official > work item so that we don't have to confused by personal i-ds. I don't understand the last sentence, but I suspect that I agree :) Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Thu Oct 12 10:11:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1H7-0001QF-0O; Thu, 12 Oct 2006 10:11:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1H5-0001PZ-W5 for spkm@ietf.org; Thu, 12 Oct 2006 10:11:03 -0400 Received: from web31801.mail.mud.yahoo.com ([68.142.207.64]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GY1H4-0003MN-MN for spkm@ietf.org; Thu, 12 Oct 2006 10:11:03 -0400 Received: (qmail 43897 invoked by uid 60001); 12 Oct 2006 14:11:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ud9M+S4JF/fWHRjRPNtJ0I31rG58HBknsk4JyDdh3wmoAyHDmCXBeyjN/7xDNFIoD+NRaeRuPLP3LON/43lLg3PpGPdmPh60yJLtk/WDHjrfMQM4l8+g7Cn+onI2B0rW9A4JFvqQ6sHM+TcEFsuFWLUhNCHh+8NnD7xs2YOyIMk= ; Message-ID: <20061012141102.43895.qmail@web31801.mail.mud.yahoo.com> Received: from [198.95.226.224] by web31801.mail.mud.yahoo.com via HTTP; Thu, 12 Oct 2006 07:11:02 PDT Date: Thu, 12 Oct 2006 07:11:02 -0700 (PDT) From: Mike Eisler Subject: Re: [SPKM] Re: [67th IETF] SPKM3 BOF announcement To: spkm@ietf.org In-Reply-To: <20061011233801.GA12284@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org --- Nicolas Williams wrote: > > So SPKM-5 (reserving even numbers for the evil > > timestamped based SPKMs) may be a reasonable way out of this. > > I agree. > > But if the authors would agree to this, then one has to ask: why > charter > a WG for SPKM-4/5/whatever? Why shouldn't the individual submission > process work? Sam Hartman suggested that the BOF/WG route would be a deterministic way to gauge interest in the problem, and thus determine whether IETF should spend its cleverness on this issue. The authors agreed. > > Those who still would like a fixed SPKM-3 can figure out how to do > > that without holding up SPKM-5. We could even make it an official > > work item so that we don't have to confused by personal i-ds. > > I don't understand the last sentence, but I suspect that I agree :) What I mean is that the potential WG can add: "fix SPKM-3 in a backward compatible way" as an additional, but lower priority item to its charter, but the primary goal would be to produce SPKM-5. Once SPKM-5 is done, those who want to produce a repaired SPKM-3 can continue to do so. And if there is going to be an effort to fix SPKM-3 I'd rather the I-Ds were named draft-ietf-spkm-... than draft-smith-spkm-... because they are harder to find. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Thu Oct 12 15:38:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY6OJ-0006ir-E3; Thu, 12 Oct 2006 15:38:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY6OI-0006iA-GE for spkm@ietf.org; Thu, 12 Oct 2006 15:38:50 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY6LK-0003db-Ov for spkm@ietf.org; Thu, 12 Oct 2006 15:35:50 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9CJZkEl022207 for ; Thu, 12 Oct 2006 13:35:46 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k9CJZjqS029876 for ; Thu, 12 Oct 2006 13:35:45 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9CJZiJ4012982; Thu, 12 Oct 2006 14:35:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9CJZi6B012981; Thu, 12 Oct 2006 14:35:44 -0500 (CDT) Date: Thu, 12 Oct 2006 14:35:44 -0500 From: Nicolas Williams To: Mike Eisler Subject: Re: [SPKM] Re: [67th IETF] SPKM3 BOF announcement Message-ID: <20061012193543.GI12284@binky.Central.Sun.COM> References: <20061011233801.GA12284@binky.Central.Sun.COM> <20061012141102.43895.qmail@web31801.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061012141102.43895.qmail@web31801.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Thu, Oct 12, 2006 at 07:11:02AM -0700, Mike Eisler wrote: > --- Nicolas Williams wrote: > > I don't understand the last sentence, but I suspect that I agree :) > > What I mean is that the potential WG can add: > "fix SPKM-3 in a backward compatible way" > as an additional, but lower priority item to its charter, but the > primary goal would be to produce SPKM-5. Once SPKM-5 is done, > those who want to produce a repaired SPKM-3 can continue to do > so. And if there is going to be an effort to fix SPKM-3 I'd > rather the I-Ds were named draft-ietf-spkm-... than > draft-smith-spkm-... because they are harder to find. I'd like to think that the individual submission path should be workable for security area work. In particular I think neither an SPKM-4/5 nor a DTLS based GSS mechanism should require forming a WG. And if there isn't sufficient interest in fixing SPKM-3 to form a WG, then nothing more can be done for it. At this point we need to hear from the authors and from anyone with experience with deployed implementations. We need to hear about the interop story. Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Thu Oct 12 15:56:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY6fA-0005ZN-BI; Thu, 12 Oct 2006 15:56:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY6XV-0005V1-Rx for spkm@ietf.org; Thu, 12 Oct 2006 15:48:21 -0400 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY6XU-0005gL-47 for spkm@ietf.org; Thu, 12 Oct 2006 15:48:21 -0400 Received: from citi.umich.edu (repository.citi.umich.edu [141.211.133.9]) by citi.umich.edu (Postfix) with ESMTP id D633D1BE1C; Thu, 12 Oct 2006 15:48:19 -0400 (EDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.1 To: Nicolas Williams Subject: Re: [SPKM] Re: [67th IETF] SPKM3 BOF announcement In-reply-to: <20061012193543.GI12284@binky.Central.Sun.COM> References: <20061011233801.GA12284@binky.Central.Sun.COM> <20061012141102.43895.qmail@web31801.mail.mud.yahoo.com> <20061012193543.GI12284@binky.Central.Sun.COM> Comments: In-reply-to Nicolas Williams message dated "Thu, 12 Oct 2006 14:35:44 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Oct 2006 15:48:19 -0400 From: "William A.(Andy) Adamson" Message-Id: <20061012194819.D633D1BE1C@citi.umich.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Thu, 12 Oct 2006 15:56:13 -0400 Cc: andros@citi.umich.edu, spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org > On Thu, Oct 12, 2006 at 07:11:02AM -0700, Mike Eisler wrote: > > --- Nicolas Williams wrote: > > > I don't understand the last sentence, but I suspect that I agree :) > > > > What I mean is that the potential WG can add: > > "fix SPKM-3 in a backward compatible way" > > as an additional, but lower priority item to its charter, but the > > primary goal would be to produce SPKM-5. Once SPKM-5 is done, > > those who want to produce a repaired SPKM-3 can continue to do > > so. And if there is going to be an effort to fix SPKM-3 I'd > > rather the I-Ds were named draft-ietf-spkm-... than > > draft-smith-spkm-... because they are harder to find. > > I'd like to think that the individual submission path should be workable > for security area work. In particular I think neither an SPKM-4/5 nor a > DTLS based GSS mechanism should require forming a WG. And if there > isn't sufficient interest in fixing SPKM-3 to form a WG, then nothing > more can be done for it. > > At this point we need to hear from the authors and from anyone with > experience with deployed implementations. We need to hear about the > interop story. At the September 2006 NFSv4 bakeathon here at CITI, the Hummingbird Windows NFSv4 client mounted a Linux NFSv4 server using SPKM3 (not spkm3i nor spkm3p). Two independent SPKM3 implementations. The full suite of connectathon tests passed. I'd say this shows a lot of interest in SPKM3. -->Andy > > Nico > -- > > _______________________________________________ > SPKM mailing list > SPKM@ietf.org > https://www1.ietf.org/mailman/listinfo/spkm _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Thu Oct 12 16:19:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY71J-0005xc-UJ; Thu, 12 Oct 2006 16:19:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY71I-0005xU-Vx for spkm@ietf.org; Thu, 12 Oct 2006 16:19:08 -0400 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY71G-0002IO-AW for spkm@ietf.org; Thu, 12 Oct 2006 16:19:08 -0400 Received: from citi.umich.edu (repository.citi.umich.edu [141.211.133.9]) by citi.umich.edu (Postfix) with ESMTP id 1546E1BD22 for ; Thu, 12 Oct 2006 16:19:02 -0400 (EDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.1 To: spkm@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1160683890_149970" Date: Thu, 12 Oct 2006 16:19:02 -0400 From: "William A.(Andy) Adamson" Message-Id: <20061012201902.1546E1BD22@citi.umich.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 Subject: [SPKM] Issues with Naming X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org This is a multipart MIME message. --==_Exmh_1160683890_149970 Content-Type: text/plain; charset=us-ascii At the 67th IETF meeting, one of the issues that we would like to discuss is naming. Prior to the creation of this list, we had many email discussions on naming with Nicolas Williams, Martin Rex, Sandeep Ramesh, and others. A few of the relevant messages are attached. We learned form the discussion that we need to get help of the cs community. The point of this mail is to setup the discussion about naming by summarizing the issues so that we can get the ball rolling and also setup our discussion for the IETF meeting. Note while we're discussing these issues in the context of draft-adamson-rfc2847-bis, they need to be addressed with any PKI GSSAPI mechanism. Server-side names ----------------- -- Problem: the client constructs a 'target-name' based on the limited information (ie service name, service hostname), without having server's certificate. then after the client receives the target's certificate it has to match the constructed 'target-name' against the received certificate. -- the current draft proposes a number of matching rules. [comment] received negative reaction to our proposal to include a 'structure' in the CN field of the certificate. we proposed to have CN=nfs/hostname, then match it to the 'target-name' of nfs/hostname. Instead of the matching rules, we propose that we follow the same approach as does PKINIT (for the KDC certs). -- Another solution (that follows PKINIT approach): -- Require the server to have SPKM3 Extended Key Usage (EKU) X509v3 extension in its certificate. -- Require the server to have SPKM3 Subject Alternative Name (SAN). -- [issue] what to put in the SAN? -- dnsNAme= -- otherName wth type-id field=id-spkm3-san (OID) and value=??? [comment] In PKINIT, SAN carries KerberosPrincipalName. In SPKM3, we have no established name space to rely on. Client-side names ----------------- -- Problem: after the context negotiation, the server needs to construct a 'client-name' from the received certificate. Currently, an X509 DN lacks a canonical form and GSSAPI requires that each mechanism implements gss_export_name() which returns a name in a canonical form that can be used for access control. In the context of NFSv4, the lack of a canonical 'client-name' from the gss context posses a problem for mapping the exported name into an NFSv4 name. -- the current draft proposes a set of rules to transform an X509 DN into a canonical form (but the rules have limitiations) [comment] we still stand by our design to make the client-side name to be a canonical X509 name from the client's certificate. We can't really put SAN in a client certificate as does PKINIT because we have no namespace to fallback on like Kerberos does. The best we could do is add a requirement to have an SPKM3 EKU in the certificate. However, we still would need to produce a canonical name for the client. Therefore, we would like to come up with a set up rules that transform an X509DN into a canonical name. Of course, any other alternatives are -->Andy and Olga --==_Exmh_1160683890_149970 Content-Type: message/rfc822 ; name="239" Content-Description: 239 Content-Disposition: attachment; filename="239" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on citi.umich.edu X-Spam-Level: X-Spam-Status: No, score=-4.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 X-Original-To: andros@citi.umich.edu Delivered-To: andros@citi.umich.edu Received: from [141.211.133.26] (yoga.citi.umich.edu [141.211.133.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "aglo", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id B45D21BDAB; Tue, 16 May 2006 14:08:30 -0400 (EDT) Message-ID: <446A151E.7090908@citi.umich.edu> Date: Tue, 16 May 2006 14:08:30 -0400 From: Olga Kornievskaia User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams Cc: "William A.(Andy) Adamson" , martin.rex@sap.com, email2mre-ietf@yahoo.com, Kevin Coffman , Sandeep Ramesh Subject: Re: SPKM-3 draft review References: <20060427143246.C7A251BBE1@citi.umich.edu> <20060427151509.GZ8152@binky.Central.Sun.COM> <44690A1C.40107@citi.umich.edu> <20060516042332.GE4249@binky.Central.Sun.COM> <20060516174221.A04BF1BC0B@citi.umich.edu> <20060516175200.GD5642@binky.Central.Sun.COM> In-Reply-To: <20060516175200.GD5642@binky.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: see a comment at the end... Nicolas Williams wrote: >>>>>>Among other things I disagree with the choice of name construction. >>>>>> >>>>>> >>>>"Name types" section has been reworked. The gist is: X500 name have no >>>>canonical form. >>>> >>>> >>>Sort of. That doesn't mean that you can't prescribe matching rules for >>>GSS-API generic syntax to certificate DNs and/or SANs, as well as >>>mechanism-specific naming syntaxes that more closely match cert naming. >>> >>> >>ok - instead of defining rules for SPKM-3 canonical name form, prescribe >>matching rules. >> >> > >Well, not entirely instead. You can make a best effort for canonical >name form. > > > that's is exactly what we did. when i said "x500 name have no canonical form", i met to say none of the standards define a canonical form. the rest of the paragraph from the original email described as you put it "a best effort for canonical name form". >>>Without a directory GSS_Canonicalize_name() can't do much -- oh well. >>> >>> >>hey! no directory service is a feature! >> >> > >Right. > > i'm puzzled by the statement 'without a directory gss_canonicalize_name() can't do much. i think this function will do just fine without a directory service. spkm-3 carries the certs of the participants in their tokens. so all the necessary info for getting a canonical name and then possibly checking an ACL is there. >>>> rfc2253 proposes a string representation but it is >>>>still not canonical. It does not address the order of multi-valued DNs, >>>>white spaces and case (this might not have a solution though). We >>>>propose to use rfc2253 format with additional rules (details are in >>>>section 2.5.1.1), briefly it's ordering or AVAs, removal of white spaces >>>>and making values all lower case. However, string representation can >>>>still be non-canonical because some implementation may lack an >>>>OID-to-string translation for an attribute present in an X500 >>>>distinguished name (eg., 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=US). So >>>>two different implementations might represent the same DN with different >>>>string representation (one which would include a string for the OID and >>>>another will have to go with hex value of the OID as in the example). So >>>>for the gss_export_name() we propose to then DER-encode the string. The >>>>result should be a canonical name that can be used for ACLs. >>>> >>>> >>>For the gss_export_name() you might even just return the whole cert... >>> >>> >>ug. >> >> > >Why is that a problem? > > users change their certs (eg., public/private key expires) and keep the same name. a good example would be a kx509 cert which gives the user a new cert every day based on kerberos creds. using a cert as an ACL doesn't seem to be a good idea. --==_Exmh_1160683890_149970 Content-Type: message/rfc822 ; name="246" Content-Description: 246 Content-Disposition: attachment; filename="246" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on citi.umich.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.1.1 X-Original-To: andros@citi.umich.edu Delivered-To: andros@citi.umich.edu Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.170]) by citi.umich.edu (Postfix) with ESMTP id 0110D1BAA9; Tue, 16 May 2006 17:10:04 -0400 (EDT) Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA04511; Tue, 16 May 2006 23:10:04 +0200 (MESZ) From: Martin Rex Message-Id: <200605162110.XAA29484@uw1048.wdf.sap.corp> Subject: Re: SPKM-3 draft review To: aglo@citi.umich.edu (Olga Kornievskaia) Date: Tue, 16 May 2006 23:10:03 +0200 (MET DST) Cc: Nicolas.Williams@sun.com, andros@citi.umich.edu, martin.rex@sap.com, email2mre-ietf@yahoo.com, kwc@citi.umich.edu, sandeep.patil@in.ibm.com In-Reply-To: <446A151E.7090908@citi.umich.edu> from "Olga Kornievskaia" at May 16, 6 02:08:30 pm Reply-To: martin.rex@sap.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out Status: Olga Kornievskaia wrote: > > that's is exactly what we did. when i said "x500 name have no canonical > form", i met to say none of the standards define a canonical form. the > rest of the paragraph from the original email described as you put it "a > best effort for canonical name form". I agree. Since we have differences based on the amout of whitespace around the RDN seperators, different acceptable RDN seperator chars, differences in the case of the RDN attribute labels, there is quite some amount of "canonicalization" that can be done within gss_canonicalize_name() or gss_import_name()--which one is up to the implementation). ACL comparisons based on exported names do a memcmp(), so case does matter (even on the attribute labels), and so does the type and amount of whitespace and the RDN seperator char. > >>>> > >>>For the gss_export_name() you might even just return the whole cert... > >>> > >>> > >>ug. > >> > >> > > > >Why is that a problem? > > > > > users change their certs (eg., public/private key expires) and keep the > same name. a good example would be a kx509 cert which gives the user a > new cert every day based on kerberos creds. using a cert as an ACL > doesn't seem to be a good idea. I also strongly dislike the idea of returning a certificate from gss_export_name(). None of the SPKM and SPKM-like mechanisms that I've seen do that. The two variants of gss_export_name() that I've seen use either the printable subject DName encapsulated in the generic framing for exported names or the ASN.1 DER encoding of the DName. The ASN.1 DER is more error-prone, because it contains ASN.1 tags of the encoding and it's not unlikely that a gssapi mechanism creates a different ASN.1 encoding from a printable name that what the CA created when it issued the certificate -- i.e. the gssapi mechanism needs to always canonicalize through a printable representation in order to account for encoding differences (IA5String vs. Printable, abused T61String vs. correct UTF8String vs. correct T61String). This is particularly true for non-standard name components, which often will end up with an OID-dump in the DName... There seem to be a a significant amount of PKIs using non-standard (or at least uncommon) DName components instead of subjectAltName -Martin --==_Exmh_1160683890_149970 Content-Type: message/rfc822 ; name="333" Content-Description: 333 Content-Disposition: attachment; filename="333" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on citi.umich.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 X-Original-To: andros@citi.umich.edu Delivered-To: andros@citi.umich.edu Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by citi.umich.edu (Postfix) with ESMTP id 50CC21BB6C; Fri, 26 May 2006 18:19:59 -0400 (EDT) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4QMJwTR022630; Fri, 26 May 2006 16:19:58 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k4QMIwab005881; Fri, 26 May 2006 16:18:58 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k4QMJvGs026539; Fri, 26 May 2006 17:19:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4QMJvD0026538; Fri, 26 May 2006 17:19:57 -0500 (CDT) Date: Fri, 26 May 2006 17:19:57 -0500 From: Nicolas Williams To: Olga Kornievskaia Cc: martin.rex@sap.com, andros@citi.umich.edu, email2mre-ietf@yahoo.com, kwc@citi.umich.edu, sandeep.patil@in.ibm.com Subject: Re: SPKM-3 draft review Message-ID: <20060526221957.GG11607@binky.Central.Sun.COM> References: <200605162110.XAA29484@uw1048.wdf.sap.corp> <44777283.30301@citi.umich.edu> <20060526213114.GC11607@binky.Central.Sun.COM> <44777A51.1000801@citi.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44777A51.1000801@citi.umich.edu> User-Agent: Mutt/1.5.7i Status: On Fri, May 26, 2006 at 05:59:45PM -0400, Olga Kornievskaia wrote: > Nicolas Williams wrote: > >Careful with terminology. This does not mean what you clarified to me. > > > >You mean to say that you'll use the output of a Name-to-rfc2253-to-Name > >conversion, with DER as the ASN.1 encoding. > > > >That's fine. > > > > > Let me try again. SPKM-3 spec proposes: given a DER encoded certificate, ^^^^^^^^^^^^^^^^^^^^^^^ don't say this, say "PKIX certificate" or "x.509 certificate" as the encoding thereof is irrelevant for this discussion > we will retrieve the subject name and use the rfc2253 algorithm to get a > string representation of the distinguished name, it's a UTF8 string (the > *name* of the rfc2253 is "UTF-8 String Representation of Distinguished > Names"). Ok. now given this string, we propose to DER encode it. I ^^^^^^^^^^^^^ > believe you say: "this is fine". No, no, you've made the same mistake again. To say "DER encode it" might mean "slap a DER Universal UTF8String tag and length in front of the UTF-8 string and be done." What you probably meant is "*parse* the rfc2253 string and output a DER encoding of the RFC3280 ASN.1 'Name' type." The key here is to carefully specify what ASN.1 type you're saying to DER encode. > Now I said: for DER encoding, we propose to use UTF8String for each RDN > attribute value. An example of an RDN in this case is "CN=aglo". We > propose to encode the value "aglo" as an UTF8String. If you look at the > rfc3280, CommonName encoding is defined as: > > CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) > > I believe DER encoding difference arise when even though PrintableString > type is specified different implementation might use IA5String instead > of PrintableString. > > So to 'nail it down' since rfc2253 converted everything to UTF8, we > continue to use this encoding for each RDN value. Is this more clear? Well, this points out that for I18N SPKM-3 depends on PKIX I18N. I don't think you can or should try to tackle I18N in a GSS mechanism that depends on I18N in components that haven't been internationalized. Yet another reason to take this to the IETF now. Nico -- --==_Exmh_1160683890_149970 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm --==_Exmh_1160683890_149970-- From spkm-bounces@ietf.org Thu Oct 12 17:06:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY7l5-0003n0-Bc; Thu, 12 Oct 2006 17:06:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY7l4-0003ms-IE for spkm@ietf.org; Thu, 12 Oct 2006 17:06:26 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY7l3-0001hy-2j for spkm@ietf.org; Thu, 12 Oct 2006 17:06:26 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9CL6K6o011483 for ; Thu, 12 Oct 2006 14:06:24 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k9CL6Je3025122 for ; Thu, 12 Oct 2006 15:06:19 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9CL6J3x013068; Thu, 12 Oct 2006 16:06:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9CL6Iwq013067; Thu, 12 Oct 2006 16:06:18 -0500 (CDT) Date: Thu, 12 Oct 2006 16:06:18 -0500 From: Nicolas Williams To: "William A.(Andy) Adamson" Subject: Re: [SPKM] Re: [67th IETF] SPKM3 BOF announcement Message-ID: <20061012210617.GK12284@binky.Central.Sun.COM> References: <20061011233801.GA12284@binky.Central.Sun.COM> <20061012141102.43895.qmail@web31801.mail.mud.yahoo.com> <20061012193543.GI12284@binky.Central.Sun.COM> <20061012194819.D633D1BE1C@citi.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061012194819.D633D1BE1C@citi.umich.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Thu, Oct 12, 2006 at 03:48:19PM -0400, William A.(Andy) Adamson wrote: > > I'd like to think that the individual submission path should be workable > > for security area work. In particular I think neither an SPKM-4/5 nor a > > DTLS based GSS mechanism should require forming a WG. And if there > > isn't sufficient interest in fixing SPKM-3 to form a WG, then nothing > > more can be done for it. > > > > At this point we need to hear from the authors and from anyone with > > experience with deployed implementations. We need to hear about the > > interop story. > > At the September 2006 NFSv4 bakeathon here at CITI, the Hummingbird Windows > NFSv4 client mounted a Linux NFSv4 server using SPKM3 (not spkm3i nor spkm3p). > Two independent SPKM3 implementations. The full suite of connectathon tests > passed. I assume these don't quite implement RFC2847, but something similar, yes? How faithful a description of that protocol is draft-adamson- rfc2847-bis-01? Has either implementation been deployed in production environments? Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Thu Oct 12 17:46:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY8Nx-0003bF-8M; Thu, 12 Oct 2006 17:46:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY8Nv-0003b8-Ss for spkm@ietf.org; Thu, 12 Oct 2006 17:46:35 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY8Nu-0000Vp-GS for spkm@ietf.org; Thu, 12 Oct 2006 17:46:35 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9CLkXnV029226 for ; Thu, 12 Oct 2006 15:46:33 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k9CLkXCp014679 for ; Thu, 12 Oct 2006 15:46:33 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9CLkXBX013102; Thu, 12 Oct 2006 16:46:33 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9CLkXiI013101; Thu, 12 Oct 2006 16:46:33 -0500 (CDT) Date: Thu, 12 Oct 2006 16:46:33 -0500 From: Nicolas Williams To: "William A.(Andy) Adamson" Subject: Re: [SPKM] Issues with Naming Message-ID: <20061012214632.GM12284@binky.Central.Sun.COM> References: <20061012201902.1546E1BD22@citi.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061012201902.1546E1BD22@citi.umich.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Thu, Oct 12, 2006 at 04:19:02PM -0400, William A.(Andy) Adamson wrote: > Server-side names > ----------------- > > -- Problem: the client constructs a 'target-name' based on the limited > information (ie service name, service hostname), without having server's > certificate. then after the client receives the target's certificate it > has to match the constructed 'target-name' against the received certificate. Background: the initial token has to name the acceptor -- that is, it has to convey the target name that the application passed to GSS_Init_sec_context(). RFC2847 provides a field of type Name for this. [I don't recall but it's possible that I may have missed some of this background in those e-mails we exchanged a while back.] Now, Name is quite restrictive, but since the Name in this token needn't actually be a cert Name as much as something that can be matched to an appropriate acceptor certificate, matching rules can allow SPKM to express the basic GSS-API name types with relative ease. Adding new name types may prove difficult. I would prefer not using Name, but depending on the matching rules I could hold my nose and live with Name. > -- the current draft proposes a number of matching rules. > > [comment] received negative reaction to our proposal to include a > 'structure' in the CN field of the certificate. we proposed to have > CN=nfs/hostname, then match it to the 'target-name' of nfs/hostname. That works for GSS_C_NT_HOSTBASED_SERVICE, but what about other name types? Also, what if I import an exported name token and pass that to GSS_Init_sec_context() as the target name? That has to work too. > Instead of the matching rules, we propose that we follow the same > approach as does PKINIT (for the KDC certs). > -- Another solution (that follows PKINIT approach): > -- Require the server to have SPKM3 Extended Key Usage (EKU) X509v3 > extension in its certificate. IMO the EKU has to relate to the GSS-API service name, not to the mechanism. Who cares what the mechanism is? > Client-side names > ----------------- > > -- Problem: after the context negotiation, the server needs to construct a > 'client-name' from the received certificate. Currently, an X509 DN lacks a > canonical form and GSSAPI requires that each mechanism implements > gss_export_name() which returns a name in a canonical form that can be used > for access control. There is no easy choice here. You could use a structure that includes the cert's DN, its KU/EKUs and its SubjectAltName, if any. That's almost like using the whole certificate minus public key and other info that can change more often than the "name" of the cert. > In the context of NFSv4, the lack of a canonical 'client-name' from the gss > context posses a problem for mapping the exported name into an NFSv4 name. There is no requirement, in RFC3530 or elsewhere, that NFSv4 implementations use the "gsscred" method of mapping client principals to local identities. (The "gsscred" method of... consists of looking up an entry, in a database keyed by exported name token, whose value indicates the principal's local identity.) NFSv4 implementations could do other things. The KITTEN WG is chartered to, among other things, develop extensions to the GSS-API that would help in this particular case. Thus NFSv4 implementations could look at the "attributes" of a client principal (i.e., the initiator's NAME object returned by GSS_Accept_sec_context()) and derive local identities or "gsscred" database keys from them. Your complaint about the lack of a canonical name for PKIX identities is not new, and KITTEN WG is well aware of it. Whatever SPKM-x ends up doing w.r.t. canonical exported name forms will be merely pragmatic and less than ideal, unless... see below. > -- the current draft proposes a set of rules to transform an X509 DN > into a canonical form (but the rules have limitiations) > > [comment] we still stand by our design to make the client-side name > to be a canonical X509 name from the client's certificate. We can't > really put SAN in a client certificate as does PKINIT because we have no > namespace to fallback on like Kerberos does. The best we could do is add > a requirement to have an SPKM3 EKU in the certificate. However, we still > would need to produce a canonical name for the client. Therefore, we > would like to come up with a set up rules that transform an X509DN into > a canonical name. Of course, any other alternatives are Another, perhaps better option, would be for the protocol to allow the client to assert a canonical name for it that the acceptor then makes sure matches the client's certificate, then GSS_Accept_sec_context() can return an initiator NAME whose exported form will agree with what the initiator asserted. Initiator applications would have control over what name to assert through the desired_name argument to the GSS_Acquire/Add_cred() functions used to acquire an initiator CREDENTIAL for use with GSS_Init_sec_context(). To me this would imply using something that includes a GeneralName... Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Thu Oct 12 18:36:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY9A6-0007Am-UG; Thu, 12 Oct 2006 18:36:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY9A5-0007Ah-Og for spkm@ietf.org; Thu, 12 Oct 2006 18:36:21 -0400 Received: from mx.hcl.com ([205.211.178.70] helo=MX.HUMMINGBIRD.COM) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY9A3-0001eD-EX for spkm@ietf.org; Thu, 12 Oct 2006 18:36:21 -0400 Received: from tor01x6.hcl.com (smtp1.hcl.com [10.1.42.55] (may be forged)) by MX.HUMMINGBIRD.COM (8.12.10/8.12.10) with ESMTP id k9CMa4EV002330; Thu, 12 Oct 2006 18:36:08 -0400 Received: by smtp1.hcl.com with Internet Mail Service (5.5.2653.19) id <4W3R04RR>; Thu, 12 Oct 2006 18:35:56 -0400 Message-ID: From: Razvan Trufasiu To: "'spkm@ietf.org'" Subject: RE: [SPKM] Re: [67th IETF] SPKM3 BOF announcement Date: Thu, 12 Oct 2006 18:36:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "'William A.\(Andy\) Adamson'" , Dan Trufasiu , 'Olga Kornievskaia' X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Hello, My name is Razvan Trufasiu, and I am in charge of developing an SPKM-3/LIPKey implementation for the Hummingbird NFS Maestro server. At the moment, Hummingbird NFSv4 implementation supports anonymous SPKM-3 and LIPKey, and the next version will hopefully implement mutual SPKM-3. Any of these are based upon the specs released in early 2006. The specs have already changed, from my understanding; however, updating the code to support this should be simple. For interoperability, currently Olga and I managed to run several Connectathon tests successfully, without Integrity or Privacy. We can connect (tentatively) with Integrity, and are working on being able to connect with Privacy, and run all the tests. There are several problems we are currently still addressing. The reason we have chosen to implement SPKM-3 or LIPKey is to provide an alternative GSS implementation to Kerberos v5. Kerberos is often difficult to set up, and the overhead of having a separate Kerberos server, in addition to the NFS client/server can be cumbersome for certain users. LIPKey and anonymous SPKM-3 are easy to set up and quick to deploy, even on large networks, without compromising the main security of GSS (although the anonymous part of either protocol does come with some problems, such as anonymous SPKM not doing any sort of client-side security checks). It would also be a huge asset if the implementation of this protocol turns out to be faster and more performing than Kerberos v5 (which it is not at the moment). Although we have a basic release of LIPKey, our implementation is still a work in progress, and depending on what spec change is proposed, it should be straight-forward to make it compatible with what we have so far. There will be exceptions, but I shall deal with those when they arise, and I still maintain that it is possible to adapt it to anything. -razvan _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Fri Oct 13 16:24:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYTaJ-0003PC-S6; Fri, 13 Oct 2006 16:24:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYTaJ-0003P2-4m for spkm@ietf.org; Fri, 13 Oct 2006 16:24:47 -0400 Received: from web31814.mail.mud.yahoo.com ([68.142.206.167]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GYTaB-0003JT-SJ for spkm@ietf.org; Fri, 13 Oct 2006 16:24:47 -0400 Received: (qmail 98927 invoked by uid 60001); 13 Oct 2006 19:57:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ejJ2RrXP+CJZD397+USGdFDBfWJVxmp4oFPRhN9nrFqLGWbIJXEJP4SQBW8IqfWerhc70s0ibRihJ/En2S7z5O3WayYoqU18REiVC/IUFYpuQzpKMkhxbM2tmn2v1FunQYW8qAzUQxcEXUc2KawGyQAMohnFSiGUmSNPT2Fr7OE= ; Message-ID: <20061013195758.98923.qmail@web31814.mail.mud.yahoo.com> Received: from [198.95.226.224] by web31814.mail.mud.yahoo.com via HTTP; Fri, 13 Oct 2006 12:57:58 PDT Date: Fri, 13 Oct 2006 12:57:58 -0700 (PDT) From: Mike Eisler Subject: Re: [SPKM] Re: [67th IETF] SPKM3 BOF announcement To: spkm@ietf.org In-Reply-To: <20061012193543.GI12284@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org > I'd like to think that the individual submission path should be > workable > for security area work. In particular I think neither an SPKM-4/5 > nor a > DTLS based GSS mechanism should require forming a WG. And if there Well if sufficient numbers of people want to form a WG, and if IESG accepts, then whether or not individual submissions work is irrelevant. I like WGs because the related I-Ds are collected in one place in the WG web page and I don't have to organize it: IETF's web masters organize it. I like WGs because there is a physical forum every 4 months for people to meet, rather than me having to arrange with the local Holiday Inn for a conference room (it's worth the $700 or so I pay IETF 3X a year to arrange all this). Etc. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Fri Oct 13 16:58:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYU6g-0004vk-1i; Fri, 13 Oct 2006 16:58:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYU6e-0004va-3s for spkm@ietf.org; Fri, 13 Oct 2006 16:58:12 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYU6a-00014U-Lj for spkm@ietf.org; Fri, 13 Oct 2006 16:58:12 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9DKw8bL010275 for ; Fri, 13 Oct 2006 13:58:08 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k9DKw7A4025690 for ; Fri, 13 Oct 2006 14:58:07 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9DKw791016002; Fri, 13 Oct 2006 15:58:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9DKw6Y3016001; Fri, 13 Oct 2006 15:58:06 -0500 (CDT) Date: Fri, 13 Oct 2006 15:58:06 -0500 From: Nicolas Williams To: Mike Eisler Subject: Re: [SPKM] Re: [67th IETF] SPKM3 BOF announcement Message-ID: <20061013205806.GC12284@binky.Central.Sun.COM> References: <20061012193543.GI12284@binky.Central.Sun.COM> <20061013195758.98923.qmail@web31814.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061013195758.98923.qmail@web31814.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Fri, Oct 13, 2006 at 12:57:58PM -0700, Mike Eisler wrote: > > I'd like to think that the individual submission path should be > > workable for security area work. In particular I think neither an > > SPKM-4/5 nor a DTLS based GSS mechanism should require forming a WG. > > And if there > > Well if sufficient numbers of people want to form a WG, and > if IESG accepts, then whether or not individual submissions work > is irrelevant. Yes, BoFs can result in no WG formation, even if there is sufficient interest. > I like WGs because the related I-Ds are collected in one place in > the WG web page and I don't have to organize it: IETF's web masters > organize it. I like WGs because there is a physical forum every > 4 months for people to meet, rather than me having to > arrange with the local Holiday Inn for a conference room (it's > worth the $700 or so I pay IETF 3X a year to arrange > all this). Etc. WGs aren't free though. And lack of WGs does not preclude having working meetings at IETF conferences for disucssing individual submissions. One possible addition to the potential charter of an SPKM WG that might help foster WG formation would be this item from the KITTEN WG charter: o Guidelines for GSS-API mechanism designers Since KITTEN has not gotten around to that item, and since that item seems rather relevant to this SPKM effort, it makes sense to consider moving it to any WG that results from this BoF. Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Fri Oct 13 17:37:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYUiy-0005l8-0M; Fri, 13 Oct 2006 17:37:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYUiu-0005fN-Pk for spkm@ietf.org; Fri, 13 Oct 2006 17:37:44 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYUXt-0000Zo-7A for spkm@ietf.org; Fri, 13 Oct 2006 17:26:22 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9DLQKs8007788 for ; Fri, 13 Oct 2006 15:26:20 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k9DLQJVn009116 for ; Fri, 13 Oct 2006 15:26:20 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9DLQJNf016036; Fri, 13 Oct 2006 16:26:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9DLQJ3F016035; Fri, 13 Oct 2006 16:26:19 -0500 (CDT) Date: Fri, 13 Oct 2006 16:26:19 -0500 From: Nicolas Williams To: Razvan Trufasiu Subject: Re: [SPKM] Re: [67th IETF] SPKM3 BOF announcement Message-ID: <20061013212618.GD12284@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "'William A.\(Andy\) Adamson'" , Dan Trufasiu , "'spkm@ietf.org'" , 'Olga Kornievskaia' X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Thu, Oct 12, 2006 at 06:36:07PM -0400, Razvan Trufasiu wrote: > My name is Razvan Trufasiu, and I am in charge of developing an > SPKM-3/LIPKey implementation for the Hummingbird NFS Maestro server. Excellent. Nice to meet you. > At the moment, Hummingbird NFSv4 implementation supports anonymous SPKM-3 > and LIPKey, and the next version will hopefully implement mutual SPKM-3. Any > of these are based upon the specs released in early 2006. The specs have > already changed, from my understanding; however, updating the code to > support this should be simple. For interoperability, currently Olga and I > managed to run several Connectathon tests successfully, without Integrity or > Privacy. We can connect (tentatively) with Integrity, and are working on > being able to connect with Privacy, and run all the tests. There are several > problems we are currently still addressing. You may want to adapt Microsoft's GSS-MONGER test suite. The Connectathon tests test NFS use of GSS-API mechanisms, but lack a thourough test of GSS mechanisms vis-a-vis the GSS-APIv2u1. I believe Martin Rex has a test suite that you might be able to get access too. > The reason we have chosen to implement SPKM-3 or LIPKey is to provide an > alternative GSS implementation to Kerberos v5. I'm with you. > Kerberos is often difficult > to set up, and the overhead of having a separate Kerberos server, in > addition to the NFS client/server can be cumbersome for certain users. I don't think this is the reason for wanting other mechanisms. But it doesn't matter -- I agree that mechanisms based on credential types other than Kerberos V tickets are desirable. > LIPKey and anonymous SPKM-3 are easy to set up and quick to deploy, even on > large networks, without compromising the main security of GSS (although the > anonymous part of either protocol does come with some problems, such as > anonymous SPKM not doing any sort of client-side security checks). It would > also be a huge asset if the implementation of this protocol turns out to be > faster and more performing than Kerberos v5 (which it is not at the moment). There is the matter of distributing trust anchors, CRLs/OCSP, etc... I don't think mechanism performance is an issue here. SPKM performance should be roughly comparable to TLS, SSHv2, etc... Given its use of public key cryptographic it certainly could not be much faster than existing secure protocols that also use public key cryptographic. Given use of PKIX then there's the whole CRL/OCSP ball of wax too, that can impact performance. Yes, some Kerberos V implementations suffer from, for example, poorly performing replay caches, which SPKM-3 should not need, so there's always a possibility that some SPKM-3 implementations could be faster than certain Kerberos V mechanism implementations. Bottom-line: SPKM isn't needed for performance reasons. Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Wed Oct 25 17:06:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcpwn-0004Uw-7k; Wed, 25 Oct 2006 17:06:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcpwm-0004Ug-7c for spkm@ietf.org; Wed, 25 Oct 2006 17:06:00 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcpwX-0003av-7b for spkm@ietf.org; Wed, 25 Oct 2006 17:06:00 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k9PJwOTK022611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Oct 2006 15:58:25 -0400 (EDT) Date: Wed, 25 Oct 2006 15:58:25 -0400 From: Jeffrey Hutzelman To: spkm@ietf.org Message-ID: Originator-Info: login-token=Mulberry:01sRsuTBuDo8D9ZqbN5Jleu0iNZXc4T6cekFyx55s=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Jeffrey Hutzelman Subject: [SPKM] SPKM BOF Agenda X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Greetings... Sam has asked me to chair the SPKM BOF at IETF 67. The main purpose of a BOF is normally to determine whether there is sufficient interest within the IETF to form a working group to address a particular problem, and to come to some agreement on the scope and goals of that work. Not all BOF's result in the formation of working groups -- sometimes there is not sufficient interest or there is no consensus on how to proceed -- but even in these cases, the BOF serves its purpose. In order to achieve that purpose, the majority of time in a BOF is spent on presentations of the problem to be solved, followed by any existing work or proposed approaches, followed by discussion of how to proceed. Sometimes these discussions are highly contentions; other times they are quite straightforward. However, in general they are focused not on the design details, but on higher-level issues such as - whether the proposed work is appropriate for the IETF - whether it is a useful application of the IETF's resources - whether there is interest in pursuing the work - whether the work should focus on a specific solution, or select from among multiple alternatives, or work on more than one approach - in what ways the work should be constrained We need to focus first on that discussion, because that is what will be needed for the AD's and the IESG to decide whether there is sufficient support to form a working group. However, this will be a fairly long meeting slot, so it is possible there will be time left at the end which can be used for more detailed technical discussion. I've posted a preliminary agenda on the IETF web site, at Comments are welcome, of course. I expect most of the interest will be focused on Andy's draft. However, in the interest of producing the best possible result, there is time in the agenda to hear other proposals. Anyone wanting to make such a proposal should be prepared to give a presentation during the BOF; please contact me by November 1 so I can put you on the agenda. Note that the time for alternate proposals is now, not later -- if there do not appear to be any serious proposals at the time of the BOF, it is unlikely that the charter of any resulting WG would include investigating alternate approaches. -- Jeff _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Mon Oct 30 22:38:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GekS2-0000vF-Na; Mon, 30 Oct 2006 22:38:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GekS1-0000t8-NK for spkm@ietf.org; Mon, 30 Oct 2006 22:38:09 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GekRx-0007Oq-0b for spkm@ietf.org; Mon, 30 Oct 2006 22:38:09 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 9B3595C01E for ; Mon, 30 Oct 2006 19:41:05 -0800 (PST) To: spkm@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Mon, 30 Oct 2006 19:38:04 -0800 From: Eric Rescorla Message-Id: <20061031034105.9B3595C01E@laser.networkresonance.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Subject: [SPKM] Comments on draft-adamson-rfc2847-bis-01 X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org $Id: draft-adamson-rfc2487-bis-01-rev.txt,v 1.2 2006/10/30 22:47:13 ekr Exp $ BACKGROUND This document describes two new GSS mechanisms: - SPKM-3 -- an asymmetric key-based handshake and token protection scheme. - LIPKEY -- a client-side password based authentication scheme with server authentication via certificates. LIPKEY is a wrapper around SPKM-3. GENERAL COMMENTS 1. Algorithms Many of the algorithms described in this document should be replaced with more modern algorithms. For message integrity, this document specifies: HMAC-MD5 MD5/RSA SHA1/RSA DSA/SHA1 DES-MAC MD5-DES-CBC SUM64-DES-CBC The only ones of these algorithms that are appropriate for new standards are SHA1/RSA and DSA/SHA-1. Wang et al.'s results clearly imply that MD5 should be deprecated in all signature contexts and Kim et al's results [0] suggest that HMAC-MD5 at least shouldn't be put into new systems. HMAC-SHA1 is the appropriate replacement. For confidentiality, this document specifies: AES256-CBC AES128-CBC DES-EDE3-CBC cast5CBC These are probably all fine, but there's really no longer any reason to include CAST. It also appears that somehow DES-CBC is allowed. That's really not OK. The OWF specified here is simply SHA-1 with the inputs concatenated. Modern KDF designs almost always have the key being a separate input value. E.g., HMAC-SHA1(key, seed....). I suggest copying the TLS PRF, the IPsec KDF, or the NIST 800-56A KDF. 2. Incomplete specification In a number of cases, the only documentation for fields is cursory comments in the ASN.1. Every field should be explained in the main body of the text. 3. MAC/signature overloading In this document, symmetric MAC algorithms and asymmetric signature algorithms are used semi-interchangeably. That's a dangerous practice which tends to lead to confusion and brittle designs. AFAICT, the signature algorithm is used to authenticate the peers and the MAC algorithm is used to authenticate data packets. Is there really any need to *sign* data packets? If there is, it should be provided with a separate facility, esp. since the current design provides no way for one side to ask for a signature on specific packets and indeed discourages negotiating it (see S 2.3.1). 4. Multiple Negotiated algorithms This mechanism seems to result in negotiating the intersection of the acceptable algorithm sets. Why not just choose one algorithm and stick with it like IPsec and TLS do? This seems like it has obvious downgrade problems. DETAILED COMMENTS S 2.1. A ladder diagram of the protocol flows would really help here. S 2.3.2. A GSS mechanism need not support confidentiality. Making a confidentiality algorithm mandatory may preclude exportability of the mechanism implementation; this document therefore specifies certain Exportability hasn't been a major concern for quite some time. S 2.3.3. I don't understand how you upgrade to stronger groups, since the initiator sends its DH share before it talks to the server. How would you upgrade to ECC, for instance? S 2.4.1.1. Conf-Algs ::= CHOICE { algs [0] SEQUENCE OF AlgorithmIdentifier, null [1] NULL, -- used when conf. is not available over context ... } Why not just allow an empty sequence instead of NULL? If the SPKM-3 implementation supports an algorithm weaker than cast5CBC, cast5CBC MUST be listed before the weaker algorithm to encourage the target to negotiate the stronger algorithm. You shouldn't be specifying any algorithms weaker than cast5CBC. S 2.4.1.2. REP-TI-TOKEN ::= SEQUENCE { rep-ti-contents Rep-ti-contents, algId AlgorithmIdentifier, -- should be one of the digital signature algorithms rep-ti-integ Integrity, -- "token" is Rep-ti-contents ... } Is there some way for the peer to express which digital signature algorithms he wants? I don't see it. key-estb-id AlgorithmIdentifier OPTIONAL, -- used if target is changing key estb. algorithm (MUST be -- a member of initiators key-estb-set) I don't understand how this could happen. S 2.4.2.2. md5WithRsaEncryption is currently stipulated for the signing of context establishment tokens. Discrepancies involving modulus bitlength can be resolved through judicious use of the SPKM-GSS-ERROR token. The context initiator signs REQ-TOKEN using the strongest RSA it supports (e.g., 1024 bits). If the target is unable to verify signatures of this length, it sends SPKM-GSS- ERROR signed with the strongest RSA that it supports (e.g. 512). Furthermore, the target can include an appropriate minor_status value (GSS_SPKM_S_SG_WEAK_KEY). How does this work if the target has a key too big for the initiator and you're in anonymous mode? S 2.4.3.1. SPKM-MIC ::= SEQUENCE { mic-header Mic-Header, int-cksum BIT STRING, -- Checksum over header and data, calculated according to -- algorithm specified in int-alg field. ... } The word "checksum" really isn't appropriate here. As noted previously, I think it's a mistake to treat MACs and signatures as the same thing, but if you must, the right term here is "Message Integrity Check" (MIC). Mic-Header ::= SEQUENCE { tok-id INTEGER (257), -- shall contain 0101 (hex) context-id Random-Integer, int-alg [0] AlgorithmIdentifier OPTIONAL, -- Integrity algorithm indicator (MUST be one of the agreed -- integrity algorithms for this context). -- field not present = default id. snd-seq [1] SeqNum OPTIONAL, -- sequence number field. ... } Allowing switch-hitting of integrity algorithms seems problematic, since it basically forces one side to receive packets with the lowest jointly acceptable algorithm. Better to let the negotiation pick the single best one. S 2.8. I don't understand the bit about the algorithm numbers being specified by the mechanism specification. Is that this document? This may be obvious to people steeped in GSS, but a little more explanation might help. The weak/medium/strong values here are quite out of date. 40 bits is laughably weak. We should be deprecating these algorithms entirely. For the Confidentiality MA field: 0001 (1) = DES-CBC 0010 (2) = cast5CBC 0011 (3) = aes256-CBC I don't understand what happened to e.g., AES-128.... S 3. Slightly more introductory text here might help. E.g., LIPKEY provides a mechanism for having target authentication via certificates and client authentication via passwords. LIPKEY is a wrapper around SPKM-3. [0] http://eprint.iacr.org/2006/187 -Ekr _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Tue Oct 31 12:08:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gex6P-0001Uh-E5; Tue, 31 Oct 2006 12:08:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gex6M-0001UR-PW; Tue, 31 Oct 2006 12:08:39 -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 1Gex6I-0007sr-HG; Tue, 31 Oct 2006 12:08:38 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id C2C43E0035; Tue, 31 Oct 2006 12:08:25 -0500 (EST) From: Sam Hartman To: tls@ietf.org,spkm@ietf.org Date: Tue, 31 Oct 2006 12:08:25 -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: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [SPKM] DTLS and GSS-API X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Monday morning at IETF 67 there is a really important BOF: SPKM. The purpose of this BOF is to decide how we will get a standards track solution for NFSV4 to use PKI credentials. Two modes are important: a mode where both parties have credentials and a mode where the server has a certificate and the client has a password. The current proposal is based off draft-adamson-rfc2847-01.txt. Several reviewers including Eric Rescorla and myself have expressed concerns about this draft. An alternate proposal for solving this problem was discussed in the past: construct a GSS-API mechanism based on DTLS. Advantages of this solution include reuse of code and specification between GSS-API and TLS implementations. When new ciphers are specified for TLS they would be available for NFS. We would not need to keep updating a GSS mechanism as public-key algorithms evolve and problems are found. There are two main drawbacks I've heard to the DTLS proposal. First, we don't have a draft. Second, it would not be interoperable with SPKM-3 deployments. I hope the BOF will answer the question of how much we care about SPKM-3 deployments. I only want to see one standards track solution in this space. Currently, there does not seem to be enough interest in the DTLS proposal for it to be a viable alternative. I would like to encourage the TLS community to take a look at draft-adamson-rfc2847-01 and to consider how a DTLS approach would work and think about whether advocating for such an approach would be a good idea. If so, someone at least needs to be prepared to give a brief presentation by next Monday on such a proposal. The BOF chair wanted to hear about anyone giving an alternative presentation by Wednesday of this week. I'm hoping he will be a bit flexible as I was supposed to write this message last Friday. Thanks for your consideration, --Sam _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Tue Oct 31 14:24:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezDX-00040O-2I; Tue, 31 Oct 2006 14:24:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezDU-00040I-OT for spkm@ietf.org; Tue, 31 Oct 2006 14:24:08 -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 1GezDQ-0000Kw-Gm for spkm@ietf.org; Tue, 31 Oct 2006 14:24:08 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 303B6E0035; Tue, 31 Oct 2006 14:23:50 -0500 (EST) From: Sam Hartman To: spkm@ietf.org Date: Tue, 31 Oct 2006 14:23:50 -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: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [SPKM] Interoperability X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Hi. I think one of the most important outcomes of the BOF is likely to be an understanding of what level of interoperability is required between the existing SPKM RFC and our solution to the NFS V4 problem and what pressures there are to minimize change to the spec. First, if we break interoperability, we're changing the OID. If we're not sure we're maintaining interoperability we're changing the OID. RPC supports a mechanism for advertizing GSS mechanisms and so the cost of changing the OID is relatively low. Servers and clients that want to implement both mechanisms can do so. Here are some questions to think about: * What deployed production code is out there that either interoperates with the RFC or draft-adamson? * Can we meet our security and other requirements without making backward incompatible changes and forcing an OID change? * Going forward, can we obtain a simpler spec or implementation by making non-backward compatible changes? * When will we get a spec out? How long will the market wait? Sometimes, you have to accept that the market will deploy something and you have little influence on it. In those cases it's better to write a compelling spec and hope that people will migrate. Other times, if you can stretch to meet market timing, you can avoid the market deploying something that does not meet your spec. That is very desirable. * Which will take longer: fixing this spec or starting from scratch? --Sam _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Tue Oct 31 15:45:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0UM-0005iN-Bq; Tue, 31 Oct 2006 15:45:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0UJ-0005hY-RU; Tue, 31 Oct 2006 15:45:36 -0500 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0U7-00070U-Im; Tue, 31 Oct 2006 15:45:35 -0500 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k9VKjMkY004344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Oct 2006 15:45:22 -0500 (EST) Date: Tue, 31 Oct 2006 15:45:22 -0500 From: Jeffrey Hutzelman To: Sam Hartman , tls@ietf.org, spkm@ietf.org Subject: Re: [SPKM] DTLS and GSS-API Message-ID: <5E206FAE251CBE7B8BF76672@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01hHBpsu7Y3ibQu+Ezt+6ZIRvioN0LpOLx5ZcXuvA=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Jeffrey Hutzelman X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Tuesday, October 31, 2006 12:08:25 PM -0500 Sam Hartman wrote: > The BOF chair wanted to hear about anyone giving an alternative > presentation by Wednesday of this week. I'm hoping he will be a bit > flexible as I was supposed to write this message last Friday. Sooner is better, but if I have a message in my inbox when I get off of the train on Sunday morning, I'll be happy. Note that I will need slides by Monday evening, so I can put them up on the IETF web site before the BOF begins. -- Jeff _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Tue Oct 31 16:10:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0sQ-000500-Sm; Tue, 31 Oct 2006 16:10:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0sO-0004z2-Jk for spkm@ietf.org; Tue, 31 Oct 2006 16:10:29 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0sI-0000o6-Km for spkm@ietf.org; Tue, 31 Oct 2006 16:10:26 -0500 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9VLAMfu015443 for ; Tue, 31 Oct 2006 14:10:22 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k9VLALZM001192 for ; Tue, 31 Oct 2006 14:10:21 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9VLAKrl022365; Tue, 31 Oct 2006 15:10:21 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9VLAKvj022364; Tue, 31 Oct 2006 15:10:20 -0600 (CST) Date: Tue, 31 Oct 2006 15:10:20 -0600 From: Nicolas Williams To: Sam Hartman Subject: Re: [SPKM] Interoperability Message-ID: <20061031211019.GS28107@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Tue, Oct 31, 2006 at 02:23:50PM -0500, Sam Hartman wrote: > First, if we break interoperability, we're changing the OID. If we're > not sure we're maintaining interoperability we're changing the OID. I am not sure that the draft as it stands maintains interop with the imaginary implementations of the original SPKM-3. Unless others can explain that it does, in fact, do this, then that means we're changing the OID. > RPC supports a mechanism for advertizing GSS mechanisms and so the > cost of changing the OID is relatively low. Servers and clients that > want to implement both mechanisms can do so. Indeed. Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Tue Oct 31 16:12:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0uj-0005aE-4L; Tue, 31 Oct 2006 16:12:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0ug-0005Yo-F6 for spkm@ietf.org; Tue, 31 Oct 2006 16:12:50 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0ud-0000z6-RT for spkm@ietf.org; Tue, 31 Oct 2006 16:12:50 -0500 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9VLCld8014012 for ; Tue, 31 Oct 2006 14:12:47 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k9VLCl7P002389 for ; Tue, 31 Oct 2006 14:12:47 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9VLCkVG022374; Tue, 31 Oct 2006 15:12:46 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9VLCksG022373; Tue, 31 Oct 2006 15:12:46 -0600 (CST) Date: Tue, 31 Oct 2006 15:12:46 -0600 From: Nicolas Williams To: Sam Hartman Subject: Re: [SPKM] Interoperability Message-ID: <20061031211246.GT28107@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Tue, Oct 31, 2006 at 02:23:50PM -0500, Sam Hartman wrote: > * When will we get a spec out? How long will the market wait? > Sometimes, you have to accept that the market will deploy something > and you have little influence on it. In those cases it's better to > write a compelling spec and hope that people will migrate. Other > times, if you can stretch to meet market timing, you can avoid the > market deploying something that does not meet your spec. That is > very desirable. If we cannot get a spec that will meet our needs in time for the market then the proposed protocol could go to Informational and a spec that does meet our needs can later go to Proposed-Standard, using a different OID. Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Tue Oct 31 16:15:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0wt-0007yg-9y; Tue, 31 Oct 2006 16:15:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0wp-0007vg-O2; Tue, 31 Oct 2006 16:15:04 -0500 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0wo-0001Cg-Aq; Tue, 31 Oct 2006 16:15:03 -0500 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9VLF169010661; Tue, 31 Oct 2006 13:15:01 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9VLF13Z003380; Tue, 31 Oct 2006 14:15:01 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9VLF1Aw022381; Tue, 31 Oct 2006 15:15:01 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9VLF186022380; Tue, 31 Oct 2006 15:15:01 -0600 (CST) Date: Tue, 31 Oct 2006 15:15:00 -0600 From: Nicolas Williams To: Sam Hartman Subject: Re: [SPKM] DTLS and GSS-API Message-ID: <20061031211500.GU28107@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: tls@ietf.org, spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Tue, Oct 31, 2006 at 12:08:25PM -0500, Sam Hartman wrote: > The BOF chair wanted to hear about anyone giving an alternative > presentation by Wednesday of this week. I'm hoping he will be a bit > flexible as I was supposed to write this message last Friday. I will have a presentation on a DTLS-based GSS mechanism in time for the meeting. However, I will only be able to participate via jabber. Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Tue Oct 31 16:19:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf10w-00045t-Js; Tue, 31 Oct 2006 16:19:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf10t-00045H-M6 for spkm@ietf.org; Tue, 31 Oct 2006 16:19:17 -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 1Gf10r-0001Yp-LB for spkm@ietf.org; Tue, 31 Oct 2006 16:19:15 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 23628E0035; Tue, 31 Oct 2006 16:19:05 -0500 (EST) From: Sam Hartman To: Nicolas Williams Subject: Re: [SPKM] Interoperability References: <20061031211246.GT28107@binky.Central.Sun.COM> Date: Tue, 31 Oct 2006 16:19:04 -0500 In-Reply-To: <20061031211246.GT28107@binky.Central.Sun.COM> (Nicolas Williams's message of "Tue, 31 Oct 2006 15:12:46 -0600") 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: 93238566e09e6e262849b4f805833007 Cc: spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Tue, Oct 31, 2006 at 02:23:50PM -0500, Sam Hartman Nicolas> wrote: >> * When will we get a spec out? How long will the market wait? >> Sometimes, you have to accept that the market will deploy >> something and you have little influence on it. In those cases >> it's better to write a compelling spec and hope that people >> will migrate. Other times, if you can stretch to meet market >> timing, you can avoid the market deploying something that does >> not meet your spec. That is very desirable. Nicolas> If we cannot get a spec that will meet our needs in time Nicolas> for the market then the proposed protocol could go to Nicolas> Informational and a spec that does meet our needs can Nicolas> later go to Proposed-Standard, using a different OID. Yes. I don't consider it a failure if the market has to do something while we work on a spec. I will not sponsor this as informational, but nothing stops the authors from going to the rfc editor. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Tue Oct 31 16:44:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1PR-0002WQ-Go; Tue, 31 Oct 2006 16:44:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1Or-0002Eg-Hq for spkm@ietf.org; Tue, 31 Oct 2006 16:44:01 -0500 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf1CN-0002dL-Od for spkm@ietf.org; Tue, 31 Oct 2006 16:31:09 -0500 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9VLV7AK009425 for ; Tue, 31 Oct 2006 13:31:07 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k9VLV6cx010626 for ; Tue, 31 Oct 2006 14:31:06 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9VLV6e7022398; Tue, 31 Oct 2006 15:31:06 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9VLV6gK022397; Tue, 31 Oct 2006 15:31:06 -0600 (CST) Date: Tue, 31 Oct 2006 15:31:06 -0600 From: Nicolas Williams To: Sam Hartman Subject: Re: [SPKM] Interoperability Message-ID: <20061031213105.GV28107@binky.Central.Sun.COM> References: <20061031211246.GT28107@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Tue, Oct 31, 2006 at 04:19:04PM -0500, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Tue, Oct 31, 2006 at 02:23:50PM -0500, Sam Hartman > Nicolas> wrote: > >> * When will we get a spec out? How long will the market wait? > >> Sometimes, you have to accept that the market will deploy > >> something and you have little influence on it. In those cases > >> it's better to write a compelling spec and hope that people > >> will migrate. Other times, if you can stretch to meet market > >> timing, you can avoid the market deploying something that does > >> not meet your spec. That is very desirable. > > Nicolas> If we cannot get a spec that will meet our needs in time > Nicolas> for the market then the proposed protocol could go to > Nicolas> Informational and a spec that does meet our needs can > Nicolas> later go to Proposed-Standard, using a different OID. > > Yes. > I don't consider it a failure if the market has to do something while we work on a spec. > > I will not sponsor this as informational, but nothing stops the > authors from going to the rfc editor. Right. I think this is a possible outcome of the BoF. Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Tue Oct 31 17:11:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1pI-0003wK-8a; Tue, 31 Oct 2006 17:11:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1hx-0005ZM-5U; Tue, 31 Oct 2006 17:03:45 -0500 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf1hq-0006HB-Jd; Tue, 31 Oct 2006 17:03:45 -0500 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.665.7; Tue, 31 Oct 2006 14:03:34 -0800 Received: from IGT-HUB-01.redmond.corp.microsoft.com ([157.54.69.154]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 31 Oct 2006 14:03:34 -0800 Received: from tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) by IGT-HUB-01.redmond.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2786); Tue, 31 Oct 2006 14:03:33 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.5; Tue, 31 Oct 2006 14:03:33 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 31 Oct 2006 14:03:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Oct 2006 14:02:32 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] DTLS and GSS-API Thread-Index: Acb9D/YDziFLQ/yXR1CKfbjIbuT32gAJ/1Gg From: "Liqiang(Larry) Zhu" To: Sam Hartman , , X-OriginalArrivalTime: 31 Oct 2006 22:03:30.0664 (UTC) FILETIME=[66853680:01C6FD38] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-Mailman-Approved-At: Tue, 31 Oct 2006 17:11:16 -0500 Cc: Subject: [SPKM] RE: [TLS] DTLS and GSS-API X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org We have a different proposal for this problem space, it is PKU2U, It is similar to PKTAPP, except it does NOT use port 88. It is similar to DTLS, in that it can use certificates. It is a GSS-API mechanism because it just uses RFC4121. I will have a draft ready by this coming Monday, and we have a proto-type of PKU2U. We will have a short presentation for this proposal this coming Monday. -- Larry -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 Sent: Tuesday, October 31, 2006 9:08 AM To: tls@ietf.org; spkm@ietf.org Subject: [TLS] DTLS and GSS-API Monday morning at IETF 67 there is a really important BOF: SPKM. The purpose of this BOF is to decide how we will get a standards track solution for NFSV4 to use PKI credentials. Two modes are important: a mode where both parties have credentials and a mode where the server has a certificate and the client has a password. The current proposal is based off draft-adamson-rfc2847-01.txt. Several reviewers including Eric Rescorla and myself have expressed concerns about this draft. An alternate proposal for solving this problem was discussed in the past: construct a GSS-API mechanism based on DTLS. Advantages of this solution include reuse of code and specification between GSS-API and TLS implementations. When new ciphers are specified for TLS they would be available for NFS. We would not need to keep updating a GSS mechanism as public-key algorithms evolve and problems are found. There are two main drawbacks I've heard to the DTLS proposal. First, we don't have a draft. Second, it would not be interoperable with SPKM-3 deployments. I hope the BOF will answer the question of how much we care about SPKM-3 deployments. I only want to see one standards track solution in this space. Currently, there does not seem to be enough interest in the DTLS proposal for it to be a viable alternative. I would like to encourage the TLS community to take a look at draft-adamson-rfc2847-01 and to consider how a DTLS approach would work and think about whether advocating for such an approach would be a good idea. If so, someone at least needs to be prepared to give a brief presentation by next Monday on such a proposal. The BOF chair wanted to hear about anyone giving an alternative presentation by Wednesday of this week. I'm hoping he will be a bit flexible as I was supposed to write this message last Friday. Thanks for your consideration, --Sam _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Tue Oct 31 17:39:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf2Gd-0004ao-Gn; Tue, 31 Oct 2006 17:39:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf2GW-0004TU-90; Tue, 31 Oct 2006 17:39:30 -0500 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf2GR-0001ax-Ja; Tue, 31 Oct 2006 17:39:28 -0500 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9VMdMvY019686; Tue, 31 Oct 2006 14:39:23 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9VMdMRd023167; Tue, 31 Oct 2006 15:39:22 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k9VMdL9G022458; Tue, 31 Oct 2006 16:39:21 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k9VMdLrB022457; Tue, 31 Oct 2006 16:39:21 -0600 (CST) Date: Tue, 31 Oct 2006 16:39:21 -0600 From: Nicolas Williams To: "Liqiang(Larry) Zhu" Subject: Re: [SPKM] RE: [TLS] DTLS and GSS-API Message-ID: <20061031223920.GZ28107@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Sam Hartman , tls@ietf.org, spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Tue, Oct 31, 2006 at 02:02:32PM -0800, Liqiang(Larry) Zhu wrote: > We have a different proposal for this problem space, it is PKU2U, > > It is similar to PKTAPP, except it does NOT use port 88. > > It is similar to DTLS, in that it can use certificates. > > It is a GSS-API mechanism because it just uses RFC4121. Does it re-use the Kerberos V mechanism OID? IMO this is a new mechanism and needs a new OID. IMO you still have naming issues to sort through, but that is true whether we go with the SPKM, DTLS or PKU2u approaches, and they are definitely solveable. > I will have a draft ready by this coming Monday, and we have a > proto-type of PKU2U. > > We will have a short presentation for this proposal this coming Monday. Excellent, thanks. I look forward to it, Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm