From housley at vigilsec.com Fri Jan 20 10:32:04 2006 From: housley at vigilsec.com (Russ Housley) Date: Fri Jan 20 10:32:45 2006 Subject: [saag] Message on Behalf of RAND Europe Message-ID: <7.0.0.16.2.20060120102902.065f16a8@vigilsec.com> I have agreed to forward this message to the SAAG list. Please respond directly to Lorenzo Valeri (lvaleri@rand.org) if you have any interest. I do not expect to discuss the content of this message on this mail list. Russ = = = = = = = = = RAND Europe has been asked by the European Commission to undertake a study into the Security Challenges to the Use and Deployment of Disruptive Technologies. The study will focus on implementations of five 'disruptive' technologies, listed below. Disruptive technologies can be defined as a new technology that unexpectedly displaces an established technology. The technologies under review are: * Radio Frequency ID (RFID) technology * WiMAX (Wireless Metropolitan Area Networking) * Trusted Computing * Voice over IP (VoIP) * Internet Protocol version 6 (IPv6) The project, which is set to last 6 months, will commence with a Delphi exercise to identify main security challenges associated with these five technologies. The Delphi exercise is expected to inform five case studies, which will be a closer look at specific implementations of each technology. The findings of this work will be discussed during a workshop to be held in Brussels during the last week of May 2006. The aim of the Delphi survey is to identify the security challenges that are associated with these technologies by asking experts in the area what they foresee as the main issues to address. A Delphi survey is a way of forecasting the challenges and likely futures associated with an issue through the knowledge of experts in the field. In the case of the 5 technologies we are studying, this would be based around the sorts of security challenges that face them (either technical, social or economic challenges). The Delphi survey would involved the following two steps: First Part: In the first section, participants are expected to answer the following general question: "What are the key shared security challenges to the use and deployment of the five technologies mentioned above?" Participants would be expected to produce a list and a set of general comments about the challenges they foresee in a concise format (not more than two or three paragraphs per challenge). These will be emailed back to the Lorenzo Valeri (lvaleri@rand.org), senior analyst RAND Europe, who will collate them and remove any duplicate findings or suggestions. Second Part: In the second part of the Delphi survey, RAND Europe will send out a full list of the suggested security challenges to those who have responded and ask them to rate the top ten security challenges from the list and send their list back to us at RAND Europe. This second part is expected to be finish by February 7, 2006. If you are interested in participating, please provide Lorenzo Valeri (lvaleri@rand.org) with two or three paragraphs in response to the First Part question above. These security challenges should cover things like socio-economic, regulatory and economic challenges as well as those relating to privacy, operational risks, and consumer protection. It may be that some challenges are not obviously applicable to all of the technologies listed; however, these may be useful in stimulating discussion on general challenges and should not be overlooked. From tim.polk at nist.gov Thu Jan 26 11:35:03 2006 From: tim.polk at nist.gov (Tim Polk) Date: Thu Jan 26 11:35:24 2006 Subject: [saag] Fwd: The Second Cryptographic Hash Workshop Call for Participation Message-ID: <5.1.0.14.2.20060126111823.031e7720@email.nist.gov> Folks, NIST has published the call for papers for our next hash function workshop. The workshop will follow Crypto 2006. I have forwarded the CFP to this group because I believe that IETF involvement is crucial to this project's success. The workshop has three goals: ? Explore potential mathematical principles and structures that can provide the foundation for cryptographic hash functions; ? Foster accelerated research on the analysis of hash functions, especially the SHA-2 hash functions; ? Survey the uses of hash functions, and investigate the properties that are assumed, used, or needed. Identify and articulate the required or desirable properties for future hash functions. To accomplish the third goal, we will need the support and participation of protocol designers in addition to cryptographers. I would strongly encourage the readers of this list to participate in this workshop. We need the benefit of your insights and expertise. Thanks, Tim Polk >X-Sieve: CMU Sieve 2.2 >X-Sender: sjchang@email.nist.gov >X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 >Date: Wed, 25 Jan 2006 15:06:20 -0500 >To: shu-jen.chang@nist.gov >From: Shu-jen Chang >Subject: The Second Cryptographic Hash Workshop Call for Participation >X-NIST-MailScanner: Found to be clean >X-NIST-MailScanner-From: shu-jen.chang@nist.gov > >The Second Cryptographic Hash Workshop >Santa Barbara, CA >August 24-25, 2006 (Starting at 1PM, August 24) >Submission deadline: May 12, 2006 (Workshop without proceedings) > >As a follow-up to the first Cryptographic Hash Workshop held on Oct. >31-Nov. 1, 2005, NIST plans to host a series of public workshops to focus >on hash function research. The next workshop will be held on August >24-25, 2006, in conjunction with Crypto 2006, at UCSB, Santa Barbara. >Attached is the Call for Participation for the Second Cryptographic Hash >Workshop. Details about the workshop will be available at the following >web site shortly: http://www.nist.gov/hash-function > >Shu-jen Chang >Computer Security Division >NIST > -------------- next part -------------- A non-text attachment was scrubbed... Name: Second Cryptographic Hash Workshop CFP.pdf Type: application/pdf Size: 41474 bytes Desc: not available Url : http://jis.mit.edu/pipermail/saag/attachments/20060126/e98c96f9/SecondCryptographicHashWorkshopCFP.pdf From housley at vigilsec.com Fri Jan 27 12:38:43 2006 From: housley at vigilsec.com (Russ Housley) Date: Fri Jan 27 12:38:56 2006 Subject: [saag] International Conference on Network Security 2006 Message-ID: <7.0.0.16.2.20060127123259.062e29f8@vigilsec.com> Please consider responding to this call for participation. Russ = = = = = = = = = The International Conference on Network Security 2006 April 17-19, 2006 Hyatt Regency Reston, Reston, Virginia Call for Presentations The International Conference on Network Security 2006, to be held in Reston, Virginia, April 17-19, is a highly informative and interactive event devoted to the subject of security in networks, applications, and critical information infrastructure. The goal of the conference on Network Security is to facilitate a shift in the current paradigm to a more implementation oriented model for Network and Critical Infrastructure Security. To achieve that goal, the conference will focus on honest analysis and fearless review of current practices and industry standards. Therefore the conference is targeted to those individuals that seek to make a tangible difference in the field of network security. Program Overview The program committee is looking for both novel work as well as overviews covering key practical subjects, new technologies and user experience case studies. The conference program will consist of tutorials, keynote speeches, technical sessions, panel discussions and interactive events addressing contemporary issues. Position papers on controversial issues, and papers that summarize the area, are also solicited. Each area will be presented with a short overview of the state of art in practice and in research, given by a specialist in that area. Some technical sessions that have already been accepted are: - Software Security What paths will lead to software security and what can more clever hardware do for us? Can type-safe languages like Java substantially eliminate exploitable security bugs? - Network Security Protocol Issues What are the important security issues in the Internet infrastructure and protocol implementation? - Trusted Platform How does Trusted Platform work and what problems does it solve? Will/should all computers be built on this technology in the future? - Wireless and Wireline Network Access Security What are the key security issues in the network access based on WiFi, WiMAX, Ad Hoc networks, as well as Broadband? Additional topics that are requested include, but are not limited to: - Surviving Denial of Service - Unintended Consequences of Virus Propagation: Third Party Denial of Service - Smart Cards and Biometrics - Web Browser Security - Network Firewall Control and Configuration - Authentication/authorization/PKI - Deployment challenges of new Internet standards - Security and the quantum/nanotech computing - Certification programs: Are they useful? - Mesh Network Security - Other pertinent issues in Network Security Following the conference, authors of selected presentations will be invited to prepare their manuscript for publication in a special issue of major professional journal. Conference Chair Guy Copeland - Vice President, Information Infrastructure Advisory Programs and Special Assistant to the CEO, at Computer Sciences Corporation Technical Co-chairs - Radia Perlman, Sun Microsystems - Bijan Jabbari, Isocore Technical Committee Members - Gene Spafford, Professor and Executive Director, Purdue University CERIAS - Charlie Kaufman, Security Architect, Microsoft - Andy Ellis, Akamai, InfoSec Chief Security Architect, Senior Director - Hillarie Orman, Chief Technology Officer and Vice-President of Engineering, Shinkuro Inc. - Darren Moffat, Senior Staff Engineer, Solaris Software, Sun Microsystems - Parviz Yegani, Technical Leader, Mobile Wireless Business Unit, Cisco Systems - Russ Housley, Principle Consultant, Vigil Security - Upendra Mardikar, Technical Architect, Pay Pal - Donald Eastlake, Distinguished Member of Technical Staff, Motorola Laboratories - Marcus Leech, Security Standards Advisor, Strategic Standards Group, Nortel - Greg Edwards, Sr. Staff InfoSec Engineer, Lockheed Martin Please send your proposal to the attention of the Technical Program Committee at networksecurity2006-cfp@isocore.com For additional information please visit http://www.networksecurity2006.com or send email to networksecurity2006-info@isocore.com From scott at hyperthought.com Tue Jan 31 05:50:16 2006 From: scott at hyperthought.com (Scott G Kelly) Date: Tue Jan 31 08:50:24 2006 Subject: [saag] [Fwd: I-D ACTION:draft-kelly-saag-des-implications-00.txt] Message-ID: <43DF6B18.6050804@hyperthought.com> Some time ago, Russ Housley asked if someone would write a note for implementers regarding the security implications of using DES. This request derived from a recommendation in http://www.ietf.org/internet-drafts/draft-ietf-newtrk-decruft-experiment-03.txt. Anyway, here's the first cut at the draft. I intend to add an appendix explaining why 3DES is still okay, and someone suggested that maybe DESX should be discussed as well. If you have suggestions or comments, I'm all ears... -------------- next part -------------- An embedded message was scrubbed... From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kelly-saag-des-implications-00.txt Date: Mon, 30 Jan 2006 15:50:02 -0500 Size: 5910 Url: http://jis.mit.edu/pipermail/saag/attachments/20060131/563b23be/draft-kelly-saag-des-implications-00.txt From housley at vigilsec.com Tue Feb 7 22:17:53 2006 From: housley at vigilsec.com (Russ Housley) Date: Tue Feb 7 22:18:03 2006 Subject: [saag] Please review draft-bonica-tcp-auth-04 Message-ID: <7.0.0.16.2.20060207221621.0957bb70@vigilsec.com> A companion document will be coming to define automated key management, but I would like to have several eyes on this document. If you have a few cycles, please review this document. Russ From hartmans-ietf at MIT.EDU Thu Feb 9 20:00:01 2006 From: hartmans-ietf at MIT.EDU (Sam Hartman) Date: Thu Feb 9 20:00:13 2006 Subject: [saag] BCP 61, advancing to draft Message-ID: Hi. I'd like to remind everyone of BCP 61. It says roughly that protocols we approve need a mandatory to implement security mechanism. We here in the security area think that's a great idea. O, by the way, we're here to help you. As part of our plan for world domination^h^h^hhelping you, we've created a number of security solutions including things like SASL, TLS, IPsec, Kerberos, GSS-API, and CMS. We really like it when you use these security services instead of inventing your own. First, it makes it hugely easier for us to review your documents. Second, it makes it easier when we need to do algorithm upgrades to things like hash functions or replace DES with AES. Finally it probably makes your security easier to deploy. There's this littple problem though. All of the above are at proposed standard. For a number of reasons they are not moving to draft as soon as anyone would like. So, I see two options that I don't like. First, we can avoid security in anything going to draft. Draft becomes a dumping ground for all the older protocols (plus a few things like SNMP that invent their own security) without updates that add security. Secondly, we can block everything from going to draft. Does anyone want to work on a better answer to this? --Sam From harald at alvestrand.no Fri Feb 10 10:02:54 2006 From: harald at alvestrand.no (Harald Tveit Alvestrand) Date: Fri Feb 10 04:03:55 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: References: Message-ID: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> --On 9. februar 2006 20:00 -0500 Sam Hartman wrote: > As part of our plan for world domination^h^h^hhelping you, we've > created a number of security solutions including things like SASL, > TLS, IPsec, Kerberos, GSS-API, and CMS. We really like it when you > use these security services instead of inventing your own. First, it > makes it hugely easier for us to review your documents. Second, it > makes it easier when we need to do algorithm upgrades to things like > hash functions or replace DES with AES. Finally it probably makes > your security easier to deploy. > > > There's this littple problem though. All of the above are at proposed > standard. > > For a number of reasons they are not moving to draft as soon as anyone > would like. Care to elaborate? > So, I see two options that I don't like. First, we can avoid security > in anything going to draft. Draft becomes a dumping ground for all > the older protocols (plus a few things like SNMP that invent their own > security) without updates that add security. Secondly, we can block > everything from going to draft. > > Does anyone want to work on a better answer to this? Seems that there are two possible answers: - Move the security stuff to Draft (knocking down the reasons for that not happening one at a time, possibly changing the criteria for Draft on the way) - Abolish Draft I consider the third option - having Draft with downreference to Proposed - to be a Bad Idea. If we have to do that, I'd rather abandon Draft. Harald -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://jis.mit.edu/pipermail/saag/attachments/20060210/ead1e610/attachment.bin From hartmans-ietf at MIT.EDU Fri Feb 10 07:34:33 2006 From: hartmans-ietf at MIT.EDU (Sam Hartman) Date: Fri Feb 10 07:34:55 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> (Harald Tveit Alvestrand's message of "Fri, 10 Feb 2006 10:02:54 +0100") References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Message-ID: >>>>> "Harald" == Harald Tveit Alvestrand writes: >> >> For a number of reasons they are not moving to draft as soon as >> anyone would like. Harald> Care to elaborate? Sure, but this is very much with my AD hat off and with the warning that I'm probably wrong on some of these. SASL: internationalization issues; low number of volunteers dedicating time. Not clear which mechanism to move to draft to validate the framework. IPsec: just moved to proposed again; not many implementations; already needs for clarifications drafts. TLS: Moving to proposed again because of hash mess. Kerberos: Doable, but we're all fairly busy working on meeting new customer needs. We did recently hold a meeting and develop feature matrix and roughly what we'd need to remove from the spec. We were really hoping that RFC 4120 would not need things removed; I think a lot of us lost interest in moving Kerberos to draft any time soon when we found out that was not the case. GSS-API: Needs a mechanism to move to drfat. Kerberos mechanism depends on Kerberos. Everything else needs some significant work on the documentation front that no one is really chartered to do. An individual wanted to do the work and was encouraged to contact an AD when they had a draft; haven't heard from them in months. PKIX: I think has some internationalization issues; possibly some hash fun. Not really sure. CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this was in the best shape. --Sam From rja at extremenetworks.com Fri Feb 10 08:06:27 2006 From: rja at extremenetworks.com (RJ Atkinson) Date: Fri Feb 10 08:06:39 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Message-ID: <5CEC980A-22AC-418F-B5FC-1F262919B6D7@extremenetworks.com> On 10 Feb 2006, at 04:02, Harald Tveit Alvestrand wrote: % Seems that there are two possible answers: % % - Move the security stuff to Draft (knocking down the reasons for that % not happening one at a time, possibly changing the criteria for Draft % on the way) % - Abolish Draft % % I consider the third option - having Draft with downreference to Proposed - % to be a Bad Idea. If we have to do that, I'd rather abandon Draft. I would suggest that in parallel both (1) "move the security stuff to Draft" and (2) "abolish Draft Standard" of Harald's suggestions be undertaken. My guess is that Sam's note was a polite way of trying to "encourage" the security community to undertake (1), but I could be wrong. Security is not the only thing that impedes going to Draft Standard or Full Standard. There is a longish list of things that can impede progression away from Proposed Standard. We have an impressive number of IETF standards-track protocols that have been at Proposed Standard for many many years. Some are widely used, while others are widely ignored. My proposal for a new standards track looks roughly like this: 1) Proposed Standard - Rules exactly as they are to progress to Proposed Standard - No Changes 2) Delete the "Draft Standard" state, but keep the "multiple interoperable implementations" rule and apply that rule to "Full Standard". 3) Require that most Proposed Standards (i.e. those that are not blocked by the failure of some other standard to advance) move to Full Standard within 2 years (edit time to your taste) of publication as a Proposed Standard or 2 years of all normative references moving to Full Standard, whichever comes later. Anything that does not meet that requirement automatically gets reclassified as HISTORIC status unless the IESG grants an exception at the 2 year timeout. IESG exceptions are themselves limited to 2 years. Any IESG exception requires the IESG to publicly say why the exception was granted in the particular case. 4) 3 months after the above changes are approved, any documents already at Draft Standard progress automatically to Full Standard, unless the IESG takes some other action (e.g. move to Historic) on the Draft Standard(s) during the 3 month window just after the process changes are approved. This achieves the following goals: (1) simplifies the standards track greatly, which by itself increases the incentive to advance a document, and (in theory) reduces the workload for the IESG. (2) retains the requirement for demonstrated interoperability before becoming a Full Standard. We all understand why this is important. (3) creates a "timeout" that incents WGs and individuals to progress their documents all the way along to Full Standard, lest the document(s) automatically move to HISTORIC. This timeout period does not start until the document is unblocked by normative references. (4) gives the IESG the power to grant exceptions to the "timeout" for any exceptional cases. Yours, Ran rja@extremenetworks.com From pgut001 at cs.auckland.ac.nz Sat Feb 11 02:13:15 2006 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Fri Feb 10 08:13:58 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: Message-ID: Sam Hartman writes: >>>>>> "Harald" == Harald Tveit Alvestrand writes: > >> > >> For a number of reasons they are not moving to draft as soon as > >> anyone would like. > > Harald> Care to elaborate? > >Sure, but this is very much with my AD hat off and with the warning that I'm >probably wrong on some of these. > >[List snipped] Just looking at this list, is the document-status thing just a case of changing some policy, or is there more to it than that? For example from that list TLS, Kerberos, and CMS have all been around for 10-15 years so it's unlikely that there are going to be major changes in the spec, and in particular that there will be non-backwards-compatible changes. So all you'd need to do is instead of pointing to [RFCxxxx], point to [TLS], where [TLS] is "'The TLS Protocol', version 1.1 or any later version". This is already done by documents like the GPL, which specify use of "version X or any later version" rather than hardcoding in a particular document. Since these protocols stick around for years, even decades (I mean we've only just got around to deprecating the broken SSLv2 protocol after 12 years of use), I can't see any major interop problems turning up. Without this, you end up with horrible priority inversions where some far-distant unfinished spec ends up blocking a major standards effort that needs to refer to it. Peter. From rja at extremenetworks.com Fri Feb 10 08:21:16 2006 From: rja at extremenetworks.com (RJ Atkinson) Date: Fri Feb 10 08:21:23 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Message-ID: <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> On 10 Feb 2006, at 07:34, Sam Hartman wrote: > Sure, but this is very much with my AD hat off and with the warning > that I'm probably wrong on some of these. > > SASL: internationalization issues; low number of volunteers dedicating > time. Not clear which mechanism to move to draft to validate the > framework. So the issue here is multiple-dependency: - SASL can't advance because of the I18N rules - lots of other stuff can't advance because of SASL I'd say that the thing to do is to waive the I18N rule to let SASL go to Draft (with a requirement that I18N issues get addressed before further forward motion) -- then push on the I18N portion of the IETF to pitch in on this. I'm familiar with several languages and from time to time (e.g. MIME) have been involved in I18N discussions in the IETF. However, a big percentage of the IETF are only familiar with one or two languages (polyglots are actually rare in our circles). Those familiar with only one language are not likely to be able to help very much. > IPsec: just moved to proposed again; not many implementations; already > needs for clarifications drafts. One only needs 2 interoperable implementations to move to Draft Standard. If the new spec(s) don't have that, push the implementers to sort out interoperability, find 2 that work, declare victory, and move to Draft. If our current process had been around when TCP was first being specified, implemented, and tested, TCP would have become totally wedged also, IMHO. > TLS: Moving to proposed again because of hash mess. I'd suggest pushing on this one first in a focused way. The hash situation should be very straight-forward to sort out, if the ADs apply time pressure to the group. Adding new hash functions is not technically difficult, though IETF processes can be very difficult these days. > Kerberos: Doable, but we're all fairly busy working on meeting new > customer needs. We did recently hold a meeting and develop feature > matrix and roughly what we'd need to remove from the spec. We were > really hoping that RFC 4120 would not need things removed; I think a > lot of us lost interest in moving Kerberos to draft any time soon when > we found out that was not the case. If the issue is that not all features of 4120 are in at least 2 implementations, there are a couple of approaches. One is to go find a sponsor to fund someone to add the missing feature(s) to either MIT Kerberos or Heimdal. The other is to do what OSPF did with M-OSPF, move the not yet widely implemented (but perceived useful) items into a separate document so the main spec can advance more quickly. (Aside: I still miss having M-OSPF. It worked very well and was very easy to configure and operate. PIM has never come close to being as useful as M-OSPF. Sigh) > GSS-API: Needs a mechanism to move to drfat. Kerberos mechanism > depends on Kerberos. Everything else needs some significant work on > the documentation front that no one is really chartered to do. An > individual wanted to do the work and was encouraged to contact an AD > when they had a draft; haven't heard from them in months. Given that analysis, this is probably not low hanging fruit. > PKIX: I think has some internationalization issues; possibly some hash > fun. Not really sure. > > CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this > was in the best shape. These also don't look like low-hanging fruit. I think TLS is probably the lowest hanging fruit here. IPsec, Kerberos, and SASL come next in a clump. GSS-API, PKIX, and CMS seem pretty high up the tree just now. Just as I believe the security-interested people in the IETF need to pitch in to help other areas advance their specs, I also believe the I18N- interested people in the IETF need to help the security specs so the security area can advance its specs. We are all in this together. Yours, Ran rja@extremenetworks.com From smb at cs.columbia.edu Fri Feb 10 08:29:40 2006 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri Feb 10 08:29:47 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: (Your message of "Fri, 10 Feb 2006 08:21:16 EST.") <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> Message-ID: <20060210132940.6C43D3BFDED@berkshire.machshav.com> In message <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com>, RJ Atkin son writes: > > > >> TLS: Moving to proposed again because of hash mess. > >I'd suggest pushing on this one first in a focused way. The hash >situation should be very straight-forward to sort out, if the ADs >apply time pressure to the group. Adding new hash functions is >not technically difficult, though IETF processes can be very difficult >these days. The issue is not adding the hash functions, it's adding the negotiation to permit their use. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb From pgut001 at cs.auckland.ac.nz Sat Feb 11 02:33:24 2006 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Fri Feb 10 08:33:29 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> Message-ID: RJ Atkinson writes: >> PKIX: I think has some internationalization issues; possibly some hash >> fun. Not really sure. >> >> CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this >> was in the best shape. > >These also don't look like low-hanging fruit. > >I think TLS is probably the lowest hanging fruit here. IPsec, Kerberos, and >SASL come next in a clump. GSS-API, PKIX, and CMS seem pretty high up the >tree just now. And that's the problem - CMS and TLS are both blocked waiting on PKIX (this is what held up TLS at the RFC 2246 stage for what, three years?). Presumably IPsec will also block on PKIX. This is why I proposed the relative- rather than absolute-value reference approach in my previous message. Without this, you get the priority-inversion situation of the lowest-hanging fruit stalled behind the highest-hanging fruit (not to mention appallingly mangled metaphors). Peter. From rja at extremenetworks.com Fri Feb 10 09:08:26 2006 From: rja at extremenetworks.com (RJ Atkinson) Date: Fri Feb 10 09:08:40 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: References: Message-ID: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> On 10 Feb 2006, at 08:33, Peter Gutmann wrote: > And that's the problem - CMS and TLS are both blocked waiting on > PKIX (this is > what held up TLS at the RFC 2246 stage for what, three years?). > Presumably IPsec will also block on PKIX. ESP/AH do not depend on PKIX, and they ought not normatively depend on IKE (or any other automatic key management method), so ESP/AH should be able to move forward without PKIX. Similarly, applications that use ESP/AH, should be able to move forward when ESP/AH move forward, regardless of IKE (or PKIX). The modular design of ESP/AH/ISAKMP/IKE was very deliberate -- because the original designer of ESP/AH fully expected that the key management schemes would need to change (given the past history of Diffie-Hellman and Needham-Schroder in the published history up through 1995). Cheers, Ran From paul.hoffman at vpnc.org Fri Feb 10 06:52:33 2006 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Fri Feb 10 10:02:42 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Message-ID: One big issue we have with security protocols moving to draft is that there is very little volunteer interest in testing SHOULD/MUST interop beyond the basics (if even that). Our protocols have a lot of SHOULDs that have nothing to do with interop and are very difficult to test. But, even without those, the security area has been much less active at voluntary interop testing than other areas, which makes "going to Draft" not appealing. We are generally happy to cycle at Proposed. Sam's message points out a significant ramification of that attitude, although I don't have a proposed solution to the problem. --Paul Hoffman, Director --VPN Consortium From Kurt at OpenLDAP.org Fri Feb 10 07:20:37 2006 From: Kurt at OpenLDAP.org (Kurt D. Zeilenga) Date: Fri Feb 10 10:21:17 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: References: Message-ID: <7.0.1.0.0.20060210070911.03a20128@OpenLDAP.org> I note that just because some dependencies are not yet ready to be progressed to Draft Standard doesn't preclude us from revising protocols as needed to address other issues holding them at Proposed. For instance, with LDAP, we've resolved a host of issues requiring publication of revised LDAP specifications. These will get published at Proposed in conjunction with revised TLS and SASL specs, then pending implementation reports and other requirements, we should get to Draft. I also note that the formal Draft Standard declaration is not nearly as important as resolution of the technical issues that kept us at Proposed. As these issues have been adequately addressed, I'm quite happy. The formalities will catch up in due course. That is, I really don't see a problem here. Kurt At 05:00 PM 2/9/2006, Sam Hartman wrote: >Hi. I'd like to remind everyone of BCP 61. It says roughly that >protocols we approve need a mandatory to implement security mechanism. >We here in the security area think that's a great idea. O, by the >way, we're here to help you. > >As part of our plan for world domination^h^h^hhelping you, we've >created a number of security solutions including things like SASL, >TLS, IPsec, Kerberos, GSS-API, and CMS. We really like it when you >use these security services instead of inventing your own. First, it >makes it hugely easier for us to review your documents. Second, it >makes it easier when we need to do algorithm upgrades to things like >hash functions or replace DES with AES. Finally it probably makes >your security easier to deploy. > > >There's this littple problem though. All of the above are at proposed >standard. > >For a number of reasons they are not moving to draft as soon as anyone >would like. > > >So, I see two options that I don't like. First, we can avoid security >in anything going to draft. Draft becomes a dumping ground for all >the older protocols (plus a few things like SNMP that invent their own >security) without updates that add security. Secondly, we can block >everything from going to draft. > >Does anyone want to work on a better answer to this? > >--Sam > > >_______________________________________________ >saag mailing list >saag@mit.edu >http://jis.mit.edu/mailman/listinfo/saag From mcr at sandelman.ottawa.on.ca Fri Feb 10 08:55:36 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Fri Feb 10 14:32:05 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: Message from Harald Tveit Alvestrand <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Message-ID: <17947.1139579736@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Harald" == Harald Tveit Alvestrand writes: >> For a number of reasons they are not moving to draft as soon as >> anyone would like. Harald> Care to elaborate? I think, because there simply isn't the patience left to do things. Harald> I consider the third option - having Draft with Harald> downreference to Proposed - to be a Bad Idea. If we have to Harald> do that, I'd rather abandon Draft. That's quite an indictment of our current three step system. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ+ybUYCLcPvd0N1lAQLbOAf9F1QBUK75+tlBGmzJarbzi1t3LyuUaDaS lnQ8OdqSBHJT03tMlepvlKLU/q1Hk5fAhTDWAvCYoZB3kBgYa0/bdNJEfPq8EhmO ywCsHFzbAdu+R5VhjSzyXVVDxuh1+84tXeRph2zVT4tT9W31iyUHxVtJSlXOdwur LH7ZbhLHLIehKM8CgMyNtvaryOR4QKXORLjs2lppruRUnP+tKNLZkupLqsyJv900 T5zpOk+xaN27XmZHwhErSq0NwXJ6U108QDo7AZiZ49ppgIVQEvdcH7eyv5SRp1iH ctisAOGBwEaRYqF+kr4RGAbTl++MsjXT6nsRhg/C2V2bPy0nQ80yBA== =qcXa -----END PGP SIGNATURE----- From hartmans-ietf at MIT.EDU Fri Feb 10 16:57:43 2006 From: hartmans-ietf at MIT.EDU (Sam Hartman) Date: Fri Feb 10 16:57:55 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> (RJ Atkinson's message of "Fri, 10 Feb 2006 09:08:26 -0500") References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> Message-ID: >>>>> "RJ" == RJ Atkinson writes: RJ> ESP/AH do not depend on PKIX, and they ought not normatively RJ> depend on IKE (or any other automatic key management method), RJ> so ESP/AH should be able to move forward without PKIX. RJ> Similarly, applications that use ESP/AH, should be able to RJ> move forward when ESP/AH move forward, regardless of IKE (or RJ> PKIX). However BCP 107 argues that there should be few applications for which ESP/AH is appropriate without automated key management. I also suspect that ESP/AH depend on the architecture document. From hartmans-ietf at MIT.EDU Fri Feb 10 17:03:16 2006 From: hartmans-ietf at MIT.EDU (Sam Hartman) Date: Fri Feb 10 17:03:33 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> (RJ Atkinson's message of "Fri, 10 Feb 2006 08:21:16 -0500") References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> Message-ID: >>>>> "RJ" == RJ Atkinson writes: >> Kerberos: Doable, but we're all fairly busy working on meeting >> new customer needs. We did recently hold a meeting and develop >> feature matrix and roughly what we'd need to remove from the >> spec. We were really hoping that RFC 4120 would not need >> things removed; I think a lot of us lost interest in moving >> Kerberos to draft any time soon when we found out that was not >> the case. RJ> If the issue is that not all features of 4120 are in at least RJ> 2 implementations, there are a couple of approaches. One is RJ> to go find a sponsor to fund someone to add the missing RJ> feature(s) to either MIT Kerberos or Heimdal. The other is to RJ> do what OSPF did with M-OSPF, move the not yet widely RJ> implemented (but perceived useful) items into a separate RJ> document so the main spec can advance more quickly. I think there are one or two things we found that we need a second implementation for. That is relatively easy. We found several items that we'd left in from 1510 because they were harmless. However they are things like X.500 realm names that no one plans to implement and that we don't have interop tests for. They're not actually useful to anyone so removing them is far better than implementing. The challenge is to produce a spec revision that is sufficiently focused. I have lowe confidence that would happen. Remember we're talking about the same people (and I'm as guilty as anyone else in the Kerberos group) who took 11 years to bring pk-init to the IESG. --Sam From housley at vigilsec.com Fri Feb 10 17:28:12 2006 From: housley at vigilsec.com (Russ Housley) Date: Fri Feb 10 17:28:23 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Message-ID: <7.0.0.16.2.20060210172750.04913de0@vigilsec.com> CMS depends on PKIX, so it cannot advance until PKIX does. Russ At 07:34 AM 2/10/2006, Sam Hartman wrote: >CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this >was in the best shape. From rja at extremenetworks.com Fri Feb 10 18:37:18 2006 From: rja at extremenetworks.com (RJ Atkinson) Date: Fri Feb 10 18:37:26 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> Message-ID: On 10 Feb 2006, at 16:57, Sam Hartman wrote: >>>>>> "RJ" == RJ Atkinson writes: > > RJ> ESP/AH do not depend on PKIX, and they ought not normatively > RJ> depend on IKE (or any other automatic key management method), > RJ> so ESP/AH should be able to move forward without PKIX. > RJ> Similarly, applications that use ESP/AH, should be able to > RJ> move forward when ESP/AH move forward, regardless of IKE (or > RJ> PKIX). > > However BCP 107 argues that there should be few applications for which > ESP/AH is appropriate without automated key management. > > I also suspect that ESP/AH depend on the architecture document. I am sympathetic to the notion that no cryptographic system is easy to use without automatic key management. That said, insisting that a mechanism can only progress jointly with its (deliberately architecturally decoupled) key management method mostly seems to increase our process gridlock in a way that seems needless. Given the note at the start of today which started this thread, it seems wisest to keep ESP/AH (and the applications that depend on them -- and probably the IPsec Arch document) de-coupled from ISAKMP/IKE for advancement purposes. There is a clear trade-off between being practical about solving current issues versus being dogmatic about the ideal policy one might prefer in an ideal world. That trade-off is something that the powers that be need to sort out among themselves. I think the tools are already in place so that ESP/AH, IPsec Arch, and their dependent apps could all move rapidly to Draft Standard, without waiting for IKEv2 to get sorted out -- if the powers that be wanted to make that choice. For openers, people continue to use IKEv1 even as IKEv2 is being sorted out. IKEv1 is very widely deployed and used these days. ESP/AH can work with IKEv1 to have automatic key management -- until IKEv2 gets sorted out or KINK gets sorted out or some other better solution appears on the scene. Cheers, Ran From mcr at sandelman.ottawa.on.ca Fri Feb 10 20:18:04 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Fri Feb 10 20:19:10 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: Message from Paul Hoffman of "Fri, 10 Feb 2006 06:52:33 PST." References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Message-ID: <3028.1139620684@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Speaking from an IPsec point of view: - the majority of IPsec vendors are selling VPN. - few of us even have host implementations on which another protocol could really use our security service. (This in itself is very sad) - so, there is almost no market push for IPsec vendors to take a further interest in the process. None of *our* customers would care. Now, the vendors who do have host integrated implementations: KAME/BSD, Solaris, Linux and Microsoft, might be persuaded to care, but in most cases the upper layer protocols that want IPsec are still not part of our portfolio. Which documents are waiting on IPsec to go to PS? For which vendors is this a *market* problem for them? - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ+07S4CLcPvd0N1lAQKGbAf/aY4X0TrYLgkM7qB5Bwe86JOvXAAVMCOb mqCNpVSPALHjF5vESshrFyad++CYraEe998ya5SwmRq0n2RDzOFb3pC+Vkj03tF2 UibgsZxGR7dmL8jw1eGMJKmIURdEUOhSoMvuegjm4xdLTRgRaJOguOUvFURNejkj 1q3ajzJFpfuFZpfR4bvubHyFOyYJ3ASfmQIstiIdOGbpzb+3VhZXLKAL+XbShptC Zs4dg3ydMHop8gLykJ0+RkWVxUaHrvYhs4mp/wtqGBdGe0CmXr6aaR2ifLHO34oM JIrbemREYbBU0JPgkY+iDWtZh5fNmePp6OieSLEr6OgKtoqvN5S0HA== =9kAw -----END PGP SIGNATURE----- From hartmans-ietf at MIT.EDU Fri Feb 10 21:47:24 2006 From: hartmans-ietf at MIT.EDU (Sam Hartman) Date: Fri Feb 10 21:47:40 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: (RJ Atkinson's message of "Fri, 10 Feb 2006 18:37:18 -0500") References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> Message-ID: >>>>> "RJ" == RJ Atkinson writes: RJ> Given the note at the start of today which started this RJ> thread, it seems wisest to keep ESP/AH (and the applications RJ> that depend on them -- and probably the IPsec Arch document) RJ> de-coupled from ISAKMP/IKE for advancement purposes. RJ> There is a clear trade-off between being practical about RJ> solving current issues versus being dogmatic about the ideal RJ> policy one might prefer in an ideal world. That trade-off is RJ> something that the powers that be need to sort out among RJ> themselves. I think the community (and the leadership) have spoken on this issue. I think we said that we all believe that automated key management is really important from a technical standpoint. I'd much rather have proposed standards that have automated key management than draft standards that assume people will use manual keying. --Sam From rja at extremenetworks.com Sat Feb 11 09:03:49 2006 From: rja at extremenetworks.com (RJ Atkinson) Date: Sat Feb 11 09:04:09 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> Message-ID: <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> On 10 Feb 2006, at 21:47, Sam Hartman wrote: > I think the community (and the leadership) have spoken on this issue. > I think we said that we all believe that automated key management is > really important from a technical standpoint. > > I'd much rather have proposed standards that have automated key > management than draft standards that assume people will use manual > keying. You can have draft standards with automated key management. It only requires advancing IKEv1 separately from (in parallel with) IKEv2. If you'd like to do that but think the current rules don't allow, then lets have a discussion about fixing the rules. IKEv1 isn't going away anytime soon from the deployed world, simply because it will take a while (probably years, if history holds true) before there are multiple IKEv2 implementations that can talk with each other, regardless of what the IETF does. It took IKEv1 some number of years to reach that state, despite active interoperability testing throughout that period. So such a modest step as advancing the 2 versions of IKE in parallel is not harming deployed security at all. It is a choice that the IESG gets to make. The bottom line is in your last paragraph, which basically says that you are comfortable having a lot of application protocols stuck at PS for a while, possibly years. If that is true, why should ordinary IETF participants feel much incentive to progress anything beyond PS ? I'm not upset with anyone or any group, but I am greatly confused by the thread of the past day or so. Cheers, Ran PS: Not speaking for my employer, but one of the observations from when I've occasionally been an end-user (ISP or other end user) is that the market need is for a stable openly published specification and for interoperability. The market does not care a great deal whether something is PS, DS, FS, or Informational. PPS: What Michael Richardson says, echos my PS just above, and sadly enough, has been true of the IPsec WG for almost 10 years now. From paul.hoffman at vpnc.org Sat Feb 11 07:15:21 2006 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Sat Feb 11 10:16:00 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> Message-ID: At 9:03 AM -0500 2/11/06, RJ Atkinson wrote: >You can have draft standards with automated key management. >It only requires advancing IKEv1 separately from (in parallel with) >IKEv2. That "only" assumes that there is interest in doing the work of testing every SHOULD and MUST; so far, there has not been. The "only" also assumes that there are multiple interoperable implementations of every SHOULD and MUST, which there is not. >It is a choice that the IESG gets to make. No, it is a choice that the IPsec community gets to make. In the over seven years since IKEv1 has been around, there has not been interest in testing for the purpose of advancing the category of the protocol. >The bottom line is in your last paragraph, which basically says >that you are comfortable having a lot of application protocols >stuck at PS for a while, possibly years. I read it differently: the IETF is willing to accept that some protocols will never advance in status because they rely on other protocols which will never advance in status. I don't see a lot of "comfort" there. --Paul Hoffman, Director --VPN Consortium From hartmans-ietf at MIT.EDU Sat Feb 11 13:34:21 2006 From: hartmans-ietf at MIT.EDU (Sam Hartman) Date: Sat Feb 11 13:34:32 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: (Paul Hoffman's message of "Sat, 11 Feb 2006 07:15:21 -0800") References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> Message-ID: >>>>> "Paul" == Paul Hoffman writes: Paul> That "only" assumes that there is interest in doing the work Paul> of testing every SHOULD and MUST; so far, there has not Paul> been. The "only" also assumes that there are multiple Paul> interoperable implementations of every SHOULD and MUST, Paul> which there is not. Testing every should and must is not required. You need to test every protocol feature. That is a simpler task. However I suspect there still is not interest in doing that. --Sam From pekkas at netcore.fi Sun Feb 12 17:45:54 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Sun Feb 12 10:46:32 2006 Subject: [saag] definition of 'feature'; reasons to advance In-Reply-To: References: <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> Message-ID: On Sat, 11 Feb 2006, Sam Hartman wrote: >>>>>> "Paul" == Paul Hoffman writes: > > Paul> That "only" assumes that there is interest in doing the work > Paul> of testing every SHOULD and MUST; so far, there has not > Paul> been. The "only" also assumes that there are multiple > Paul> interoperable implementations of every SHOULD and MUST, > Paul> which there is not. > > Testing every should and must is not required. You need to test every > protocol feature. Depends on what you call a 'feature'. For example, a protocol might have a MUST discard clause for certain malformed, insecure or spoofed packets. If an implementation under testing does not implement that MUST, the outcome of the testing might be unspecified and we don't really know how compliant implementations would perform. Testing SHOULDs have similar, but slightly different implications: two compliant implementations might (but where at least one doesn't implement a SHOULD) not be enough to know if all the acceptable combinations would work. I think the main issue here the motivation for pushing specs along on the standards track. If we do it to demonstrate that the spec is known to interoperate under rigorous testing and be relevant to be implemented in its entirety, detailed reports could be very useful. If the motivation is to just obtain a status level and/or allow normative referencing by other specs, it is not so useful. With the current 3-level standards track and downref rules, I'd propose that Draft Standards should not require very detailed implementation reports, but that getting to Full Standard should. If we eliminate one step and/or remove downref rules, I'd vote for requiring sufficiently detailed interoperability and implementation reports. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jas at extundo.com Fri Feb 10 15:56:01 2006 From: jas at extundo.com (Simon Josefsson) Date: Sun Feb 12 14:54:28 2006 Subject: [saag] Re: BCP 61, advancing to draft In-Reply-To: (Peter Gutmann's message of "Sat, 11 Feb 2006 02:33:24 +1300") References: <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> Message-ID: pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > RJ Atkinson writes: >>> PKIX: I think has some internationalization issues; possibly some hash >>> fun. Not really sure. >>> >>> CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this >>> was in the best shape. >> >>These also don't look like low-hanging fruit. >> >>I think TLS is probably the lowest hanging fruit here. IPsec, Kerberos, and >>SASL come next in a clump. GSS-API, PKIX, and CMS seem pretty high up the >>tree just now. > > And that's the problem - CMS and TLS are both blocked waiting on PKIX (this is > what held up TLS at the RFC 2246 stage for what, three years?). Presumably > IPsec will also block on PKIX. This is why I proposed the relative- rather > than absolute-value reference approach in my previous message. Without this, > you get the priority-inversion situation of the lowest-hanging fruit stalled > behind the highest-hanging fruit (not to mention appallingly mangled > metaphors). I don't think PKIX should be critical for TLS. Look at TLS-PSK, TLS-SRP and TLS-OpenPGP. Decoupling TLS from PKIX fully would be a good idea. It would also help non-PKIX TLS mechanisms, which is also good. OTOH, to abolish draft seem like a better approach to me. The market doesn't seem to care if a document is at proposed or draft. The technical quality isn't better at higher standards level either. Just look at DNS. The only people who seem to care about this separation is long time IETF attendees, but they seem to have few instruments available to apply pressure on others to write standards. To make somebody write a standard, there should be some incentive or at least some good reason for doing the work. It is not a compelling reason to ask "Well, don't you want this document as Draft?". I'm not sure I see any real reason for spending the time on moving, say, IPSEC from proposed to draft. For most organizations, it seems the time is better spent on improving implementations (which will result in improvements to the standard too, eventually). Thanks, Simon From tony at att.com Sat Feb 11 01:14:31 2006 From: tony at att.com (Tony Hansen) Date: Sun Feb 12 14:54:30 2006 Subject: [newtrk] Re: [saag] BCP 61, advancing to draft In-Reply-To: References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Message-ID: <43ED80C7.9010608@att.com> Is it time to move beyond volunteers? Perhaps we need to ask some organization (ISOC? IGB? ????) if they would be willing to support an effort to do the interop testing? Tony Hansen tony@att.com Paul Hoffman wrote: > One big issue we have with security protocols moving to draft is that > there is very little volunteer interest in testing SHOULD/MUST > interop beyond the basics (if even that). Our protocols have a lot of > SHOULDs that have nothing to do with interop and are very difficult > to test. But, even without those, the security area has been much > less active at voluntary interop testing than other areas, which > makes "going to Draft" not appealing. We are generally happy to cycle > at Proposed. Sam's message points out a significant ramification of > that attitude, although I don't have a proposed solution to the > problem. From touch at ISI.EDU Sat Feb 11 14:01:37 2006 From: touch at ISI.EDU (Joe Touch) Date: Sun Feb 12 14:54:33 2006 Subject: [newtrk] Re: [saag] BCP 61, advancing to draft In-Reply-To: References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> Message-ID: <43EE5EC1.9080007@isi.edu> Sam Hartman wrote: >>>>>> "Paul" == Paul Hoffman writes: > > Paul> That "only" assumes that there is interest in doing the work > Paul> of testing every SHOULD and MUST; so far, there has not > Paul> been. The "only" also assumes that there are multiple > Paul> interoperable implementations of every SHOULD and MUST, > Paul> which there is not. > > Testing every should and must is not required. That seems odd; what is sufficient protocol testing if not to validate the MUST and MUST NOTs? Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://jis.mit.edu/pipermail/saag/attachments/20060211/18c959e8/signature.bin From LMM at acm.org Sun Feb 12 17:57:23 2006 From: LMM at acm.org (Larry Masinter) Date: Sun Feb 12 21:20:14 2006 Subject: [saag] RE: [newtrk] definition of 'feature'; reasons to advance In-Reply-To: Message-ID: <000d01c63040$d54ef6c0$29f1070a@corp.adobe.com> > > Testing every should and must is not required. You need to test every > > protocol feature. > > Depends on what you call a 'feature'. For example, a protocol might > have a MUST discard clause for certain malformed, insecure or spoofed > packets. If an implementation under testing does not implement that > MUST, the outcome of the testing might be unspecified and we don't > really know how compliant implementations would perform. Testing > SHOULDs have similar, but slightly different implications: two > compliant implementations might (but where at least one doesn't > implement a SHOULD) not be enough to know if all the acceptable > combinations would work. http://www.ietf.org/internet-drafts/draft-ietf-newtrk-interop-reports-00.txt proposes creating a separate Protocol Feature Set which identifies what constitutes the "features" for a protocol. It is consistent with one-step or two-step or three-step, and might even be a way of migrating gradually between those. Larry From pgut001 at cs.auckland.ac.nz Mon Feb 13 21:08:36 2006 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Mon Feb 13 03:08:48 2006 Subject: [saag] Re: BCP 61, advancing to draft In-Reply-To: Message-ID: Simon Josefsson writes: >I don't think PKIX should be critical for TLS. Look at TLS-PSK, TLS-SRP and >TLS-OpenPGP. All of those combined are buried in the noise floor compared to use of certificates with TLS: TLS-PSK: Really only accepted as something for low-powered devices (although I disagree with this use). TLS-SRP: Amost never used due to patent concerns. TLS-PGP: Never used (or at least there's probably some experimental implementation somewhere, but I'm not aware of it). >Decoupling TLS from PKIX fully would be a good idea. It would also help non- >PKIX TLS mechanisms, which is also good. I think it'd be a good idea too, but it'll never happen in practice. You'd have to convince several million web sites with several hundred million dollars tied up in infrastructure to change, which is never going to happen. Currently every one of them will still do SSLv3 at the drop of a handshake option, which wasn't even an RFC, let alone a standards-track one. Peter. From jas at extundo.com Mon Feb 13 10:19:41 2006 From: jas at extundo.com (Simon Josefsson) Date: Mon Feb 13 04:20:26 2006 Subject: [saag] Re: BCP 61, advancing to draft In-Reply-To: (Peter Gutmann's message of "Mon, 13 Feb 2006 21:08:36 +1300") References: Message-ID: pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: >>Decoupling TLS from PKIX fully would be a good idea. It would also help non- >>PKIX TLS mechanisms, which is also good. > > I think it'd be a good idea too, but it'll never happen in practice. You'd > have to convince several million web sites with several hundred million > dollars tied up in infrastructure to change, which is never going to happen. > Currently every one of them will still do SSLv3 at the drop of a handshake > option, which wasn't even an RFC, let alone a standards-track one. I don't see how that is related to having TLS depend normatively or informatively on PKIX. The TLS protocol can be decoupled from the certificate types used. I agree that it would be a lot of work to replace the PKIX language in the TLS spec with something more abstract, that would map to PKIX or other certificate structures, but it seems possible to me. However, the benefits (i.e., having TLS at Draft) of doing all that work (rewriting the TLS spec) seem small. It seems better to me to relax how documents at Draft can reference documents at Proposed, and even to abolish Draft. Thanks, Simon From pgut001 at cs.auckland.ac.nz Mon Feb 13 22:48:35 2006 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Mon Feb 13 04:48:41 2006 Subject: [saag] Re: BCP 61, advancing to draft In-Reply-To: Message-ID: Simon Josefsson writes: >pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: >>>Decoupling TLS from PKIX fully would be a good idea. It would also help non- >>>PKIX TLS mechanisms, which is also good. >> >> I think it'd be a good idea too, but it'll never happen in practice. You'd >> have to convince several million web sites with several hundred million >> dollars tied up in infrastructure to change, which is never going to happen. >> Currently every one of them will still do SSLv3 at the drop of a handshake >> option, which wasn't even an RFC, let alone a standards-track one. > >I don't see how that is related to having TLS depend normatively or >informatively on PKIX. The TLS protocol can be decoupled from the >certificate types used. How? TLS, at least as used with HTTP (which is probably about 99% of it use) is synonymous with X.509 PKI. By "decouple" do you mean replace the current explicit use of X.509 certs with generic language describing an abstract certificate type, and then assume that everyone knows that the abstract certificate type is actually meant to be X.509 even though it's not made explicit? (Incidentally, you run into additional problems with TLS extensions, which reference a pile of X.509 cert mechanisms). Peter. From jas at extundo.com Mon Feb 13 11:36:09 2006 From: jas at extundo.com (Simon Josefsson) Date: Mon Feb 13 05:36:54 2006 Subject: [saag] Re: BCP 61, advancing to draft In-Reply-To: (Peter Gutmann's message of "Mon, 13 Feb 2006 22:48:35 +1300") References: Message-ID: pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Simon Josefsson writes: >>pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: >>>>Decoupling TLS from PKIX fully would be a good idea. It would also help non- >>>>PKIX TLS mechanisms, which is also good. >>> >>> I think it'd be a good idea too, but it'll never happen in practice. You'd >>> have to convince several million web sites with several hundred million >>> dollars tied up in infrastructure to change, which is never going to happen. >>> Currently every one of them will still do SSLv3 at the drop of a handshake >>> option, which wasn't even an RFC, let alone a standards-track one. >> >>I don't see how that is related to having TLS depend normatively or >>informatively on PKIX. The TLS protocol can be decoupled from the >>certificate types used. > > How? TLS, at least as used with HTTP (which is probably about 99% of it use) > is synonymous with X.509 PKI. By "decouple" do you mean replace the current > explicit use of X.509 certs with generic language describing an abstract > certificate type, and then assume that everyone knows that the abstract > certificate type is actually meant to be X.509 even though it's not made > explicit? Yes, something like that. You could provide a "PKIX-profile for TLS" that would describe how to translate the TLS generic language into PKIX matters. TLS would then be able to be at Draft level, and the PKIX-to-TLS document staying at Proposed until PKIX moves to Draft. Implementations would not be affected, and TLS could move to Draft. > (Incidentally, you run into additional problems with TLS extensions, which > reference a pile of X.509 cert mechanisms). TLS extensions could stay at Proposed, or use a similar profile-based mechanism. Again, I'd much rather abolish Draft than to follow my approach. My approach is a lot of work, that may hide complicated problems in bureaucratic sounding text. I'd much rather design documents based around technical problems rather than around process issues within the IETF. Thanks, Simon From jari.arkko at piuha.net Mon Feb 13 13:52:11 2006 From: jari.arkko at piuha.net (Jari Arkko) Date: Mon Feb 13 06:52:04 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> Message-ID: <43F072EB.60200@piuha.net> Sam Hartman wrote: >However BCP 107 argues that there should be few applications for which >ESP/AH is appropriate without automated key management. > > Yes. But that need not stop us from advancing ESP/AH/Arch. We get those to Draft, we are half way done. Yes, we'd still have a problem with a spec at Draft employing them since it would also need to reference the key management protocol, but the key to progress is to take the first step... >I'd much rather have proposed standards that have automated key >management than draft standards that assume people will use manual >keying. > > Sure. But just advancing some of our specs to Draft does not mean that we give up on requiring the use of others. --Jari From jari.arkko at piuha.net Mon Feb 13 14:32:42 2006 From: jari.arkko at piuha.net (Jari Arkko) Date: Mon Feb 13 07:32:31 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> Message-ID: <43F07C6A.5010807@piuha.net> Thank you Sam for raising this issue. I think it is an important issue, and its not merely a process nuisance*. The main question to me is "Why aren't we updating our specs frequently enough?" Its not only about the status designation in the RFCs, it also about real-world things such as fixing bugs, adding clarifications, removing bloat^H^H^H^H^H features that no one turned out to implement, updating mandatory algorithm lists to whatever is appropriate at the time, and looking after the true interoperability of our specifications. And I do think we need to improve. Before jumping to a particular solution maybe its useful to think a little bit about the root causes that have led to the situation. I'm thinking mostly from the SEC perspective, other areas may be different. o References to common components and formats. These need to progress first before the referring spec can progress. I don't think there is a lot we can or should do about this, other than remembering to progress that referred component. Having components is good. Sometimes you can use general language to avoid a reference problem. o Desire to address a number of issues in one go. For instance, produce a "bis" revision along with adding features 1, 2, and 3. I would suggest a stepwise approach would be better. Take small steps, but take them often. As an example, a bad algorithm could be replaced by a timely published "bis" version, if we didn't need to incorporate everyone's all possible changes and new features at the same time. (And by the time you are done with the all the changes there will be new issues to address.) o Lack of editor and other participant resources for the work. I suspect timely completion of spec revisions has an impact on the availability of people to do the work. For instance, if you make a small update this will likely complete faster, giving you more willing editor candidates. And you can hire junior editors because the scope of the changes is not that big. o Lack of interoperability testing of all features. If this situation persists, I don't think its just a question about interop events or even funding. Its a more fundamental issue about specs matching the needs of the world. Personally, I like small base specs accompanied with a number of optional extensions. They are a bit harder to read, but the tradeoff wrt publication speed is well worth it. Then some specific thoughts about what we can do now. I wonder if we could attempt to progress AH/ESP/Arch to Draft. The main problem appears to be the architecture RFC which has a long list of normative references. I'm not sure though that all those references really need to be normative, e.g., both IKEv1 and IKEv2. I would also suggest pursuing the IKEv2 clarifications (is the result a "bis"?) work as soon as possible, and not adding new features during that process. For TLS... I don't know. Maybe the general language helps avoid the PKIX reference. --Jari *) There is a process question as well, namely the fate of the three-step process. Personally, I think two steps would be better, but for the most part, it doesn't matter because we already have the ability to either use or ignore the steps beyond Proposed. From hartmans-ietf at MIT.EDU Sun Feb 12 15:20:08 2006 From: hartmans-ietf at MIT.EDU (Sam Hartman) Date: Mon Feb 13 10:46:34 2006 Subject: [saag] Re: definition of 'feature'; reasons to advance In-Reply-To: (Pekka Savola's message of "Sun, 12 Feb 2006 17:45:54 +0200 (EET)") References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> Message-ID: Remember the goal of the implementation report is to test the specification and make sure it is clear enough to create two interoperable implementations. We are not doing conformance testing; we are not doing interoperability testing of the implementations. We're simply trying to determine if the spec is good enough that you can create interoperable implementations from it. At least when I've asked other IESG members about this it explicitly means that you don't check error paths involving data that a conforming implementation cannot generate. Conformance testing is very useful and the kind of testing we've done can be a useful in developing conformance tests. But please let's not make the job harder than it has to be. From hartmans-ietf at MIT.EDU Sun Feb 12 21:42:49 2006 From: hartmans-ietf at MIT.EDU (Sam Hartman) Date: Mon Feb 13 10:46:39 2006 Subject: [saag] Re: [newtrk] definition of 'feature'; reasons to advance In-Reply-To: <000d01c63040$d54ef6c0$29f1070a@corp.adobe.com> (Larry Masinter's message of "Sun, 12 Feb 2006 17:57:23 -0800") References: <000d01c63040$d54ef6c0$29f1070a@corp.adobe.com> Message-ID: >>>>> "Larry" == Larry Masinter writes: Larry> http://www.ietf.org/internet-drafts/draft-ietf-newtrk-interop-reports-00.txt Larry> proposes creating a separate Protocol Feature Set which Larry> identifies what constitutes the "features" for a protocol. Larry> It is consistent with one-step or two-step or three-step, Larry> and might even be a way of migrating gradually between Larry> those. As a side note, we found this analysis (based on an early draft of your work) very useful in creating a feature matrix for Kerberos. From mcr at sandelman.ottawa.on.ca Thu Feb 16 10:20:09 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Thu Feb 16 10:20:44 2006 Subject: [saag] BCP 61, advancing to draft In-Reply-To: Message from Jari Arkko of "Mon, 13 Feb 2006 14:32:42 +0200." <43F07C6A.5010807@piuha.net> References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <43F07C6A.5010807@piuha.net> Message-ID: <19879.1140103209@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Jari" == Jari Arkko writes: Jari> o Desire to address a number of issues in one go. For Jari> instance, produce a "bis" revision along with adding features Jari> 1, 2, and 3. I would suggest a stepwise approach would be Jari> better. Take small steps, but take them often. As an example, As I've said before --- we made this mistake with IKEv1->IKEv2. Jari> o Lack of editor and other participant resources for the Jari> work. I suspect timely completion of spec revisions has an Jari> impact on the availability of people to do the work. For There is another factor here -- it's hard to make a small change to an existing document because the .xml file isn't available. (Or may never have existed). And the nroff source that the rfc-editor used, won't match. Jari> o Lack of interoperability testing of all features. If this Jari> situation persists, I don't think its just a question about Jari> interop events or even funding. Its a more fundamental issue Jari> about specs matching the needs of the world. Personally, I Interop events and funding *ARE* important issues. Lots of people want open source reference implementations --- it's hard to fund this. Even if you assume the people are free (they aren't), you can't afford to attend meetings, interop events. etc. without funding. Jari> like small base specs accompanied with a number of optional Jari> extensions. They are a bit harder to read, but the tradeoff Jari> wrt publication speed is well worth it. I agree strongly. Make people plan for new features being added, rather than adding them. Mostly, we do a good job here, but not always. Jari> I would also suggest pursuing the IKEv2 clarifications (is the Jari> result a "bis"?) work as soon as possible, and not adding new Jari> features during that process. I agree. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ/SYHICLcPvd0N1lAQLPnQf/cm803pjwp8Amgo/ofy87a0jFuHHIjX2t GuiHE0E1UKFQ029C8J92GzxfYAfXdCDxS7UhuM/xnpF81+ohfXurFwq5ttjsY9Du 7Hj9Mmh60DoaPwcxZpegllm4O6RtU9s7wj2UqE2Kv49FfDkwyNkhWGwtwYoZyEIx HKv1XAuhVt+xHUi1mkZUQ08/g+lQ2a2vvIHn6J6CnyuMNc+8RNbQjbaHavH0Qs/p sB162ewqeVlzcjZpLC62K9O6ODMlifgixVamumFH5qAJLAQfQ1UTH/USNnNInSNQ f0PEtBOmZWLqGv7EK95gr/BUlC69S7XoBoRVeKgz9Det69WjnxYcTA== =9gkP -----END PGP SIGNATURE----- From housley at vigilsec.com Wed Mar 1 07:58:00 2006 From: housley at vigilsec.com (Russ Housley) Date: Wed Mar 1 09:23:12 2006 Subject: [saag] Cryptographic Token Key Initialization Protocol Version 1.0 Message-ID: <7.0.0.16.2.20060227104601.04c216d0@vigilsec.com> Please take a look at draft-nystrom-ct-kip-00.txt. It specifies Cryptographic Token Key Initialization Protocol Version 1.0, which is part of the OTPS series of documents being coordinated by RSA Laboratories. My opinion is that this is appropriate for publication as an RFC. My current plan is to sponsor this document as an Informational RFC. Please let me know if this causes concern. Russ