From tls-bounces@ietf.org Mon Feb 2 11:07:30 2009 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ACE128C233; Mon, 2 Feb 2009 11:07:30 -0800 (PST) X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9D5443A6886; Mon, 2 Feb 2009 11:07:27 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090202190727.9D5443A6886@core3.amsl.com> Date: Mon, 2 Feb 2009 11:07:27 -0800 (PST) Cc: Internet Architecture Board , tls mailing list , tls chair , RFC Editor Subject: [TLS] Protocol Action: 'Pre-Shared Key Cipher Suites for Transport Layer Security (TLS) with SHA-256/384 and AES Galois Counter Mode' to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org The IESG has approved the following document: - 'Pre-Shared Key Cipher Suites for Transport Layer Security (TLS) with SHA-256/384 and AES Galois Counter Mode ' as a Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-new-mac-aes-gcm-05.txt Technical Summary RFC 4279 and RFC 4785 describe pre-shared key cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 as their MAC algorithm. This document describes a set of pre-shared key cipher suites for TLS which uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another set which uses the Advanced Encryption Standard (AES) in Galois Counter Mode (GCM). Working Group Summary This document is a product of the Transport Layer Security (TLS) Working Group. The document represents the consensus of the TLS working group. Document Quality There are no existing implementations, but working group members have shown interest in the document. Personnel The document shepherd is Joe Salowey. The responsible area director is Pasi Eronen. RFC Editor Note Please add the following sentence to the end of Section 1.1: "The applicability statement in [RFC4279] applies to this document as well." Please remove the following paragraph from Section 4: "As described in [RFC5288], the cipher suites defined in the Section 2 of this document may only be used with TLS 1.2 or greater. The cipher suites defined in the Section 3 may be used, whatever the negotiated TLS version is. " _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From Michael.Tuexen@lurchi.franken.de Thu Feb 5 03:40:54 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56F128C20E for ; Thu, 5 Feb 2009 03:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[AWL=-2.169, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhVx9KxLp7uU for ; Thu, 5 Feb 2009 03:40:44 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id EE8CA28C1BF for ; Thu, 5 Feb 2009 03:40:43 -0800 (PST) Received: from [192.168.1.4] (p5481F450.dip.t-dialin.net [84.129.244.80]) by mail-n.franken.de (Postfix) with ESMTP id 98B8E1C0E9356; Thu, 5 Feb 2009 12:40:20 +0100 (CET) Message-Id: <733D0D28-D8ED-4EF7-8B88-CD380B770F57@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: TLS Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Feb 2009 12:40:20 +0100 X-Mailer: Apple Mail (2.930.3) Subject: [TLS] DTLS interop server available on interop.fh-muenster.de X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 11:40:54 -0000 Dear all, Robin and myself have setup an DTLS interop server at interop.fh-muenster.de (195.37.125.98). It runs an echo and discard server for DTLS/UDP and DTLS/SCTP. The DTLS implementation use is the one from OpenSSL with Robins bug fixes available at http://sctp.fh-muenster.de If you have comments, questions, found bugs or anything else related to the above interop testing, please send an e-mail to seggelmann@fh-muenster.de or tuexen@fh-muenster.de. Best regards Michael From wwwrun@core3.amsl.com Fri Feb 6 06:43:25 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 516543A6BC5; Fri, 6 Feb 2009 06:43:25 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090206144325.516543A6BC5@core3.amsl.com> Date: Fri, 6 Feb 2009 06:43:25 -0800 (PST) Cc: Internet Architecture Board , tls mailing list , tls chair , RFC Editor Subject: [TLS] Document Action: 'ECDHE_PSK Ciphersuites for Transport Layer Security (TLS)' to Informational RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 14:43:25 -0000 The IESG has approved the following document: - 'ECDHE_PSK Ciphersuites for Transport Layer Security (TLS) ' as an Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecdhe-psk-05.txt Technical Summary This document extends RFC 4279, RFC 4492 and RFC 4785, and specifies a set of cipher suites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange (ECDH). These cipher suites provide Perfect Forward Secrecy (PFS). Working Group Summary This document is a product of the Transport Layer Security (TLS) Working Group. The document represents the consensus of the TLS working group. Document Quality There are no existing implementations, but working group members have shown interest in the document. Personnel The document shepherd is Joe Salowey. The responsible area director is Pasi Eronen. RFC Editor Note Please add the following sentence to the end of Section 1.1: "The applicability statement in [RFC4279] applies to this document as well." Section 5, 2nd paragraph: OLD: Given the current state of published to date crypto attacks, HMAC-SHA1 apparently is not (yet) so bad that we need to risk breaking interoperability with previous versions of TLS. However, implementers and administrators should monitor the general statements on recommended cryptographic algorithms published from time to time by various forums including the IETF, as a base for the portfolio they support and the policies for strength of function acceptable for the cipher suites they set. NEW: Implementers and administrators should monitor the general statements on recommended cryptographic algorithms (e.g., SHA-1 hash function) published from time to time by various forums including the IETF, as a base for the portfolio they support and the policies for strength of function acceptable for the cipher suites they set. From rfc-editor@rfc-editor.org Tue Feb 10 18:25:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7FD83A6864; Tue, 10 Feb 2009 18:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.836 X-Spam-Level: X-Spam-Status: No, score=-16.836 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPrPLZls4wWP; Tue, 10 Feb 2009 18:25:15 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id AEF7A3A6D61; Tue, 10 Feb 2009 18:25:14 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id 8255421659D; Tue, 10 Feb 2009 18:25:18 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090211022518.8255421659D@bosco.isi.edu> Date: Tue, 10 Feb 2009 18:25:18 -0800 (PST) Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 5469 on DES and IDEA Cipher Suites for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 02:25:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5469 Title: DES and IDEA Cipher Suites for Transport Layer Security (TLS) Author: P. Eronen, Ed. Status: Informational Date: February 2009 Mailbox: pasi.eronen@nokia.com Pages: 4 Characters: 8558 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-des-idea-02.txt URL: http://www.rfc-editor.org/rfc/rfc5469.txt Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346) include cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms. DES (when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS version 1.2 (RFC 5246). This document specifies these cipher suites for completeness and discusses reasons why their use is no longer recommended. This memo provides information for the Internet community. This document is a product of the Transport Layer Security Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From dean@av8.com Wed Feb 11 13:20:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CBAC3A67F0; Wed, 11 Feb 2009 13:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsCcq9Sd7vcW; Wed, 11 Feb 2009 13:20:17 -0800 (PST) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id AFB113A68AF; Wed, 11 Feb 2009 13:20:15 -0800 (PST) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n1BLKGut008749 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 11 Feb 2009 16:20:16 -0500 Date: Wed, 11 Feb 2009 16:20:14 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Tim Polk In-Reply-To: <1A253EA8-BCF7-47D7-9A68-C9A7DE1423E8@nist.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tls@ietf.org, draft-housley-tls-authz-extns@tools.ietf.org, ietf-honest@lists.iadl.org, iesg@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 21:20:18 -0000 Please remember that if the TLS WG does take on this work, that RFC3979 requires that the group consider non-patented alternatives to the protocol. As President of the LPF, I will be following this very closely for IPR issues and reporting those to the LPF and FSF. And as programmer and developer, I will probably have some non-patented alternatives to present. --Dean On Wed, 11 Feb 2009, Tim Polk wrote: > Eric & Joe, > > In retrospect, I certainly should have consulted with the TLS WG before > initiating yet another Last Call. I failed to do so because the > controversy > had not centered on technical questions, but a great deal of time has > passed, and the mechanism is clearly relevant to the scope of your > working group. I appreciate the course correction, as I did not intend > to perform an end around. > > I will rectify the situation this week and request that the TLS WG > review > the document to gauge interest in this area. I would be delighted to > learn that the TLS WG is now interested in pursuing work in the > authorization space. I have always thought that would be the best > course of action. An important metric for working group interest > would be availability of an editor, since the lead editor for authz does > not have the necessary cycles available for active editorship. > > In this case, I would ask the WG chairs to support approval of > draft-housley-tls-authz as experimental, with a hold in the RFC queue > until the the WG document is ready for publication. When completed, > the WG document would include an appendix that moves > draft-housley-tls-authz to historic. In this way, draft-housley-tls- > authz > would not appear as an RFC until the standards track document is > also an RFC, and would always be designated historic. (This is > consistent with the recent handling of personal drafts in several other > working groups.) > > If the working group decides not to pursue this work, I will *not* > ask the > IESG to approve for standards track. After two years as AD, I have my > own reservations about advancing individual submissions as standards > track. (It has been problematic almost every time!) I am not ready > to set > a hard and fast rule, but opposition from the relevant wg chairs would > seem to be an important indicator. :) I will consider requesting > approval > as Experimental, *contingent on the consensus call* of course. > > I am unsure what course is best if the working group decides to pursue > authorization work but the authors decline to submit the document to the > working group a second time. Hopefully, that set of conditions will not > come to pass. > > Again, my apologies for the process failure (at least in spirit). > Thanks for > responding, and I look forward to hearing the results of the TLS WG > discussions. > > Thanks, > > Tim Polk > > On Feb 11, 2009, at 12:33 AM, Eric Rescorla wrote: > > > [Resent with proper addressing information] > > > > As chairs of the TLS Working Group, we request that the IESG not > > approve draft-ietf-tls-authz-07 as a Proposed Standard. This document > > was initially brought to the TLS WG, which passed on it due to lack of > > interest and it was subsequently advanced as an individual submission, > > but IESG approval was rescinded after the disclosure of IPR that > > affected the document. These events occurred in late 2006 and early > > 2007. In the nearly two years since the previous attempts at > > progressing the document, the authors have not coordinated with the > > TLS WG. The TLS WG was not consulted prior to the start of this new > > Last Call. > > > > Although we recognize that opinions vary about the wisdom of advancing > > documents as individual submissions, this does not seem like an edge > > case to us. First, there is a functioning, relevant, working group: > > TLS. While it is true that the WG did not object to advancement two > > years ago, that was with the impression that it would be > > uncontroversial, which clearly is not the situation. On the contrary, > > the IPR situation remains quite unclear and there are also technical > > issues with the document (see Eric Rescorla's separate review), as > > well as at least one part of the document which is obsoleted by RFC > > 5246. These factors provide substantial evidence that the document > > would benefit from the Working Group process. > > > > If the authors wish to advance the document on the standards track, > > the appropriate path is to submit it to the TLS WG as a work item. TLS > > WG has the appropriate participation and skills to evaluate the need > > for this work and the suitability of this document. If there is > > sufficient support for work in this area (including the usual RFC 3979 > > IPR Evaluation), then it can advance through the standards track via > > the WG process. If the authors don't wish to go through the WG > > process, we do not oppose advancement of this document as > > Experimental. However, we do not believe that advancing a two year old > > document which is clearly in scope of an active WG is an appropriate > > use of the individual submission process. Therefore we urge the IESG > > not to approve this document. > > > > Eric Rescorla > > Joe Salowey > > [TLS WG Chairs] > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From A.Hoenes@tr-sys.de Wed Feb 11 16:04:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9009D28C106; Wed, 11 Feb 2009 16:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.251 X-Spam-Level: * X-Spam-Status: No, score=1.251 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NKCa9QE0jw5; Wed, 11 Feb 2009 16:04:27 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 5AF0B3A69E0; Wed, 11 Feb 2009 16:04:26 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA112536953; Thu, 12 Feb 2009 01:02:33 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA11916; Thu, 12 Feb 2009 01:02:03 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200902120002.BAA11916@TR-Sys.de> To: dean@av8.com Date: Thu, 12 Feb 2009 01:02:03 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 00:04:28 -0000 At Wed, 11 Feb 2009 16:20:14 -0500 (EST), Dean Anderson wrote: > ... And as > programmer and developer, I will probably have some non-patented > alternatives to present. > > --Dean Dean, that's really laudable progress, leading back to technical discussion of possible alternative solutions. Please indeed prepare such I-D as soon as feasible. I heartly invite other interested parties as well to submit their proposals to the TLS WG, and I hereby explicitely would like to address those many folks that newly started being interested in IETF work in general and further development and application of TLS in particular. In order to make life easier for all participants, I suggest to start with streamlined draft names like draft--tlz-authz--00 . The WG should be able to perform an unprejudized discussion of alternative proposals before it comes to determine consensus whether there is enough interest and support to warrant adopting 'TLS Authorization' as a new work item, and if so, which draft(s) to base the WG project on. I personally promise to review sound draft proposals in time before such WG decision (perhaps not initial -00 versions, only enough elaborate refined versions). One immediate question to the group and the respective author: Draft-housley-tls-authz-extns only defines a framework, and according to the past exegesis of the imprecise IPR statements under discussion, only the application of that framework to specific use cases might be encumbered by these claims. However, the recent I-D, draft-keromytis-tls-authz-keynote-01, together with a supporting sibling document, draft-keromytis-keynote-x509-01 (both still rough and lacking important details), defines a concrete instantiation of that framework. In how far is that instantiation encumbered by these IPR claims? Is it burdened with other patent claims? Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From wang.hongyan4@zte.com.cn Wed Feb 11 20:36:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BED83A677E for ; Wed, 11 Feb 2009 20:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.386 X-Spam-Level: X-Spam-Status: No, score=-96.386 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_SPAM=3.798, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ab7YVhTKeJhj for ; Wed, 11 Feb 2009 20:36:32 -0800 (PST) Received: from mail.zte.com.cn (mail2.zte.com.cn [202.103.147.144]) by core3.amsl.com (Postfix) with ESMTP id 9E3C43A6778 for ; Wed, 11 Feb 2009 20:36:30 -0800 (PST) Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 97599.1626001193; Thu, 12 Feb 2009 12:53:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n1C4aJuK091992 for ; Thu, 12 Feb 2009 12:36:19 +0800 (CST) (envelope-from wang.hongyan4@zte.com.cn) To: tls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.0.2 August 07, 2008 Message-ID: From: wang.hongyan4@zte.com.cn Date: Thu, 12 Feb 2009 12:34:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-02-12 12:36:12, Serialize complete at 2009-02-12 12:36:12 Content-Type: multipart/alternative; boundary="=_alternative 001A26F64825755B_=" X-MAIL: mse1.zte.com.cn n1C4aJuK091992 Cc: wei.yinxing@zte.com.cn Subject: [TLS] could we add a record in hello request? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 04:36:33 -0000 This is a multipart message in MIME format. --=_alternative 001A26F64825755B_= Content-Type: text/plain; charset="US-ASCII" hi Given we have PSK between client and server. we would like to use PSK TLS to establish connection between client and server. if Server want to send hello request to client and then client can begin to handshake with sever by sending clientHello. here I have one question: if one bad guy forge the hello request and send to many clients, the clients will send client Hello to server, it will lead to the attack to server. so I think whether we can add record in hello request, this record acts as MAC which can be produced based on PSK. the record can protect the server against the attack. the client received the hello request and verify it according this record, if it's valid, then it will process it( send clientHello or ignore ). could you give me some suggestion on it? thanks Best Regards Terry(HongYan) Wang --------------------------------------------------- Address: System Architecture Department, Central Institute, ZTE Corporation Room 2A3, No. 68, Zijinghua Road, Yuhuatai District, Nanjing, China Zipcode: 210012 Office Telephone: Mobile Telephone: +86-15905178852 Fax: +86-25-52878008 MSN: why_hhu@live.cn -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 001A26F64825755B_= Content-Type: text/html; charset="US-ASCII"
hi

  Given we have PSK between client and server. we would like to use PSK TLS to establish connection between client and server.
 
  if Server want to send hello request to client and then client can begin to handshake with sever by sending clientHello.
 
  here I have one question:
 
  if one bad guy forge the hello request and send to many clients, the clients will send client Hello to server, it will lead to the attack to server.

  so I think whether we can add record in hello request, this record acts as MAC which can be produced based on PSK.
 
  the record can protect the server against the attack.

  the client received the hello request and verify it according this record, if it's valid, then it will process it( send clientHello or ignore ).

 
  could you give me some suggestion on it?

 
  thanks
 

  Best Regards

Terry(HongYan) Wang

---------------------------------------------------
Address: System Architecture Department, Central Institute, ZTE Corporation
Room 2A3, No. 68, Zijinghua Road, Yuhuatai District, Nanjing, China
Zipcode: 210012
Office Telephone:
Mobile Telephone: +86-15905178852
Fax: +86-25-52878008
MSN: why_hhu@live.cn
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 001A26F64825755B_=-- From angelos@cs.columbia.edu Thu Feb 12 01:21:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4FA53A6969; Thu, 12 Feb 2009 01:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91IL3L75K1+a; Thu, 12 Feb 2009 01:21:19 -0800 (PST) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 8409F3A6963; Thu, 12 Feb 2009 01:21:19 -0800 (PST) Received: from ADKs-Computer.home (ANice-754-1-6-100.w90-52.abo.wanadoo.fr [90.52.225.100]) (user=ak2052 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n1C9Krho019769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 12 Feb 2009 04:20:55 -0500 (EST) Message-Id: From: "Angelos D. Keromytis" To: =?ISO-8859-1?Q?Alfred_H=CEnes?= In-Reply-To: <200902120002.BAA11916@TR-Sys.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Feb 2009 04:20:53 -0500 References: <200902120002.BAA11916@TR-Sys.de> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 X-Mailman-Approved-At: Thu, 12 Feb 2009 11:13:33 -0800 Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 09:53:55 -0000 Alfred, neither of the cited KeyNote drafts (nor the KeyNote system itself) is =20= patent-encumbered. However, I admit to not (yet) having paid close =20 attention to the details of the IPR issues around tls-authz-extns =20 itself and their potential impact to tls-authz-keynote. I have started draft-keromytis-keynote-x509-01 through the RFC-=20 fication process (currently discussing with a reviewer), since it does =20= not depend on authz (or any other pending work in any WG). I have been =20= waiting for tls-authz-extns to go through the process before I start =20 with draft-keromytis-tls-authz-keynote-01. I invite every interested =20 party to send me comments. You may find it useful to first read RFCs =20 2704 (at least the first few sections) and 2792. Best, -Angelos On Feb 11, 2009, at 7:02 PM, Alfred H=CEnes wrote: > At Wed, 11 Feb 2009 16:20:14 -0500 (EST), Dean Anderson wrote: > >> ... And as >> programmer and developer, I will probably have some non-patented >> alternatives to present. >> >> --Dean > > Dean, > that's really laudable progress, leading back to technical discussion > of possible alternative solutions. > Please indeed prepare such I-D as soon as feasible. > > > I heartly invite other interested parties as well to submit their > proposals to the TLS WG, and I hereby explicitely would like to > address those many folks that newly started being interested in > IETF work in general and further development and application of > TLS in particular. > > In order to make life easier for all participants, > I suggest to start with streamlined draft names like > draft--tlz-authz--00 . > > The WG should be able to perform an unprejudized discussion > of alternative proposals before it comes to determine consensus > whether there is enough interest and support to warrant adopting > 'TLS Authorization' as a new work item, and if so, which > draft(s) to base the WG project on. > > I personally promise to review sound draft proposals in time > before such WG decision (perhaps not initial -00 versions, > only enough elaborate refined versions). > > > One immediate question to the group and the respective author: > > Draft-housley-tls-authz-extns only defines a framework, and > according to the past exegesis of the imprecise IPR statements > under discussion, only the application of that framework to > specific use cases might be encumbered by these claims. > However, the recent I-D, draft-keromytis-tls-authz-keynote-01, > together with a supporting sibling document, > draft-keromytis-keynote-x509-01 (both still rough and lacking > important details), defines a concrete instantiation of that > framework. > In how far is that instantiation encumbered by these IPR claims? > Is it burdened with other patent claims? > > > Kind regards, > Alfred H=CEnes. > > --=20 > > +------------------------=20 > +--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-=20 > Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: =20 > -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-=20 > Sys.de | > +------------------------=20 > +--------------------------------------------+ > > From Hannes.Tschofenig@gmx.net Thu Feb 12 10:22:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D963A6AC7 for ; Thu, 12 Feb 2009 10:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weKYuSU3GykD for ; Thu, 12 Feb 2009 10:22:31 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A2D273A69F9 for ; Thu, 12 Feb 2009 10:22:28 -0800 (PST) Received: (qmail invoked by alias); 12 Feb 2009 18:15:52 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp019) with SMTP; 12 Feb 2009 19:15:52 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/NVtYbF9nNHqObOFq71gqzDFtSzYzElIL5/oPXbc aTW7JFaHjxHqdZ From: "Hannes Tschofenig" To: "'Angelos D. Keromytis'" , =?iso-8859-1?Q?'Alfred_H=CEnes'?= References: <200902120002.BAA11916@TR-Sys.de> Date: Thu, 12 Feb 2009 20:16:43 +0200 Message-ID: <07d901c98d3e$0fdb9f70$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcmNOUsifPOne/+8RcqFVJ7RSjvsDAAA9Chw X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 X-Mailman-Approved-At: Thu, 12 Feb 2009 11:13:33 -0800 Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 18:22:31 -0000 The main issue I have been struggeling with these authorization = extensions inside TLS is that they happen at the wrong layer.=20 Today, we see similar functionality being deployed at higher layers. I = doubt that a standardized authorization mechanism inside TLS will have a lot = of impact.=20 Ciao Hannes >-----Original Message----- >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20 >Behalf Of Angelos D. Keromytis >Sent: 12 February, 2009 11:21 >To: Alfred H=CEnes >Cc: dean@av8.com; tls@ietf.org; ietf@ietf.org >Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07=20 > >Alfred, >neither of the cited KeyNote drafts (nor the KeyNote system=20 >itself) is patent-encumbered. However, I admit to not (yet)=20 >having paid close attention to the details of the IPR issues=20 >around tls-authz-extns itself and their potential impact to=20 >tls-authz-keynote. > >I have started draft-keromytis-keynote-x509-01 through the=20 >RFC- fication process (currently discussing with a reviewer),=20 >since it does not depend on authz (or any other pending work=20 >in any WG). I have been waiting for tls-authz-extns to go=20 >through the process before I start with=20 >draft-keromytis-tls-authz-keynote-01. I invite every=20 >interested party to send me comments. You may find it useful=20 >to first read RFCs >2704 (at least the first few sections) and 2792. >Best, >-Angelos > > >On Feb 11, 2009, at 7:02 PM, Alfred H=CEnes wrote: > >> At Wed, 11 Feb 2009 16:20:14 -0500 (EST), Dean Anderson wrote: >> >>> ... And as=20 >>> programmer and developer, I will probably have some non-patented=20 >>> alternatives to present. >>> >>> --Dean >> >> Dean, >> that's really laudable progress, leading back to technical=20 >discussion=20 >> of possible alternative solutions. >> Please indeed prepare such I-D as soon as feasible. >> >> >> I heartly invite other interested parties as well to submit their=20 >> proposals to the TLS WG, and I hereby explicitely would like to=20 >> address those many folks that newly started being interested in IETF=20 >> work in general and further development and application of TLS in=20 >> particular. >> >> In order to make life easier for all participants, I suggest=20 >to start=20 >> with streamlined draft names like draft--tlz-authz--00 . >> >> The WG should be able to perform an unprejudized discussion of=20 >> alternative proposals before it comes to determine consensus whether=20 >> there is enough interest and support to warrant adopting 'TLS=20 >> Authorization' as a new work item, and if so, which >> draft(s) to base the WG project on. >> >> I personally promise to review sound draft proposals in time before=20 >> such WG decision (perhaps not initial -00 versions, only enough=20 >> elaborate refined versions). >> >> >> One immediate question to the group and the respective author: >> >> Draft-housley-tls-authz-extns only defines a framework, and=20 >according=20 >> to the past exegesis of the imprecise IPR statements under=20 >discussion,=20 >> only the application of that framework to specific use cases=20 >might be=20 >> encumbered by these claims. >> However, the recent I-D, draft-keromytis-tls-authz-keynote-01, >> together with a supporting sibling document, >> draft-keromytis-keynote-x509-01 (both still rough and lacking=20 >> important details), defines a concrete instantiation of that=20 >> framework. >> In how far is that instantiation encumbered by these IPR claims? >> Is it burdened with other patent claims? >> >> >> Kind regards, >> Alfred H=CEnes. >> >> -- >> >> +------------------------ >> +--------------------------------------------+ >> | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-=20 >> Phys. | >> | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: =20 >> -18 | >> | D-71254 Ditzingen | E-Mail: ah@TR-=20 >> Sys.de | >> +------------------------ >> +--------------------------------------------+ >> >> > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf > From mshore@cisco.com Thu Feb 12 11:07:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 682CA3A6AAA; Thu, 12 Feb 2009 11:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obPQNCM0UU50; Thu, 12 Feb 2009 11:07:14 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 647DA3A6A06; Thu, 12 Feb 2009 11:07:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,198,1233532800"; d="scan'208";a="36893010" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Feb 2009 19:07:04 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1CJ74DU017271; Thu, 12 Feb 2009 14:07:04 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1CJ74kp011192; Thu, 12 Feb 2009 19:07:04 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Feb 2009 14:07:04 -0500 Received: from 10.98.54.215 ([10.98.54.215]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Feb 2009 19:07:03 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Thu, 12 Feb 2009 14:07:03 -0500 From: Melinda Shore To: Hannes Tschofenig Message-ID: Thread-Topic: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 Thread-Index: AcmNOUsifPOne/+8RcqFVJ7RSjvsDAAA9ChwAAH+vPc= In-Reply-To: <07d901c98d3e$0fdb9f70$0201a8c0@nsnintra.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Feb 2009 19:07:04.0504 (UTC) FILETIME=[179AA380:01C98D45] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=478; t=1234465624; x=1235329624; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[TLS]=20TLS=20WG=20Chair=20Comments=20o n=20draft-ietf-tls-authz-07=20 |Sender:=20 |To:=20Hannes=20Tschofenig=20; bh=/LSAJvrE6lO6pI1qtybQ5XHY4ze6ZZQrACVJMTKzXqE=; b=Jf9oI/NtDK6yFHjSSfw8tb7NOrUgyBY9xKY4aUulQ+1W49lIqcww328+bi QgE5V0OiY6RT3w2Vq+gA/PKXQ5Ie4hCV2xTaExSMSM6rRVrNW97/z0ShRTgQ WOeBid+bZL; Authentication-Results: rtp-dkim-1; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Mailman-Approved-At: Thu, 12 Feb 2009 11:13:33 -0800 Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 19:07:15 -0000 On 2/12/09 1:16 PM, "Hannes Tschofenig" wrote: > The main issue I have been struggeling with these authorization extensions > inside TLS is that they happen at the wrong layer. I don't know about that - I think it really depends on how the TLS session is being used, etc. I think that the more ability traffic has to describe itself the better, and that there are some non-trivial advantages to carrying authorizations in-band. Melinda From dean@av8.com Thu Feb 12 11:15:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F153A68A9 for ; Thu, 12 Feb 2009 11:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH63ZNh17k24 for ; Thu, 12 Feb 2009 11:15:33 -0800 (PST) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 0FA6F3A67AD for ; Thu, 12 Feb 2009 11:15:32 -0800 (PST) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n1CJFTfp014822 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 12 Feb 2009 14:15:29 -0500 Date: Thu, 12 Feb 2009 14:15:29 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: "Angelos D. Keromytis" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= , ietf-honest@lists.iadl.org, tls@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 19:15:34 -0000 Hi, I don't think it is true that these TLS-Authz-dependent drafts are not encumbered. They are merely not specifically mentioned, and I didn't even know about them until just now. The patent covers broad categories of authorizations, and it would seem that any framework for authorization using TLS-authz, as these documents are, must necessarilly fall into one of those categories for which a patent license is required in order to use the TLS-authz drafts. I think these drafts should wait until TLS-authz succeeds in being accepted, particularly since it is very unlikely that TLS-authz will ever be accepted or approved by any process involving community consensus. I think the significant opposition that has been demonstrated in the third and forth last calls demonstrates that this draft will not be approved. I note that there were even more opposition in the forth last call than in the third last call. I think the combination of misconduct and patent encumbrance ensures that a large part of the community will continue to oppose this standard. Opposition is growing, not fading. The misconduct continues with the recent destruction (spoliation) of evidence in removing IPR 765. IPR 765 was the first disclosure by Redphone of the patent and license terms offered by Redphone. While Alvestrand and the IESG previously assured the community that IPR disclosures would never be removed except for 'spam' and 'fiddling with the database', they reneged on their promises and removed IPR 765 anyway. IPR 765 reflected poorly on Redphone, and has been used to show their malfeasance. Destroying such evidence as IPR 765 is legal misconduct. A complaint was made to the IESG and the IETF Lawyer Jorge Contreras, but was ignored. Contreras also hasn't responded to email. The IESG has also recently stated to me that it not asked for legal advice in complaints involving their compliance with the law. This is all rather odd, and suggests that they know that their actions violate the law and violate their duties and are trying to avoid involving Contreras in unlawful acts. But, anyway, these dependent documents should also have IPR disclosures that reference the disclosures in TLS-authz, particularly IPR 765 and IPR 1026. --Dean On Thu, 12 Feb 2009, Angelos D. Keromytis wrote: > Alfred, > neither of the cited KeyNote drafts (nor the KeyNote system itself) is > patent-encumbered. However, I admit to not (yet) having paid close > attention to the details of the IPR issues around tls-authz-extns > itself and their potential impact to tls-authz-keynote. > > I have started draft-keromytis-keynote-x509-01 through the RFC- > fication process (currently discussing with a reviewer), since it does > not depend on authz (or any other pending work in any WG). I have been > waiting for tls-authz-extns to go through the process before I start > with draft-keromytis-tls-authz-keynote-01. I invite every interested > party to send me comments. You may find it useful to first read RFCs > 2704 (at least the first few sections) and 2792. > Best, > -Angelos > > > On Feb 11, 2009, at 7:02 PM, Alfred HÎnes wrote: > > > At Wed, 11 Feb 2009 16:20:14 -0500 (EST), Dean Anderson wrote: > > > >> ... And as > >> programmer and developer, I will probably have some non-patented > >> alternatives to present. > >> > >> --Dean > > > > Dean, > > that's really laudable progress, leading back to technical discussion > > of possible alternative solutions. > > Please indeed prepare such I-D as soon as feasible. > > > > > > I heartly invite other interested parties as well to submit their > > proposals to the TLS WG, and I hereby explicitely would like to > > address those many folks that newly started being interested in > > IETF work in general and further development and application of > > TLS in particular. > > > > In order to make life easier for all participants, > > I suggest to start with streamlined draft names like > > draft--tlz-authz--00 . > > > > The WG should be able to perform an unprejudized discussion > > of alternative proposals before it comes to determine consensus > > whether there is enough interest and support to warrant adopting > > 'TLS Authorization' as a new work item, and if so, which > > draft(s) to base the WG project on. > > > > I personally promise to review sound draft proposals in time > > before such WG decision (perhaps not initial -00 versions, > > only enough elaborate refined versions). > > > > > > One immediate question to the group and the respective author: > > > > Draft-housley-tls-authz-extns only defines a framework, and > > according to the past exegesis of the imprecise IPR statements > > under discussion, only the application of that framework to > > specific use cases might be encumbered by these claims. > > However, the recent I-D, draft-keromytis-tls-authz-keynote-01, > > together with a supporting sibling document, > > draft-keromytis-keynote-x509-01 (both still rough and lacking > > important details), defines a concrete instantiation of that > > framework. > > In how far is that instantiation encumbered by these IPR claims? > > Is it burdened with other patent claims? > > > > > > Kind regards, > > Alfred HÎnes. > > > > -- > > > > +------------------------ > > +--------------------------------------------+ > > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.- > > Phys. | > > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: > > -18 | > > | D-71254 Ditzingen | E-Mail: ah@TR- > > Sys.de | > > +------------------------ > > +--------------------------------------------+ > > > > > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From mike-list@pobox.com Thu Feb 12 11:58:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F8723A6AF7 for ; Thu, 12 Feb 2009 11:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lp64jNXTP5A for ; Thu, 12 Feb 2009 11:58:55 -0800 (PST) Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by core3.amsl.com (Postfix) with ESMTP id 8402C3A6ABA for ; Thu, 12 Feb 2009 11:58:54 -0800 (PST) Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 0596499908; Thu, 12 Feb 2009 14:58:59 -0500 (EST) Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 3D07F99907; Thu, 12 Feb 2009 14:58:56 -0500 (EST) Message-ID: <49947F70.6050906@pobox.com> Date: Thu, 12 Feb 2009 11:58:40 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ietf-honest@lists.iadl.org, tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 963D781E-F93F-11DD-9143-8B21C92D7133-38729857!a-sasl-fastnet.pobox.com Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 19:58:56 -0000 > I don't think it is true that these TLS-Authz-dependent drafts are not > encumbered. They are merely not specifically mentioned, and I didn't > even know about them until just now. The patent covers broad categories > of authorizations, and it would seem that any framework for > authorization using TLS-authz, as these documents are, must necessarilly > fall into one of those categories for which a patent license is required > in order to use the TLS-authz drafts. While it's probably too early to make decisions based on it, the courts have basically rendered software unpatentable. The new test for patent- ability requires either 1) a physical transformation of some sort, or 2) restriction to a specific machine (and a general purpose computer does not apply). This would imply that any pure software algorithm running on a general purpose computer can not be patented. Note that I am not a lawyer and am not attempting to provide legal advice. Mike From hartmans@mit.edu Thu Feb 12 14:39:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9743A696D; Thu, 12 Feb 2009 14:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5rVLj390nC5; Thu, 12 Feb 2009 14:39:49 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id ED7D33A68F6; Thu, 12 Feb 2009 14:39:48 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DAF944526; Thu, 12 Feb 2009 17:39:48 -0500 (EST) From: Sam Hartman To: "Josh Howlett" References: <07d901c98d3e$0fdb9f70$0201a8c0@nsnintra.net> <081b01c98d46$d8c731d0$0201a8c0@nsnintra.net> <6ED388AA006C454BA35B0098396B9BFB04CD3CC5@uxsrvr20.atlas.ukerna.ac.uk> Date: Thu, 12 Feb 2009 17:39:48 -0500 In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB04CD3CC5@uxsrvr20.atlas.ukerna.ac.uk> (Josh Howlett's message of "Thu, 12 Feb 2009 21:47:32 -0000") 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 Cc: Hannes Tschofenig , tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 22:39:50 -0000 >>>>> "Josh" == Josh Howlett writes: Josh> I have a long list of applications, collected from within Josh> this community, with which they would like to use SAML-based Josh> authorisation; and it seems to me that the ability for Josh> application protocols to share a common mechanism for Josh> expressing authorisation would mitigate or perhaps even Josh> avoid the need to make application-specific authorisation Josh> extensions. The Kerberos community has many years of experience that within an infrastructure, carrying authorizations in-band has been useful and has reduced the effort required to fit an application into a larger infrastructure. Sometimes it reduces implementation cost in that sometimes libraries can automatically handle some aspects of authorization. Mor often, it reduces the cost of specifying a protocol or adapting a protocol that was not intended to work within a given infrastructure to working within the infrastructure. In many cases, authorization handling becomes a matter for client libraries and the server implementation, requiring little if any effort from the client application or any changes to the client->server protocol. As a result, it becomes significantly easier to expand the authorization system. To a large extent, it becomes a matter of updating the infrastructure, and updating only one side of the application. That is a huge savings in deployment and software engineering complexity. I would expect that SAML infrastructures could see similar benefits. For these reasons I support the publication of a standard in this space. I don't object to this work going to the TLS working group provided that 1) it is within their current charter 2) They commit to do the work and have sufficient energy to move it forward quickly. I do object to moving the discussion of whether to solve this problem to the TLS working group. I don't think that is the right forum: the TLS working group does not collect the people who would benefit from this work. From Hannes.Tschofenig@gmx.net Thu Feb 12 11:18:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 499F03A6BA7 for ; Thu, 12 Feb 2009 11:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuRz8w2smqpE for ; Thu, 12 Feb 2009 11:18:44 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 816F53A6B58 for ; Thu, 12 Feb 2009 11:18:42 -0800 (PST) Received: (qmail invoked by alias); 12 Feb 2009 19:18:46 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp071) with SMTP; 12 Feb 2009 20:18:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19x1Fozbc1xXFyYQIcUCPueiVeBzcyraRj4y+Mf/y E5khugCz7VHio6 From: "Hannes Tschofenig" To: "'Melinda Shore'" References: <07d901c98d3e$0fdb9f70$0201a8c0@nsnintra.net> Date: Thu, 12 Feb 2009 21:19:36 +0200 Message-ID: <081b01c98d46$d8c731d0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcmNOUsifPOne/+8RcqFVJ7RSjvsDAAA9ChwAAH+vPcAAFRa0A== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7 X-Mailman-Approved-At: Thu, 12 Feb 2009 14:42:04 -0800 Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 19:18:45 -0000 Hi Melinda, >On 2/12/09 1:16 PM, "Hannes Tschofenig" > wrote: >> The main issue I have been struggeling with these authorization >> extensions inside TLS is that they happen at the wrong layer. > >I don't know about that - I think it really depends on how the >TLS session is being used, etc. Sure. A good example of SAML usage is WebSSO. Using SAML in that usage scenario requires a bit more than just carrying around the SAML assertion. > I think that the more ability >traffic has to describe itself the better, Not sure I understand that. > and that there are >some non-trivial advantages to carrying authorizations in-band. Namely... Ciao Hannes > >Melinda > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf > From Josh.Howlett@ja.net Thu Feb 12 13:47:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5A53A672F; Thu, 12 Feb 2009 13:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v3cImwBDxBD; Thu, 12 Feb 2009 13:47:41 -0800 (PST) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id EE5A328C226; Thu, 12 Feb 2009 13:47:40 -0800 (PST) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1LXjPJ-0006Uf-5O; Thu, 12 Feb 2009 21:47:41 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 3E2124A6B27_99498F1B; Thu, 12 Feb 2009 21:47:29 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 24C084A6A7D_99498EBF; Thu, 12 Feb 2009 21:47:23 +0000 (GMT) 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: Thu, 12 Feb 2009 21:47:32 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB04CD3CC5@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <081b01c98d46$d8c731d0$0201a8c0@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 Thread-Index: AcmNOUsifPOne/+8RcqFVJ7RSjvsDAAA9ChwAAH+vPcAAFRa0AAEND6w References: <07d901c98d3e$0fdb9f70$0201a8c0@nsnintra.net> <081b01c98d46$d8c731d0$0201a8c0@nsnintra.net> From: "Josh Howlett" To: "Hannes Tschofenig" , "Melinda Shore" X-Mailman-Approved-At: Thu, 12 Feb 2009 14:42:04 -0800 Cc: Josh Howlett , tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 21:47:41 -0000 Hannes wrote: > Melinda wrote: > > > > and that there are > > some non-trivial advantages to carrying authorizations in-band. > Namely...=20 I don't wish to speak for Melinda, but this is a view shared by many within my own community. I have a long list of applications, collected from within this community, with which they would like to use SAML-based authorisation; and it seems to me that the ability for application protocols to share a common mechanism for expressing authorisation would mitigate or perhaps even avoid the need to make application-specific authorisation extensions. (The fact that SAML-based Web SSO uses SAML that is bound to the application-layer is, I believe, only an artifact of a requirement to avoid modifying contemporary Web browsers and I don't think it is an approach that would necessarily be desirable for the general case.) Binding authorisation to TLS, as suggested by this document, is one approach that would satisfy the 'common mechanism' requirement indicated previously. josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From dean@av8.com Thu Feb 12 15:19:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB24028C245 for ; Thu, 12 Feb 2009 15:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PK-gnW88Cxib for ; Thu, 12 Feb 2009 15:19:46 -0800 (PST) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 2F66D28C232 for ; Thu, 12 Feb 2009 15:19:46 -0800 (PST) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n1CNJmQV015416 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 12 Feb 2009 18:19:49 -0500 Date: Thu, 12 Feb 2009 18:19:47 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: "Michael D'Errico" In-Reply-To: <49947F70.6050906@pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ietf-honest@lists.iadl.org, tls@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 23:19:47 -0000 Hi Michael, You're referring to In Re Bilski, decided in October. This decision was certainly in our favor, and it shows we are winning in a significant theatre of the war on software patents, but it doesn't make all software unpatentable. Not yet. Redphone's patent is still being examined, hasn't been rejected, and appears to be going forward. We have to base our actions and decisions on the expectation that the patent will be granted, as we have no guarentee that it won't beg granted. --Dean On Thu, 12 Feb 2009, Michael D'Errico wrote: > > I don't think it is true that these TLS-Authz-dependent drafts are not > > encumbered. They are merely not specifically mentioned, and I didn't > > even know about them until just now. The patent covers broad categories > > of authorizations, and it would seem that any framework for > > authorization using TLS-authz, as these documents are, must necessarilly > > fall into one of those categories for which a patent license is required > > in order to use the TLS-authz drafts. > > While it's probably too early to make decisions based on it, the courts > have basically rendered software unpatentable. The new test for patent- > ability requires either 1) a physical transformation of some sort, or > 2) restriction to a specific machine (and a general purpose computer does > not apply). This would imply that any pure software algorithm running on > a general purpose computer can not be patented. > > Note that I am not a lawyer and am not attempting to provide legal advice. > > Mike > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From peter.sylvester@edelweb.fr Thu Feb 12 15:28:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A3728C0ED; Thu, 12 Feb 2009 15:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiPOefmYv7si; Thu, 12 Feb 2009 15:28:24 -0800 (PST) Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by core3.amsl.com (Postfix) with ESMTP id 50C383A6C0C; Thu, 12 Feb 2009 15:28:24 -0800 (PST) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id 0483B6A; Fri, 13 Feb 2009 00:28:28 +0100 (CET) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id B003F17118; Fri, 13 Feb 2009 00:28:28 +0100 (CET) Received: from [192.168.0.15] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 784D077DC; Fri, 13 Feb 2009 00:28:28 +0100 (CET) Message-ID: <4994B09C.1080709@edelweb.fr> Date: Fri, 13 Feb 2009 00:28:28 +0100 From: Peter Sylvester User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Hannes Tschofenig References: <07d901c98d3e$0fdb9f70$0201a8c0@nsnintra.net> <081b01c98d46$d8c731d0$0201a8c0@nsnintra.net> In-Reply-To: <081b01c98d46$d8c731d0$0201a8c0@nsnintra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 23:28:25 -0000 >> and that there are >> some non-trivial advantages to carrying authorizations in-band. >> > Namely... > > Independance between payload and security measures. Piggybagging information on lower layers is a very old concept. https was successful over shttp. I think the patent is made by trolls. There seems to be lots of evidence of prior art. sending an OSCP response as part of the TLS session setup is a standard, where is the difference? The current hacks to carry SAML assertion using additional http connection is inefficient, mildly speaking. The authz has technical problems. I encourage the TLS working group members to seriously treat the issue. Peter Sylvester From Hannes.Tschofenig@gmx.net Thu Feb 12 14:56:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E3D3A6951 for ; Thu, 12 Feb 2009 14:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMjBqr9OqfAM for ; Thu, 12 Feb 2009 14:56:25 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5EBD23A68F6 for ; Thu, 12 Feb 2009 14:56:21 -0800 (PST) Received: (qmail invoked by alias); 12 Feb 2009 22:49:45 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp010) with SMTP; 12 Feb 2009 23:49:45 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18MPtVEvDcMJrU1WiXqJL2y5Tgj7U3Xa0SjwAjj5O TyCI4QuJk+3uts From: "Hannes Tschofenig" To: "'Josh Howlett'" , "'Melinda Shore'" References: <07d901c98d3e$0fdb9f70$0201a8c0@nsnintra.net> <081b01c98d46$d8c731d0$0201a8c0@nsnintra.net> <6ED388AA006C454BA35B0098396B9BFB04CD3CC5@uxsrvr20.atlas.ukerna.ac.uk> Date: Fri, 13 Feb 2009 00:50:34 +0200 Message-ID: <084f01c98d64$51118b00$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB04CD3CC5@uxsrvr20.atlas.ukerna.ac.uk> Thread-Index: AcmNOUsifPOne/+8RcqFVJ7RSjvsDAAA9ChwAAH+vPcAAFRa0AAEND6wAALDcLA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 X-Mailman-Approved-At: Thu, 12 Feb 2009 22:45:28 -0800 Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 22:56:25 -0000 Hi Josh, >Hannes wrote: >> Melinda wrote: >> > >> > and that there are >> > some non-trivial advantages to carrying authorizations in-band. >> Namely... > >I don't wish to speak for Melinda, but this is a view shared >by many within my own community. > >I have a long list of applications, collected from within this >community, with which they would like to use SAML-based >authorisation; Interesting. Any interest to share it with us? >and it seems to me that the ability for >application protocols to share a common mechanism for >expressing authorisation would mitigate or perhaps even avoid >the need to make application-specific authorisation extensions. My experience: authorization is often related to the specific application domain. Furthermore, working on SIP SAML I noticed the problems when you go down to specific solutions scenarios. >(The fact that SAML-based Web SSO uses SAML that is bound to >the application-layer is, I believe, only an artifact of a >requirement to avoid modifying contemporary Web browsers and I >don't think it is an approach that would necessarily be >desirable for the general case.) ... a reasonable transition plan, in my view. The reason for the success of these IdM solutions, particularly OpenID. >Binding authorisation to TLS, as suggested by this document, >is one approach that would satisfy the 'common mechanism' >requirement indicated previously. Looking forward to see your solutions. Ciao Hannes > >josh. > >JANET(UK) is a trading name of The JNT Association, a company >limited by guarantee which is registered in England under No. >2881024 and whose Registered Office is at Lumen House, Library >Avenue, Harwell Science and Innovation Campus, Didcot, >Oxfordshire. OX11 0SG > From DPKemp@missi.ncsc.mil Fri Feb 13 06:07:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997FB3A6B77; Fri, 13 Feb 2009 06:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJFJx192vd4P; Fri, 13 Feb 2009 06:07:42 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id AFE153A6A86; Fri, 13 Feb 2009 06:07:42 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 13 Feb 2009 09:07:19 -0500 Message-ID: <200902131407.n1DE7YDn008012@stingray.missi.ncsc.mil> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 Thread-Index: AcmN2Itziawv3ySCTIqSyqg+e5X0yQACJ9eQ References: <07d901c98d3e$0fdb9f70$0201a8c0@nsnintra.net><081b01c98d46$d8c731d0$0201a8c0@nsnintra.net><6ED388AA006C454BA35B0098396B9BFB04CD3CC5@uxsrvr20.atlas.ukerna.ac.uk> From: "Kemp, David P." To: , X-OriginalArrivalTime: 13 Feb 2009 14:03:20.0640 (UTC) FILETIME=[D3BF6C00:01C98DE3] Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 14:07:43 -0000 Sam, Is your suggestion that there is a better existing working group, or to establish one through the BOF process? We are interested both in leveraging at the application layer an authentication context established by TLS between A and B (as opposed to relying on an SSO assertion from C to B that C has authenticated A), and in carrying A's authorization-related attributes (pre-signed by C) within that context. I was aware of this discussion only because it came to TLS, and would welcome a pointer to the right forum. -----Original Message----- From: Sam Hartman Sent: Thursday, February 12, 2009 5:40 PM To: Josh Howlett Cc: Hannes Tschofenig; tls@ietf.org; ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 [...] For these reasons I support the publication of a standard in this space. I don't object to this work going to the TLS working group provided that=20 1) it is within their current charter 2) They commit to do the work and have sufficient energy to move it forward quickly. I do object to moving the discussion of whether to solve this problem to the TLS working group. I don't think that is the right forum: the TLS working group does not collect the people who would benefit from this work. From mshore@cisco.com Fri Feb 13 06:38:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D2E3A6BE0; Fri, 13 Feb 2009 06:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0GFlgFtIMew; Fri, 13 Feb 2009 06:38:25 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BD10A3A67F7; Fri, 13 Feb 2009 06:38:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,202,1233532800"; d="scan'208";a="36950029" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Feb 2009 14:38:30 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1DEcURs019577; Fri, 13 Feb 2009 09:38:30 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1DEcUqS025907; Fri, 13 Feb 2009 14:38:30 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 09:38:30 -0500 Received: from 10.98.54.215 ([10.98.54.215]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Feb 2009 14:38:30 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Fri, 13 Feb 2009 09:38:29 -0500 From: Melinda Shore To: Josh Howlett Message-ID: Thread-Topic: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 Thread-Index: AcmNOUsifPOne/+8RcqFVJ7RSjvsDAAA9ChwAAH+vPcAAFRa0AAEND6wACRg1lE= In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB04CD3CC5@uxsrvr20.atlas.ukerna.ac.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Feb 2009 14:38:30.0819 (UTC) FILETIME=[BD832F30:01C98DE8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1165; t=1234535911; x=1235399911; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[TLS]=20TLS=20WG=20Chair=20Comments=20o n=20draft-ietf-tls-authz-07=20 |Sender:=20 |To:=20Josh=20Howlett=20; bh=rvDGb4GmAEcdRUT66FmsKEZfpxdGTb8yZavvD+abOzQ=; b=C3XNQoc8jT00lg3i/b3y0UUKzyPO8enJF6aEHpmcHUay2QhgiulpRngj+o G4TPwYdpido44Ge64mJmUdR8JQWGGy5GqidKt/ydIHPq8i+VdGxOIeU75VEi QQ80DjBn+Y; Authentication-Results: rtp-dkim-1; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 14:38:26 -0000 On 2/12/09 4:47 PM, "Josh Howlett" wrote: > I have a long list of applications, collected from within this > community, with which they would like to use SAML-based authorisation; > and it seems to me that the ability for application protocols to share a > common mechanism for expressing authorisation would mitigate or perhaps > even avoid the need to make application-specific authorisation > extensions. Right, and to be more specific about it, the kinds of things that we're talking about include reducing retained state on devices during the authorization process by eliminating queries, reducing the problems around service discovery and topology, and I tend to think that there are some cross-domain advantages, as well. There are fate-sharing considerations, where the authorizations aren't held by devices that don't need them, they're not delivered if the traffic isn't delivered, and if the traffic is delivered the authorizations are delivered. So, I think that in addition to some issues specific to authorization problems there are some advantages around traditional networking considerations. Melinda From Josh.Howlett@ja.net Fri Feb 13 01:40:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 822713A68E7; Fri, 13 Feb 2009 01:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ir0JSu+Q40fl; Fri, 13 Feb 2009 01:40:46 -0800 (PST) Received: from umhost1.ukerna.ac.uk (umhost1.ukerna.ac.uk [193.62.83.67]) by core3.amsl.com (Postfix) with ESMTP id 9813B3A684A; Fri, 13 Feb 2009 01:40:46 -0800 (PST) Received: from har003676.ukerna.ac.uk ([194.82.140.75]) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1LXuXQ-0006mn-4g; Fri, 13 Feb 2009 09:40:48 +0000 Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 47E8D4A6B1F_9954013B; Fri, 13 Feb 2009 09:40:35 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 24E344A6B7D_995400DF; Fri, 13 Feb 2009 09:40:29 +0000 (GMT) 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: Fri, 13 Feb 2009 09:40:46 -0000 Message-ID: <6ED388AA006C454BA35B0098396B9BFB04CD3D2A@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <084f01c98d64$51118b00$0201a8c0@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 Thread-Index: AcmNOUsifPOne/+8RcqFVJ7RSjvsDAAA9ChwAAH+vPcAAFRa0AAEND6wAALDcLAAFl3XsA== References: <07d901c98d3e$0fdb9f70$0201a8c0@nsnintra.net> <081b01c98d46$d8c731d0$0201a8c0@nsnintra.net> <6ED388AA006C454BA35B0098396B9BFB04CD3CC5@uxsrvr20.atlas.ukerna.ac.uk> <084f01c98d64$51118b00$0201a8c0@nsnintra.net> From: "Josh Howlett" To: "Hannes Tschofenig" , "Melinda Shore" X-Mailman-Approved-At: Fri, 13 Feb 2009 06:57:21 -0800 Cc: Josh Howlett , tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 09:40:47 -0000 Hi Hans, > >Hannes wrote: > >> Melinda wrote: > >> > > >> > and that there are > >> > some non-trivial advantages to carrying authorizations in-band. > >> Namely...=20 > > > >I don't wish to speak for Melinda, but this is a view shared by many=20 > >within my own community. > > > >I have a long list of applications, collected from within this=20 > >community, with which they would like to use SAML-based=20 > authorisation; >=20 > Interesting. Any interest to share it with us? I'm in the process of trying to flesh it out at the moment, in a collaboration with some of the communities concerned, so that we can articulate some concrete use-cases. At the moment the list covers pretty much everything that is presently used in an Inter-Institutional context (AFS, SSH, VNC, RDP, SIP, SMTP, NEA, ...). > >and it seems to me that the ability for application=20 > protocols to share=20 > >a common mechanism for expressing authorisation would mitigate or=20 > >perhaps even avoid the need to make application-specific=20 > authorisation=20 > >extensions. >=20 > My experience: authorization is often related to the specific=20 > application domain. I agree insofar as 'authorisation' is often an exercise in making statements using semantics that are specific to application domains, but I don't believe it follows that the syntactical and transport elements (that support the semantic expression) also need to be specific to the application domain. > Furthermore, working on SIP SAML I noticed the problems when=20 > you go down to specific solutions scenarios. Can you expand? > >(The fact that SAML-based Web SSO uses SAML that is bound to the=20 > >application-layer is, I believe, only an artifact of a=20 > requirement to=20 > >avoid modifying contemporary Web browsers and I don't think it is an=20 > >approach that would necessarily be desirable for the general case.) >=20 > ... a reasonable transition plan, in my view. Sure. > The reason for the success of these IdM solutions,=20 > particularly OpenID. (Well - OpenID has been a flop in my opinion. It has its uses, but not very interesting ones. But I digress...) > >Binding authorisation to TLS, as suggested by this document, is one=20 > >approach that would satisfy the 'common mechanism' > >requirement indicated previously. >=20 > Looking forward to see your solutions. I have no answers; I'm still trying to figure out what the questions are :-/ josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From DPKemp@missi.ncsc.mil Fri Feb 13 07:52:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECCD228C257; Fri, 13 Feb 2009 07:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxbBBTwoFboD; Fri, 13 Feb 2009 07:52:03 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 0145F3A6B7E; Fri, 13 Feb 2009 07:52:02 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 13 Feb 2009 10:52:03 -0500 Message-ID: <200902131552.n1DFqA1K012845@stingray.missi.ncsc.mil> In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB04CD3D2A@uxsrvr20.atlas.ukerna.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 Thread-Index: AcmNOUsifPOne/+8RcqFVJ7RSjvsDAAA9ChwAAH+vPcAAFRa0AAEND6wAALDcLAAFl3XsAAM8tnw References: <07d901c98d3e$0fdb9f70$0201a8c0@nsnintra.net><081b01c98d46$d8c731d0$0201a8c0@nsnintra.net><6ED388AA006C454BA35B0098396B9BFB04CD3CC5@uxsrvr20.atlas.ukerna.ac.uk><084f01c98d64$51118b00$0201a8c0@nsnintra.net> <6ED388AA006C454BA35B0098396B9BFB04CD3D2A@uxsrvr20.atlas.ukerna.ac.uk> From: "Kemp, David P." To: , X-OriginalArrivalTime: 13 Feb 2009 15:47:55.0406 (UTC) FILETIME=[6FCCBAE0:01C98DF2] Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 15:52:04 -0000 I too would like to figure out what the questions are. The draft is not about carrying "authorizations" in TLS, or that "The main issue with these authorization extensions inside TLS is that they happen at the wrong layer" as stated by Hannes Tschofenig. Authorization happens at the application layer. Data is transported at the transport layer. The draft is about carrying data (SAML assertions, attribute certificates, or pointers thereto) that can be used or ignored by applications when those applications make authorization decisions. What application domain is involved when I hand someone a certificate (driver's license) stating that I was born on MMDDYYYY? It only becomes part of an application domain when the "someone" is instantiated as a store clerk who needs to decide whether I am authorized to buy cigarettes or liquor. The clerk is doing the authorization, not the certificate. Since Mr. Anderson is so exercised about the word "authorization" in the name of the I-D, perhaps it should be renamed "draft-ietf-tls-attributes-07". That would avoid the IPR issues entirely, since one can transport an attribute certificate without ever using it to authorize anything. -----Original Message----- From: Josh Howlett [...] > My experience: authorization is often related to the specific=20 > application domain. I agree insofar as 'authorisation' is often an exercise in making statements using semantics that are specific to application domains, but I don't believe it follows that the syntactical and transport elements (that support the semantic expression) also need to be specific to the application domain. [...] > Looking forward to see your solutions. I have no answers; I'm still trying to figure out what the questions are :-/ From dean@av8.com Fri Feb 13 09:56:18 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82C63A6D91; Fri, 13 Feb 2009 09:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vApJjVrMrFoq; Fri, 13 Feb 2009 09:56:17 -0800 (PST) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 754BD3A6D8D; Fri, 13 Feb 2009 09:56:17 -0800 (PST) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n1DHuKun018757 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 Feb 2009 12:56:20 -0500 Date: Fri, 13 Feb 2009 12:56:19 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: "Kemp, David P." In-Reply-To: <200902131552.n1DFqA1K012845@stingray.missi.ncsc.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ietf-honest@lists.iadl.org, ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 17:56:18 -0000 Hi David, There is nothing in the word "authorization" that bothers me. What bothers me is the patent itself, the patent non-disclosure, the conflict of interest in having the IETF chair selling his position, the conflict of interest in Housley's business partner Polk advance Housley's draft after repeated massive rejections of last calls, and the destruction of evidence removing IPR disclosures. Working in the government, you must have some appreciation of the propriety of such acts. But otherwise than that, I'm totally fine with authorization as a notion and a name. It is a done deal that the TLS WG will take on this work? Or will it pass on it? Rescorla and Salowey weren't exactly clear that the WG would take it. I'll start working on a draft that doesn't violate the patent, if the WG is going to work on it. --Dean On Fri, 13 Feb 2009, Kemp, David P. wrote: > I too would like to figure out what the questions are. The draft is not > about carrying "authorizations" in TLS, or that "The main issue with > these authorization extensions inside TLS is that they happen at the > wrong layer" as stated by Hannes Tschofenig. > > Authorization happens at the application layer. Data is transported at > the transport layer. The draft is about carrying data (SAML assertions, > attribute certificates, or pointers thereto) that can be used or ignored > by applications when those applications make authorization decisions. > > What application domain is involved when I hand someone a certificate > (driver's license) stating that I was born on MMDDYYYY? It only becomes > part of an application domain when the "someone" is instantiated as a > store clerk who needs to decide whether I am authorized to buy > cigarettes or liquor. The clerk is doing the authorization, not the > certificate. > > Since Mr. Anderson is so exercised about the word "authorization" in the > name of the I-D, perhaps it should be renamed > "draft-ietf-tls-attributes-07". That would avoid the IPR issues > entirely, since one can transport an attribute certificate without ever > using it to authorize anything. > > > > > -----Original Message----- > From: Josh Howlett > > [...] > > > My experience: authorization is often related to the specific > > application domain. > > I agree insofar as 'authorisation' is often an exercise in making > statements using semantics that are specific to application domains, but > I don't believe it follows that the syntactical and transport elements > (that support the semantic expression) also need to be specific to the > application domain. > > [...] > > > Looking forward to see your solutions. > > I have no answers; I'm still trying to figure out what the questions are > :-/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From DPKemp@missi.ncsc.mil Fri Feb 13 10:57:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F213628C2AD; Fri, 13 Feb 2009 10:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttFqByoUj0J1; Fri, 13 Feb 2009 10:57:28 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id BC21F28C28E; Fri, 13 Feb 2009 10:57:28 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 13 Feb 2009 13:57:00 -0500 Message-ID: <200902131857.n1DIvYZl020354@stingray.missi.ncsc.mil> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 Thread-Index: AcmOBHmg8XTZzdB5TzGk3LtNYwRHKgAA+1Hw References: <200902131552.n1DFqA1K012845@stingray.missi.ncsc.mil> From: "Kemp, David P." To: "Dean Anderson" X-OriginalArrivalTime: 13 Feb 2009 18:53:18.0968 (UTC) FILETIME=[55F59780:01C98E0C] Cc: ietf-honest@lists.iadl.org, ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 18:57:30 -0000 What bothers me is the assertion that a specification for using TLS to carry information (attributes) about entities could possibly infringe on any patent related to authorization. Sending an X.509 attribute certificate containing my date of birth over TLS says precisely nothing about what any application might authorize me to do. And even without the client_authz and server_authz extensions, the TLS protocol itself would carry the same information about me if the DOB attribute were included in my X.509 public key certificate. Does that mean TLS should be abandoned? The assertion of encumbrance is as ridiculous as saying: 1) http can be (and has been) used to transport copyrighted music 2) therefore RFC 2616 should never have been worked on, or approved by, the IETF I reject that assertion. -----Original Message----- From: Dean Anderson [mailto:dean@av8.com]=20 Sent: Friday, February 13, 2009 12:56 PM To: Kemp, David P. Cc: ietf@ietf.org; ietf-honest@lists.iadl.org; tls@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 Hi David, There is nothing in the word "authorization" that bothers me. What bothers me is the patent itself, the patent non-disclosure, the conflict of interest in having the IETF chair selling his position, the conflict of interest in Housley's business partner Polk advance Housley's draft after repeated massive rejections of last calls, and the destruction of evidence removing IPR disclosures. Working in the government, you must have some appreciation of the propriety of such acts. But otherwise than that, I'm totally fine with authorization as a notion and a name. It is a done deal that the TLS WG will take on this work? Or will it pass on it? Rescorla and Salowey weren't exactly clear that the WG would take it. I'll start working on a draft that doesn't violate the patent, if the WG is going to work on it. --Dean On Fri, 13 Feb 2009, Kemp, David P. wrote: > I too would like to figure out what the questions are. The draft is not > about carrying "authorizations" in TLS, or that "The main issue with > these authorization extensions inside TLS is that they happen at the > wrong layer" as stated by Hannes Tschofenig. >=20 > Authorization happens at the application layer. Data is transported at > the transport layer. The draft is about carrying data (SAML assertions, > attribute certificates, or pointers thereto) that can be used or ignored > by applications when those applications make authorization decisions. >=20 > What application domain is involved when I hand someone a certificate > (driver's license) stating that I was born on MMDDYYYY? It only becomes > part of an application domain when the "someone" is instantiated as a > store clerk who needs to decide whether I am authorized to buy > cigarettes or liquor. The clerk is doing the authorization, not the > certificate. >=20 > Since Mr. Anderson is so exercised about the word "authorization" in the > name of the I-D, perhaps it should be renamed > "draft-ietf-tls-attributes-07". That would avoid the IPR issues > entirely, since one can transport an attribute certificate without ever > using it to authorize anything. >=20 >=20 >=20 >=20 > -----Original Message----- > From: Josh Howlett >=20 > [...] >=20 > > My experience: authorization is often related to the specific=20 > > application domain. >=20 > I agree insofar as 'authorisation' is often an exercise in making > statements using semantics that are specific to application domains, but > I don't believe it follows that the syntactical and transport elements > (that support the semantic expression) also need to be specific to the > application domain. >=20 > [...] >=20 > > Looking forward to see your solutions. >=20 > I have no answers; I'm still trying to figure out what the questions are > :-/ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 >=20 --=20 Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 =20 From ekr@networkresonance.com Sat Feb 14 06:49:07 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE90A3A6A15 for ; Sat, 14 Feb 2009 06:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAgkQFfjMP-o for ; Sat, 14 Feb 2009 06:49:07 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 4A7263A6359 for ; Sat, 14 Feb 2009 06:49:07 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id EBDA250872; Sat, 14 Feb 2009 07:06:04 -0800 (PST) Date: Sat, 14 Feb 2009 07:06:04 -0800 From: Eric Rescorla To: Michael D'Errico In-Reply-To: <49947F70.6050906@pobox.com> References: <49947F70.6050906@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090214150604.EBDA250872@romeo.rtfm.com> Cc: ietf-honest@lists.iadl.org, tls@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 14:49:08 -0000 At Thu, 12 Feb 2009 11:58:40 -0800, Michael D'Errico wrote: > > > I don't think it is true that these TLS-Authz-dependent drafts are not > > encumbered. They are merely not specifically mentioned, and I didn't > > even know about them until just now. The patent covers broad categories > > of authorizations, and it would seem that any framework for > > authorization using TLS-authz, as these documents are, must necessarilly > > fall into one of those categories for which a patent license is required > > in order to use the TLS-authz drafts. > > While it's probably too early to make decisions based on it, the courts > have basically rendered software unpatentable. The new test for patent- > ability requires either 1) a physical transformation of some sort, or > 2) restriction to a specific machine (and a general purpose computer does > not apply). This would imply that any pure software algorithm running on > a general purpose computer can not be patented. > > Note that I am not a lawyer and am not attempting to provide legal advice. Folks, It's fine to discuss the Redphone patents specifically in the context of whether TLS should adopt work in this area (though note that no such work has been proposed in TLS at this time). However, the general question of the patentability of software is not relevant to the TLS WG and should be discussed elsewhere. -Ekr [As WG Chair] From Hannes.Tschofenig@gmx.net Sat Feb 14 12:58:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B9828C0F3 for ; Sat, 14 Feb 2009 12:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrDwdvsU+YSI for ; Sat, 14 Feb 2009 12:58:18 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AEC9B3A68D7 for ; Sat, 14 Feb 2009 12:58:17 -0800 (PST) Received: (qmail invoked by alias); 14 Feb 2009 20:58:25 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp036) with SMTP; 14 Feb 2009 21:58:25 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+pEY5oxGOp3TziiIcVB2oSwuZ2Laj6L3F02ZLL0b I+2fCVVZm6ySgh From: "Hannes Tschofenig" To: "'Josh Howlett'" , "'Melinda Shore'" References: <07d901c98d3e$0fdb9f70$0201a8c0@nsnintra.net> <081b01c98d46$d8c731d0$0201a8c0@nsnintra.net> <6ED388AA006C454BA35B0098396B9BFB04CD3CC5@uxsrvr20.atlas.ukerna.ac.uk> <084f01c98d64$51118b00$0201a8c0@nsnintra.net> <6ED388AA006C454BA35B0098396B9BFB04CD3D2A@uxsrvr20.atlas.ukerna.ac.uk> Date: Sat, 14 Feb 2009 22:59:17 +0200 Message-ID: <00b101c98ee7$1a391d30$3fb5b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB04CD3D2A@uxsrvr20.atlas.ukerna.ac.uk> Thread-Index: AcmNOUsifPOne/+8RcqFVJ7RSjvsDAAA9ChwAAH+vPcAAFRa0AAEND6wAALDcLAAFl3XsABJixlA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 20:58:19 -0000 Hi Josh, >Hi Hans, > >> >Hannes wrote: >> >> Melinda wrote: >> >> > >> >> > and that there are >> >> > some non-trivial advantages to carrying authorizations in-band. >> >> Namely... >> > >> >I don't wish to speak for Melinda, but this is a view >shared by many >> >within my own community. >> > >> >I have a long list of applications, collected from within this >> >community, with which they would like to use SAML-based >> authorisation; >> >> Interesting. Any interest to share it with us? > >I'm in the process of trying to flesh it out at the moment, in >a collaboration with some of the communities concerned, so >that we can articulate some concrete use-cases. At the moment >the list covers pretty much everything that is presently used >in an Inter-Institutional context (AFS, SSH, VNC, RDP, SIP, >SMTP, NEA, ...). Looking forward to see more about it. > >> >and it seems to me that the ability for application >> protocols to share >> >a common mechanism for expressing authorisation would mitigate or >> >perhaps even avoid the need to make application-specific >> authorisation >> >extensions. >> >> My experience: authorization is often related to the specific >> application domain. > >I agree insofar as 'authorisation' is often an exercise in >making statements using semantics that are specific to >application domains, but I don't believe it follows that the >syntactical and transport elements (that support the semantic >expression) also need to be specific to the application domain. > >> Furthermore, working on SIP SAML I noticed the problems when you go >> down to specific solutions scenarios. > >Can you expand? Look at http://tools.ietf.org/html/draft-ietf-sip-saml-05. We started with a specific problem in mind, described in RFC 4484. There are obviously different design approaches one can take and SIP is a complex protocol and hence there are not always point-to-point interactions making it somewhat difficult to provide similar functionality at a lower layer. With specific details about the actual authorization statements we also had a hard time. We published a few specifications (all expired in the meanwhile) that discussed more or less complex attributes. Examples: http://tools.ietf.org/html/draft-schubert-sipping-saml-cpc-02 http://tools.ietf.org/html/draft-schwartz-sipping-spit-saml-01 http://tools.ietf.org/html/draft-jennings-sipping-pay-06 Since you mentioned SIP as one of the usage scenarios in the paragraph above you might have had other use cases in mind. For many of the protocols and usage scenarios it may not even be so obvious what SAML can actually give you (not even touching the subject of where to put the SAML assertions). My fear about SAML in TLS was a history like the following one: * Hmmm. SAML becomes popular. We should put it in every protocol. * There isn't an extension for TLS defined yet. Let's do it. * Now, let's search for the problems it could solve. >> >(The fact that SAML-based Web SSO uses SAML that is bound to the >> >application-layer is, I believe, only an artifact of a >> requirement to >> >avoid modifying contemporary Web browsers and I don't think >it is an >> >approach that would necessarily be desirable for the general case.) >> >> ... a reasonable transition plan, in my view. > >Sure. > >> The reason for the success of these IdM solutions, particularly >> OpenID. > >(Well - OpenID has been a flop in my opinion. It has its uses, >but not very interesting ones. But I digress...) There are different camps, without doubt. Just to point you to one other opinion -- Jeff Schiller's webblog I recently discovered: http://qyv.net/jisblog/2007/05/08/identity-on-the-internet/ > >> >Binding authorisation to TLS, as suggested by this document, is one >> >approach that would satisfy the 'common mechanism' >> >requirement indicated previously. >> >> Looking forward to see your solutions. > >I have no answers; I'm still trying to figure out what the >questions are :-/ I was referring to the usage scenarios you are working on. Btw, I am not suggesting that folks shouldn't spend their time on usage of authorization in TLS. I am more looking for some of the background of the work as it often not too obvious from the pure specification. Your pointer to http://kerberos.org/software/kerbweb.pdf is certainly helpful for a number of folks -- I have learned it already from Jeff. Ciao Hannes > >josh. > >JANET(UK) is a trading name of The JNT Association, a company >limited by guarantee which is registered in England under No. >2881024 and whose Registered Office is at Lumen House, Library >Avenue, Harwell Science and Innovation Campus, Didcot, >Oxfordshire. OX11 0SG > From Hannes.Tschofenig@gmx.net Sat Feb 14 13:04:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 212E43A6C34 for ; Sat, 14 Feb 2009 13:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mru4wweMN8yC for ; Sat, 14 Feb 2009 13:04:56 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 877D93A6BF3 for ; Sat, 14 Feb 2009 13:04:55 -0800 (PST) Received: (qmail invoked by alias); 14 Feb 2009 20:58:20 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp042) with SMTP; 14 Feb 2009 21:58:20 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX180X4laO7Q0W2ALktvadAPe2Wb+XB1Hh2n9p3o5vv cp0oytBNdt2IZX From: "Hannes Tschofenig" To: "'Sam Hartman'" , "'Josh Howlett'" References: <07d901c98d3e$0fdb9f70$0201a8c0@nsnintra.net><081b01c98d46$d8c731d0$0201a8c0@nsnintra.net><6ED388AA006C454BA35B0098396B9BFB04CD3CC5@uxsrvr20.atlas.ukerna.ac.uk> Date: Sat, 14 Feb 2009 22:59:12 +0200 Message-ID: <00b001c98ee7$17c13f60$3fb5b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcmNYteVOXYZkLrCRjG4kjJGgs6npwBfcfRQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: tls@ietf.org, ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 21:04:56 -0000 Hi Sam, I am aware of some of the authorization mechanisms used in Kerberos (e.g., those introduced by Microsoft). The issue here is a bit different, particularly on the Internet (in comparison to the pure enterprise space). We see a good deal of SSO solutions being deployed. To provide incremental deployment the protocol designers have written their specs in such a way that they do not require end host modifications. It turned out that this is a fairly good idea to find excitement in the industry. It seems that end host changes (even if they are only in the browser) aren't so easy. Many other solutions are theoretically possible to solve the WebSSO problem when you assume end host modifications are possible. Now, the question (for me) is why someone should deploy a new technique that requires end host modifications when they can get a similar result with already widely deployed mechanisms. (Not speaking about the OpenID being fairly popular on the Internet due to it's simple deployment model.) To answer this question, I believe, one has to start with a particular problem / usage scenario. I don't want to prevent anyone from standardizing (or even implementing) new authorization extensions for TLS but all the discussions we see about the IPRs are IMHO a bit over the top. I have a hard time seeing the widespread deployment in front of me. I could be wrong -- we will see in a few years. Ciao Hannes >-----Original Message----- >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On >Behalf Of Sam Hartman >Sent: 13 February, 2009 00:40 >To: Josh Howlett >Cc: Melinda Shore; Hannes Tschofenig; tls@ietf.org; ietf@ietf.org >Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 > >>>>>> "Josh" == Josh Howlett writes: > > Josh> I have a long list of applications, collected from within > Josh> this community, with which they would like to use SAML-based > Josh> authorisation; and it seems to me that the ability for > Josh> application protocols to share a common mechanism for > Josh> expressing authorisation would mitigate or perhaps even > Josh> avoid the need to make application-specific authorisation > Josh> extensions. > > >The Kerberos community has many years of experience that >within an infrastructure, carrying authorizations in-band has >been useful and has reduced the effort required to fit an >application into a larger infrastructure. Sometimes it >reduces implementation cost in that sometimes libraries can >automatically handle some aspects of authorization. Mor >often, it reduces the cost of specifying a protocol or >adapting a protocol that was not intended to work within a >given infrastructure to working within the infrastructure. In >many cases, authorization handling becomes a matter for client >libraries and the server implementation, requiring little if >any effort from the client application or any changes to the >client->server protocol. > >As a result, it becomes significantly easier to expand the >authorization system. To a large extent, it becomes a matter >of updating the infrastructure, and updating only one side of >the application. That is a huge savings in deployment and >software engineering complexity. > > > >I would expect that SAML infrastructures could see similar benefits. > >For these reasons I support the publication of a standard in >this space. I don't object to this work going to the TLS >working group provided that >1) it is within their current charter >2) They commit to do the work and have sufficient energy to >move it forward quickly. > >I do object to moving the discussion of whether to solve this >problem to the TLS working group. I don't think that is the >right forum: the TLS working group does not collect the people >who would benefit from this work. > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf > From seggelmann@fh-muenster.de Wed Feb 25 03:16:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9AE3A6B78 for ; Wed, 25 Feb 2009 03:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zJ-zknh6Qof for ; Wed, 25 Feb 2009 03:16:49 -0800 (PST) Received: from smtprelay09.ispgateway.de (smtprelay09.ispgateway.de [80.67.29.23]) by core3.amsl.com (Postfix) with ESMTP id 3A8E23A6A63 for ; Wed, 25 Feb 2009 03:16:49 -0800 (PST) Received: from [194.95.73.188] (helo=[10.0.1.198]) by smtprelay09.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LcHlE-0006GM-6i for tls@ietf.org; Wed, 25 Feb 2009 12:17:08 +0100 Message-Id: From: Robin Seggelmann To: tls@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 12:17:07 +0100 X-Mailer: Apple Mail (2.930.3) X-Df-Sender: 229264 Subject: [TLS] DTLS retransmission problem X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 11:16:50 -0000 While testing the retransmission functionallity of my DTLS implementation, I have found a problem which is not covered by the specification. The scenario is that client and server are performing an initial handshake and the ChangeCipherSpec/Finished flight of the server gets lost. The handshake will look like this: ClientHello ServerHello, Certificate, Certificate Request, ServerHelloDone Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, Finished ChangeCipherSpec (Epoch: 0, Seq: 4), Finished (Epoch: 1, Seq: 0) --> got lost The client will discover a timeout because its last flight has not been acknowledged and starts to retransmit: Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, Finished The server then also repeats its last flight: ChangeCipherSpec (Epoch: 0, Seq: 1), Finished (Epoch: 1, Seq: 2) The client discards the repeated ChangeCipherSpec because the replay check fails. There already was a message with sequence number 1 at epoch 0, the Certificate. The sequence number has been reset to 0 after sending the ChangeCipherSpec and retransmissions have to get a new sequence number according to the specification. To solve this, there has to be an exception for retransmitted ChangeCipherSpecs. Either the rule to reset the sequence numbers or the rule to use a new sequence number for every retransmission has to be ignored. In the first case an increased number of the old epoch (5 in the example above) would be used. In the latter case the same sequence number (4 here) would be used again. Just accepting ChangeCipherSpecs with already used sequence numbers would be a security risk. In this case the client is still awaiting the ChangeCipherSpec and retransmits again. This results in an inifite loop until the maximum number of timeouts is reached and the connection is dropped. Best regards, Robin From Michael.Tuexen@lurchi.franken.de Wed Feb 25 04:09:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D4B3A67D2 for ; Wed, 25 Feb 2009 04:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.035 X-Spam-Level: *** X-Spam-Status: No, score=3.035 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hz7XNVMEisNd for ; Wed, 25 Feb 2009 04:09:36 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 874653A6768 for ; Wed, 25 Feb 2009 04:09:35 -0800 (PST) Received: from [192.168.1.193] (p508FDC70.dip.t-dialin.net [80.143.220.112]) by mail-n.franken.de (Postfix) with ESMTP id 8654F1C0B4620; Wed, 25 Feb 2009 13:09:53 +0100 (CET) Message-Id: <7A56C3A5-3BB6-4BB6-9966-AA27A26825F3@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Robin Seggelmann In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 13:09:52 +0100 References: X-Mailer: Apple Mail (2.930.3) Cc: tls@ietf.org Subject: Re: [TLS] DTLS retransmission problem X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 12:09:36 -0000 Hi Robin, a comment in-line. Best regards Michael On Feb 25, 2009, at 12:17 PM, Robin Seggelmann wrote: > While testing the retransmission functionallity of my DTLS > implementation, I have found a problem which is not covered by the > specification. The scenario is that client and server are performing > an initial handshake and the ChangeCipherSpec/Finished flight of the > server gets lost. The handshake will look like this: > > ClientHello > ServerHello, Certificate, Certificate Request, ServerHelloDone > Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, > Finished > ChangeCipherSpec (Epoch: 0, Seq: 4), Finished (Epoch: 1, Seq: 0) --> > got lost > > The client will discover a timeout because its last flight has not > been acknowledged and starts to retransmit: > > Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, > Finished > > The server then also repeats its last flight: > > ChangeCipherSpec (Epoch: 0, Seq: 1), Finished (Epoch: 1, Seq: 2) I would expect it to be ChangeCipherSpec (Epoch: 0, Seq: 5), Finished (Epoch: 1, Seq: 1) Can you provide a pointer to the text which is describing the behaviour you saw in the OpenSLL implementation? > > > The client discards the repeated ChangeCipherSpec because the replay > check fails. There already was a message with sequence number 1 at > epoch 0, the Certificate. The sequence number has been reset to 0 > after sending the ChangeCipherSpec and retransmissions have to get a > new sequence number according to the specification. To solve this, > there has to be an exception for retransmitted ChangeCipherSpecs. > Either the rule to reset the sequence numbers or the rule to use a > new sequence number for every retransmission has to be ignored. In > the first case an increased number of the old epoch (5 in the > example above) would be used. In the latter case the same sequence > number (4 here) would be used again. Just accepting > ChangeCipherSpecs with already used sequence numbers would be a > security risk. > > In this case the client is still awaiting the ChangeCipherSpec and > retransmits again. This results in an inifite loop until the maximum > number of timeouts is reached and the connection is dropped. > > Best regards, > Robin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From Michael.Tuexen@lurchi.franken.de Wed Feb 25 07:25:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDDD13A6919 for ; Wed, 25 Feb 2009 07:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.786 X-Spam-Level: ** X-Spam-Status: No, score=2.786 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oH+5OIdqF8qy for ; Wed, 25 Feb 2009 07:25:25 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 8084A3A6866 for ; Wed, 25 Feb 2009 07:25:21 -0800 (PST) Received: from [192.168.1.193] (p508FDC70.dip.t-dialin.net [80.143.220.112]) by mail-n.franken.de (Postfix) with ESMTP id AE28F1C0B4620; Wed, 25 Feb 2009 16:25:39 +0100 (CET) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: =C2 TLS In-Reply-To: <7A56C3A5-3BB6-4BB6-9966-AA27A26825F3@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 16:25:38 +0100 References: <7A56C3A5-3BB6-4BB6-9966-AA27A26825F3@lurchi.franken.de> X-Mailer: Apple Mail (2.930.3) Subject: Re: [TLS] DTLS retransmission problem X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 15:25:26 -0000 Dear all, I had a look at http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-01.txt and think the text gives the impression that you have only one sequence_number variable. I think this is wrong, one should have (conceptually) one =20 sequence_number per epoch. When retransmitting records, one should use for the retransmission a new sequence_number from the epoch of initial =20 transmission. Of course, one should also use the same set of algorithms for the retransmission as was used for the initial transmission. Do you agree? If yes, I think we need to add some text... Best regards Michael On Feb 25, 2009, at 1:09 PM, Michael T=FCxen wrote: > Hi Robin, > > a comment in-line. > > Best regards > Michael > > On Feb 25, 2009, at 12:17 PM, Robin Seggelmann wrote: > >> While testing the retransmission functionallity of my DTLS =20 >> implementation, I have found a problem which is not covered by the =20= >> specification. The scenario is that client and server are =20 >> performing an initial handshake and the ChangeCipherSpec/Finished =20 >> flight of the server gets lost. The handshake will look like this: >> >> ClientHello >> ServerHello, Certificate, Certificate Request, ServerHelloDone >> Certificate, ClientKeyExchange, CertificateVerify, =20 >> ChangeCipherSpec, Finished >> ChangeCipherSpec (Epoch: 0, Seq: 4), Finished (Epoch: 1, Seq: 0) --=20= >> > got lost >> >> The client will discover a timeout because its last flight has not =20= >> been acknowledged and starts to retransmit: >> >> Certificate, ClientKeyExchange, CertificateVerify, =20 >> ChangeCipherSpec, Finished >> >> The server then also repeats its last flight: >> >> ChangeCipherSpec (Epoch: 0, Seq: 1), Finished (Epoch: 1, Seq: 2) > I would expect it to be > ChangeCipherSpec (Epoch: 0, Seq: 5), Finished (Epoch: 1, Seq: 1) > > Can you provide a pointer to the text which is describing the =20 > behaviour you > saw in the OpenSLL implementation? >> >> >> The client discards the repeated ChangeCipherSpec because the =20 >> replay check fails. There already was a message with sequence =20 >> number 1 at epoch 0, the Certificate. The sequence number has been =20= >> reset to 0 after sending the ChangeCipherSpec and retransmissions =20 >> have to get a new sequence number according to the specification. =20 >> To solve this, there has to be an exception for retransmitted =20 >> ChangeCipherSpecs. Either the rule to reset the sequence numbers or =20= >> the rule to use a new sequence number for every retransmission has =20= >> to be ignored. In the first case an increased number of the old =20 >> epoch (5 in the example above) would be used. In the latter case =20 >> the same sequence number (4 here) would be used again. Just =20 >> accepting ChangeCipherSpecs with already used sequence numbers =20 >> would be a security risk. >> >> In this case the client is still awaiting the ChangeCipherSpec and =20= >> retransmits again. This results in an inifite loop until the =20 >> maximum number of timeouts is reached and the connection is dropped. >> >> Best regards, >> Robin >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From ekr@networkresonance.com Wed Feb 25 07:36:47 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC653A69B2 for ; Wed, 25 Feb 2009 07:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqfY6gj2UK8s for ; Wed, 25 Feb 2009 07:36:46 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id D1C8E3A6814 for ; Wed, 25 Feb 2009 07:36:46 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id DBCF750822; Wed, 25 Feb 2009 07:59:55 -0800 (PST) Date: Wed, 25 Feb 2009 07:59:55 -0800 From: Eric Rescorla To: Michael =?ISO-8859-1?Q?T=FCxen?= In-Reply-To: References: <7A56C3A5-3BB6-4BB6-9966-AA27A26825F3@lurchi.franken.de> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20090225155955.DBCF750822@romeo.rtfm.com> Cc: =C2 TLS Subject: Re: [TLS] DTLS retransmission problem X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 15:36:47 -0000 At Wed, 25 Feb 2009 16:25:38 +0100, Michael T=FCxen wrote: >=20 > Dear all, >=20 > I had a look at > http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-01.txt > and think the text gives the impression that you have only one > sequence_number variable. >=20 > I think this is wrong, one should have (conceptually) one =20 > sequence_number > per epoch. Agreed. > When retransmitting records, one should use for the > retransmission a new sequence_number from the epoch of initial =20 > transmission. Yep. > Of course, one should also use the same set of algorithms for the > retransmission as was used for the initial transmission. >=20 > Do you agree? If yes, I think we need to add some text... OK. I can do that, but if you want to contribute some, I wouldn't complain :) -Ekr From Henry.Story@Sun.COM Wed Feb 25 10:03:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3944D3A67C0 for ; Wed, 25 Feb 2009 10:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgeGRJkRXarL for ; Wed, 25 Feb 2009 10:03:09 -0800 (PST) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id B9CEB28C0D0 for ; Wed, 25 Feb 2009 10:03:08 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1PI3LMd004486 for ; Wed, 25 Feb 2009 18:03:27 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFM00F00VADAX00@fe-emea-10.sun.com> for tls@ietf.org; Wed, 25 Feb 2009 18:03:21 +0000 (GMT) Received: from [192.168.0.1] ([unknown] [88.163.1.232]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFM00IGXVH3UC70@fe-emea-10.sun.com>; Wed, 25 Feb 2009 18:03:09 +0000 (GMT) Date: Wed, 25 Feb 2009 19:02:52 +0100 From: Henry Story Sender: Henry.Story@Sun.COM To: tls@ietf.org Message-id: <6CF4BBB1-9004-44B7-A08E-62BA8D1F9F86@Sun.COM> X-Mailer: Apple Mail (2.930.3) Cc: Harbulot Bruno , foaf-protocols@lists.foaf-project.org Subject: [TLS] foaf+tls for distributed social networks - 2 questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 18:04:24 -0000 Dear TLS experts, We are working on a very simple protocol for distributed identity in a web of trust that uses TLS in a novel way. The details of this are short and can be found online [1]. Here I'd first just like to ask two questions, to get into the heart of the problem, then I'll explain why these came up. The 2 questions: ================ 1. How many browsers pre TLS1.1 act as TLS1.1 browsers with respect to section 7.4.4 [2] [[ If the certificate_authorities list is empty then the client MAY send any certificate of the appropriate ClientCertificateType, unless there is some external arrangement to the contrary. ]] So if a server sends an empty certificate_authorities list, how many browsers will in fact respond with at least one certificate? 2. Would it be possible to create a Certificate Authority that is completely open? That is we would publish the public and private keys of this CA so that people can sign their keys themselves, reducing the paper work needed to create certs. Of course as a result the value of these certs would be minimal, since they would not really validate anything. The background: =============== 1. infinite number of CAs ------------------------- When a foaf+tls [1] server asks the client for a certificate it is only really interested in the following information: - the Subject Alternative Name URL/URI - the public key of the certificate The server does not really care about the PKI hierarchy of trust, and can completely ignore that (though it could be useful as an extra piece of information). The server would like to accept certificates that are signed by as many people as possible. So currently we allow them even to be self signed certificates. This is a problem with the letter of TLS 1.0 which states in section 7.4.6: [[ If no suitable certificate is available, the client should send a certificate message containing no certificates. ]] Since we want everybody to be able to put together their own certificates, and since nobody can know in advance all the self signed CAs, it would be impossible for a server to ask the client for a certificate in the spirit of this letter is followed. Now if it turns out that most clients follow TLS1.1 in spirit, then we may just be able to proceed as is. 2. One Open marker CA --------------------- The other solution could be to create an Open Marker CA. This CA would just publish it's private key, so that anyone who had certificates that were intended to be used as foaf+ssl certificates, could sign those themselves with that Open CA, without having to ask anyone. The advantage of this would be that servers could provide a way to tell the clients that they were foaf+ssl enabled, and so reduce the risk of a random cert being sent to them. (I am not sure how many people do use certs in their browser, so I am not sure how much of a problem this is) I look forward to any feedback you may have about this or any other aspects of the protocol we are developing. I'll be glad to answer any questions you have. I hope this summary was not too short. Henry Story [1] The main paper for what we have called foaf+ssl (ssl being more widely known): http://www.w3.org/2008/09/msnws/papers/foaf+ssl.html The wiki page: http://esw.w3.org/topic/foaf+ssl The name is not set in stone and could be changed :-) [2] http://tools.ietf.org/html/rfc4346#section-7.4.4 [3] http://tools.ietf.org/html/rfc2246#section-7.4.6 From jnc@mercury.lcs.mit.edu Wed Feb 25 09:23:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02C73A684A; Wed, 25 Feb 2009 09:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCgEa3y55WXk; Wed, 25 Feb 2009 09:23:16 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id C13883A6883; Wed, 25 Feb 2009 09:23:16 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 751056BE573; Wed, 25 Feb 2009 12:23:36 -0500 (EST) To: ipr-wg@ietf.org Message-Id: <20090225172336.751056BE573@mercury.lcs.mit.edu> Date: Wed, 25 Feb 2009 12:23:36 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailman-Approved-At: Wed, 25 Feb 2009 23:11:50 -0800 Cc: jnc@mercury.lcs.mit.edu, rms@gnu.org Subject: [TLS] Call for volunteers to discuss IETF patent policy with Richard Stallman X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 17:23:17 -0000 Hi all, while discussing the whole TLS-AUTHZ situation with Richard Stallman of the FSF, he asked me to put him in touch with a couple of IETFers who are interested in trying to get the IETF to commit to staying further away from patent encumbrances in standards (distinctly patents, as opposed to other forms of IPR). I told him that I would try and rustle up some people, but that I thought it better to find some people on both sides for him to interact with, because I was concerned that if he only interacted with one side, he might get too hopeful a view of the likelihood of success for an attempt to change IETF policy in this area. He agreed that this would be good, since such an effort would involve a lot of effort, and he would only want to undertake it if it had a significant chance of success, and he did want to get a realistic appraisal of how things stood. So, if anyone wants to volunteer to interact with him on this matter, his email is "rms -at- gnu.org" (and this is CC'd to him), and please contact him. Sorry to the TLS members for the BCC to them too (if any of them are wondering how this got to them :-), if it's out of your scope, but given that TLS-AUTHZ was the cause of all this, I thought there might be some there who aren't on the IPR mailing list who might be interested to responding to him. Please also note that I am just _relaying_ this request, I am not myself directly deeply interested in whether the IETF has, or has not, a strong prohibition on patents; I am not receiving email from either list, and propose to take no further part in any of this. So if you want me to see any particular reply, for some reason, please make sure you CC me directly. Thanks! Noel From kanno-s@po.ntts.co.jp Thu Feb 26 08:18:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487C13A6877 for ; Thu, 26 Feb 2009 08:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwtPL9nRt-9f for ; Thu, 26 Feb 2009 08:18:42 -0800 (PST) Received: from mail2.ics.ntts.co.jp (mail2.ics.ntts.co.jp [202.32.24.42]) by core3.amsl.com (Postfix) with ESMTP id 5DEF628C269 for ; Thu, 26 Feb 2009 08:18:42 -0800 (PST) Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail2.ics.ntts.co.jp (8.13.8/NTTSOFT) with ESMTP id n1QGJ3IG019128 for ; Fri, 27 Feb 2009 01:19:03 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id n1QGJ3qJ001848 for tls@ietf.org; Fri, 27 Feb 2009 01:19:03 +0900 (JST) Received: from ccm18.silk.ntts.co.jp [10.7.18.18] by sadoku34.silk.ntts.co.jp with SMTP id BAA01847; Fri, 27 Feb 2009 01:19:03 +0900 Received: from mail15.silk.ntts.co.jp (localhost [127.0.0.1]) by ccm18.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n1QGJ3sV011943; Fri, 27 Feb 2009 01:19:03 +0900 (JST) Received: from mail15.silk.ntts.co.jp (localhost [127.0.0.1]) by mail15.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n1QGJ3xN005698; Fri, 27 Feb 2009 01:19:03 +0900 (JST) Received: from [127.0.0.1] ([10.7.206.148]) by mail15.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n1QGIwkl005666; Fri, 27 Feb 2009 01:19:03 +0900 (JST) Date: Fri, 27 Feb 2009 01:19:01 +0900 From: Satoru Kanno To: tls@ietf.org X-Face: ,\m{?h\)X Message-Id: <20090227005322.336D.KANNO-S@po.ntts.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.02 [ja] X-CC-Mail-RelayStamp: CC-Mail-V4-Client X-CC-Mail-RelayStamp: CC-Mail-V4-Server Subject: [TLS] draft-kato-tls-rfc4132bis-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 16:18:43 -0000 Hi, List We've uploaded an updated 'Camellia Cipher Suites for TLS', and is available at http://www.ietf.org/internet-drafts/draft-kato-tls-rfc4132bis-03.txt Please check our document. Of course, comments and questions about our document would be welcome. Best regards, -- Satoru Kanno Security Business Unit Mobile and Security Solution Business Group NTT Software Corporation e-mail: kanno-s@po.ntts.co.jp From nelson@bolyard.me Thu Feb 26 15:08:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253813A6817 for ; Thu, 26 Feb 2009 15:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1sBt5M1P9up for ; Thu, 26 Feb 2009 15:08:21 -0800 (PST) Received: from smtpauth11.prod.mesa1.secureserver.net (smtpauth11.prod.mesa1.secureserver.net [64.202.165.33]) by core3.amsl.com (Postfix) with SMTP id 1AD7A28C225 for ; Thu, 26 Feb 2009 15:08:20 -0800 (PST) Received: (qmail 29328 invoked from network); 26 Feb 2009 23:08:42 -0000 Received: from unknown (64.202.165.33) by smtpauth11.prod.mesa1.secureserver.net (64.202.165.33) with ESMTP; 26 Feb 2009 23:08:41 -0000 Message-ID: <49A7207D.20606@bolyard.me> Date: Thu, 26 Feb 2009 15:06:37 -0800 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: Satoru Kanno References: <20090227005322.336D.KANNO-S@po.ntts.co.jp> In-Reply-To: <20090227005322.336D.KANNO-S@po.ntts.co.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-kato-tls-rfc4132bis-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 23:08:22 -0000 Satoru Kanno wrote, On 2009-02-26 08:19: > Hi, List > > We've uploaded an updated 'Camellia Cipher Suites for TLS', > and is available at > > http://www.ietf.org/internet-drafts/draft-kato-tls-rfc4132bis-03.txt > > Please check our document. > > Of course, comments and questions about our document would be welcome. > > Best regards, > > -- > Satoru Kanno Please provide a brief summary of the differences between this document and RFC 4132. Since RFC 4132 is implemented in recent versions of Firefox, I am interested in knowing if the new document necessitates any changes that might present interoperability issues with implementations of that RFC. Regards, /Nelson Bolyard From A.Hoenes@tr-sys.de Thu Feb 26 17:34:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68C23A6B13 for ; Thu, 26 Feb 2009 17:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.784 X-Spam-Level: * X-Spam-Status: No, score=1.784 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYd0+Vi1KqwP for ; Thu, 26 Feb 2009 17:34:36 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id B6C063A67B4 for ; Thu, 26 Feb 2009 17:34:34 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA200128382; Fri, 27 Feb 2009 02:33:02 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id CAA12309; Fri, 27 Feb 2009 02:33:00 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200902270133.CAA12309@TR-Sys.de> To: kanno-s@po.ntts.co.jp, tls@ietf.org Date: Fri, 27 Feb 2009 02:33:00 +0100 (MEZ) In-Reply-To: <20090226190948.335F.KANNO-S@po.ntts.co.jp> from Satoru Kanno at Feb "27, " 2009 "01:19:10" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] draft-kato-tls-rfc4132bis-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 01:34:36 -0000 Since the first revisions of draft-kato-tls-rfc4132bis, the collective wisdom in the TLS WG, the SEC area of the IETF, and at large, on proper mix & match of block cipher strenghts (measured in key size) and hash strength (measured in SHA-2 hash width) has evolved. The latest policy of the TLS WG was: a) that full AES-256 strength (corresponding to SHA-512) was not required in TLS for the foreseeable future, and a) to use the 'overshooting' AES-256 for the 192-bit security level (corresponding to SHA-384), in order to reduce the combinatorial complexity. Based on these principles, the common combinations have been AES-128 + SHA-256 and AES-256 + SHA-384 . This strategy has been followed in the TLS ciphersuite documents published in the recent past and currently in the RFC Editor Queue. Thus, it should be seriously considered to define a matching portfolio of properties in the Camellia-based family of TLS cipersuites. This would mean introducing SHA-384 in place of SHA-256 into the last group of 6 ciphersuites (those using Camellia-256) defined in the draft. Should we recommend the authors to undertake this step? Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From n.mavrogiannopoulos@gmail.com Fri Feb 27 03:08:11 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924C83A6AB1 for ; Fri, 27 Feb 2009 03:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuvN-2PAPO7F for ; Fri, 27 Feb 2009 03:08:10 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 0440F3A6A8A for ; Fri, 27 Feb 2009 03:07:47 -0800 (PST) Received: by bwz26 with SMTP id 26so967411bwz.37 for ; Fri, 27 Feb 2009 03:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=EBaG2fAi+5Rfd455+amxhFHzB8WTOu+0QigcbW5Opxs=; b=E5dEJcluTgyMPW/P/ce2Qd4xK5zN/bdl2Koz9me1d1d7BgPkZNNlrg97pw+mLPv/wD zgaaaka8OzW3LiKr6y0M3IwATQXIMb3AI56nVMRGJr/Fcvty+gHO8pitSYyd40eqfa2U aD1IPYX7GuNeiPsNdNJAPQzdZpGLTZ0XsD8+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=t2W65qdkgdaj+UJ+/gg3Pu+KqNeTrGe8mw56cbh8xjmpr8i84aAmLq9wW70AFka6vu k0yqh9FVuIdOCjTIL93OmD4ykG2PFXja37bu5mgyMZOzBWfS/3tn5w7BKCJiyltqTGVj Jai2anoZlGoi+wWOqo8gOXdnwRf6paqvC4dh0= Received: by 10.102.228.10 with SMTP id a10mr1242423muh.26.1235732889221; Fri, 27 Feb 2009 03:08:09 -0800 (PST) Received: from ?10.100.1.196? (adsl19-101.ath.forthnet.gr [77.49.210.101]) by mx.google.com with ESMTPS id j10sm53mue.56.2009.02.27.03.08.03 (version=SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 03:08:08 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <49A7C991.5050309@gnutls.org> Date: Fri, 27 Feb 2009 13:08:01 +0200 From: Nikos Mavrogiannopoulos User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Henry Story References: <6CF4BBB1-9004-44B7-A08E-62BA8D1F9F86@Sun.COM> In-Reply-To: <6CF4BBB1-9004-44B7-A08E-62BA8D1F9F86@Sun.COM> X-Enigmail-Version: 0.95.0 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Harbulot Bruno , tls@ietf.org, foaf-protocols@lists.foaf-project.org Subject: Re: [TLS] foaf+tls for distributed social networks - 2 questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 11:08:11 -0000 Henry Story wrote: > Dear TLS experts, > > We are working on a very simple protocol for distributed identity in a > web of trust that uses TLS in a novel way. The details of this are short > and can be found online [1]. Here I'd first just like to ask two > questions, to get into the heart of the problem, then I'll explain why > these came up. After the explanation and seeing the protocol description I still do not understand why you need the client certificate for what you want to achieve. Why you don't send the information you need for foaf on the application layer (if it is http via a cookie etc)? Why send a dummy certificate and add some extensions on it? Also the security offerings are not clear to me. What will that protocol offer, security-wise? regards, Nikos From Henry.Story@Sun.COM Fri Feb 27 04:23:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922943A6A20 for ; Fri, 27 Feb 2009 04:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.094 X-Spam-Level: X-Spam-Status: No, score=-6.094 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSyPVnwI4yRE for ; Fri, 27 Feb 2009 04:23:51 -0800 (PST) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id BFCDD3A680F for ; Fri, 27 Feb 2009 04:23:38 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1RCNjHv006365 for ; Fri, 27 Feb 2009 12:23:59 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFQ00G004CV0E00@fe-emea-10.sun.com> for tls@ietf.org; Fri, 27 Feb 2009 12:23:45 +0000 (GMT) Received: from [192.168.0.1] ([unknown] [88.163.1.232]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFQ00EA753CHUD0@fe-emea-10.sun.com>; Fri, 27 Feb 2009 12:23:43 +0000 (GMT) Date: Fri, 27 Feb 2009 13:23:22 +0100 From: Henry Story In-reply-to: <49A7C991.5050309@gnutls.org> Sender: Henry.Story@Sun.COM To: Nikos Mavrogiannopoulos Message-id: X-Mailer: Apple Mail (2.930.3) References: <6CF4BBB1-9004-44B7-A08E-62BA8D1F9F86@Sun.COM> <49A7C991.5050309@gnutls.org> Cc: tls@ietf.org, foaf-protocols@lists.foaf-project.org Subject: Re: [TLS] foaf+tls for distributed social networks - 2 questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 12:23:52 -0000 On 27 Feb 2009, at 12:08, Nikos Mavrogiannopoulos wrote: > Henry Story wrote: >> Dear TLS experts, >> >> We are working on a very simple protocol for distributed identity >> in a >> web of trust that uses TLS in a novel way. The details of this are >> short >> and can be found online [1]. Here I'd first just like to ask two >> questions, to get into the heart of the problem, then I'll explain >> why >> these came up. > > After the explanation and seeing the protocol description I still do > not > understand why you need the client certificate for what you want to > achieve. Why you don't send the information you need for foaf on the > application layer (if it is http via a cookie etc)? Why send a dummy > certificate and add some extensions on it? Also the security offerings > are not clear to me. What will that protocol offer, security-wise? Before I go into why I don't do it differently, let me clarify why we do it this way. So in answer to your question "Why send a dummy certificate and add some extensions on it?" let me show you what that gives me: When the URI is taken from the Subject Alternative Name of the certificate sent to the browser the server at stage 3 of the diagram in [1] knows the following: - the browser has access to the private key for the public key listed in the X509 cert - the browser wishes to identify the user as having that URI - and of course the communication has not been tampered with (TLS) This, it is true, is very little, but not nothing. By then dereferencing the URI of the User using simple HTTP GET, the server can then get confirmation that the resource referred to by that URL is indeed controlled by the owner of the User Agent. This then ties the User to that URI. > Also the security offerings are not clear to me. What will that > protocol offer, security-wise? Well TLS provides all the security of communication we need. What remains is the question of Trust. How much does the server trust the agent making the connection with knowledge of the resource it wishes to server up? Trust just something that is not always captured well in a hierarchical manner. So there are a number of ways the server could decide to trust the now identified and authenticated request. It could just check that URI with a list of URIs it already is in possession of. That list of URIs could be something published on a remote site (at a URL) which the server would crawl regualarly. Or the server could check a list of resources crawled periodically from a friend network. Or many other things... I go into more detail on some of the trust issues in the article "foaf+ssl: creating a web of trust without key signing parties" [2]. The TLS piece gives us identity and authentication. We then use that to build trust from a web of trust, rather than a hierarchical pyramid of trust as it more common in PKI. This it is true is unusual, but that may explain why nobody tried it before [3] :-) > Why you don't send the information you need for foaf on the > application layer (if it is http via a cookie etc)? So what do you loose by doing it any different way? By as you suggest sending the URL via a cookie for example? a. cookies are tied to domains. So here you loose the global nature of the foaf+tls solution. With foaf+tls you can go to a site you have never visited before, and in one click authenticate yourself. [4] Without as with OpenId needed to remember a URL [5] b. how would a user add a cookie to his browser to be sent on his demand to any server on the internet? (indeed with foaf+tls the browser can give the user a choice of which id to present to the server on request of a client certificate) There is no such functionality for cookies. c. how would you tie the cookie, added by the user, to that browser, without the danger of man in the middle attacks? You need TLS. In fact I had initially thought of a cookie + TLS solution [6], because I thought we would need new UserAgents to get this working, and I was writing a specialized semantic web user agent anyway [7]. But of course once I discovered that everything I needed was provided by TLS I realised that my job was done. I hope this helps answer your questions, Henry > regards, > Nikos [1] http://blogs.sun.com/bblfish/entry/foaf_ssl_adding_security_to [2] http://blogs.sun.com/bblfish/entry/more_on_authorization_in_foaf [3] http://blogs.sun.com/bblfish/entry/foaf_ssl_pki_and_the [4] http://blogs.sun.com/bblfish/entry/foaf_ssl_user_story_1 [5] foaf compared to openid: http://blogs.sun.com/bblfish/entry/what_does_foaf_ssl_give [6] http://lists.w3.org/Archives/Public/semantic-web/2008Mar/0206.html [7] https://sommer.dev.java.net/AddressBook.html From ekr@rtfm.com Fri Feb 27 07:06:59 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31513A6882 for ; Fri, 27 Feb 2009 07:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95SEAGmdB0Gl for ; Fri, 27 Feb 2009 07:06:58 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id B36383A6452 for ; Fri, 27 Feb 2009 07:06:58 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so580240wag.5 for ; Fri, 27 Feb 2009 07:07:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.92.14 with SMTP id p14mr1200758wab.140.1235747241368; Fri, 27 Feb 2009 07:07:21 -0800 (PST) Date: Fri, 27 Feb 2009 07:07:21 -0800 Message-ID: From: Eric Rescorla To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] TLS Errate confirmation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 15:06:59 -0000 I confirm this is correct. -Ekr ---------------- Somehow we missed this one, although this bug was in all versions from 01 to 10.... Eric: if you can confirm that this errata is correct, I can mark it as "verified" in the RFC Editor errata database. Best regards, Pasi > -----Original Message----- > From: ext RFC Errata System [mailto:rfc-editor at rfc-editor.org] > Sent: 05 November, 2008 10:45 > To: tim at dierks.org; ekr at rtfm.com; tim.polk at nist.gov; Eronen > Pasi (Nokia-NRC/Helsinki); ekr at networkresonance.com; > jsalowey at cisco.com > Cc: Eronen Pasi (Nokia-NRC/Helsinki); rfc-editor at rfc-editor.org > Subject: [Technical Errata Reported] RFC5246 (1585) > > > The following errata report has been submitted for RFC5246, > "The Transport Layer Security (TLS) Protocol Version 1.2". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=1585 > > -------------------------------------- > Type: Technical > Reported by: Pasi Eronen > > Section: A.4.2 > > Original Text > ------------- > struct { > ClientCertificateType certificate_types<1..2^8-1>; > DistinguishedName certificate_authorities<0..2^16-1>; > } CertificateRequest; > > > Corrected Text > -------------- > struct { > ClientCertificateType certificate_types<1..2^8-1>; > SignatureAndHashAlgorithm > supported_signature_algorithms<2^16-1>; > DistinguishedName certificate_authorities<0..2^16-1>; > } CertificateRequest; > > > Notes > ----- > The definition in Section 7.4.4 (which includes the "supported_ > signature_algorithms" field) is the correct one. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5246 (draft-ietf-tls-rfc4346-bis-10) > -------------------------------------- > Title : The Transport Layer Security (TLS) > Protocol Version 1.2 > Publication Date : August 2008 > Author(s) : T. Dierks, E. Rescorla > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > ___________________________________ From root@core3.amsl.com Sat Feb 28 13:45:01 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E57E43A684B; Sat, 28 Feb 2009 13:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090228214501.E57E43A684B@core3.amsl.com> Date: Sat, 28 Feb 2009 13:45:01 -0800 (PST) Cc: tls@ietf.org Subject: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 21:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Keying Material Exporters for Transport Layer Security (TLS) Author(s) : E. Rescorla Filename : draft-ietf-tls-extractor-04.txt Pages : 6 Date : 2009-02-28 A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-extractor-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-28133518.I-D@ietf.org> --NextPart--